Answered by:
Sql Azure and Sync Framework

Question
-
<cross-post from Sql Azure forum>
Running a Windows Azure service I am trying to use the SqlAzureSyncProvider. Runs fine in dev fabric but when deployed my service crashes claiming:
"Could not load file or assembly 'Microsoft.Synchronization.Data.SqlAzure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. An attempt was made to load a program with an incorrect format."
Obviously this error is normally associated with 32/64-bit mismatch so I'm not sure how it can be my bug (I'm building Any CPU, all managed code). I'm able to access SqlAzure for standard DB operations successfully elsewhere in the code, I believe the bug only triggers when I try to instantiate the SqlAzureSyncProvider.
Any ideas?- Moved by Max Wang_1983 Thursday, April 21, 2011 10:27 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
Thursday, November 26, 2009 9:07 PM
Answers
-
Hi Greg,
Unfortunately, the SQL Azure provider that is part of the CTP1 Power Pack for SQL Azure does not support the ability to be run within SQL Azure (N-tier). The reason for this is due to the batching that was implemented in this provider. The batches need to be persisted and we have not implemented this support in the provider for Windows Azure yet. We are looking into supporting this in a subsequent version.
For this CTP the provider can only be run in 2-tier (meaning the client and server provider run on the client side). Fortunately due to the this new bathcing support (that uses SQL Azure TVP's) the performance is much better then we saw with previous server providers run in 2-tier mode. In fact some basic tests showed up to 20x performance improvements.
Out of curiosity what is the primary reason you want to run this in Windows Azure? Is it to allow you to centralize your business logic?
Liam
Sr. Program Manager, SQL Azure and Sync Framework - http://msdn.microsoft.com/sync/- Proposed as answer by Liam Cavanagh - MSFTMicrosoft employee Monday, November 30, 2009 5:32 PM
- Marked as answer by Liam Cavanagh - MSFTMicrosoft employee Monday, November 30, 2009 5:32 PM
Monday, November 30, 2009 5:32 PM
All replies
-
Hi Greg,
Unfortunately, the SQL Azure provider that is part of the CTP1 Power Pack for SQL Azure does not support the ability to be run within SQL Azure (N-tier). The reason for this is due to the batching that was implemented in this provider. The batches need to be persisted and we have not implemented this support in the provider for Windows Azure yet. We are looking into supporting this in a subsequent version.
For this CTP the provider can only be run in 2-tier (meaning the client and server provider run on the client side). Fortunately due to the this new bathcing support (that uses SQL Azure TVP's) the performance is much better then we saw with previous server providers run in 2-tier mode. In fact some basic tests showed up to 20x performance improvements.
Out of curiosity what is the primary reason you want to run this in Windows Azure? Is it to allow you to centralize your business logic?
Liam
Sr. Program Manager, SQL Azure and Sync Framework - http://msdn.microsoft.com/sync/- Proposed as answer by Liam Cavanagh - MSFTMicrosoft employee Monday, November 30, 2009 5:32 PM
- Marked as answer by Liam Cavanagh - MSFTMicrosoft employee Monday, November 30, 2009 5:32 PM
Monday, November 30, 2009 5:32 PM -
Hi Liam,
Thanks for the response. The design that this is very useful for is a peer-to-peer sync service where one of the devices is a "virtual" device in the cloud. The clients sync to SqlCe and the cloud syncs to SqlAzure, but the communication between all of them is uniform and n-tier.
-gregTuesday, December 1, 2009 12:29 AM -
Yes, being able to run the logic within SQL Azure is definitely a priority for us and specifically your suggested scenario is at the top of that list so we hope you will see some of this in the next release.
Liam
Sr. Program Manager, SQL Azure and Sync Framework - http://msdn.microsoft.com/sync/Wednesday, December 2, 2009 10:13 PM