locked
Which version for which dll's for which distributions? RRS feed

  • Question

  • Can someone please provide guidance as to which dll's should be referenced to have a valid set of sync dll's? I find the versioning to be confusing. I would like to blow everything away and get a correct installation on my development machine.

    As it stands, I have multiple copies of, for example,  Microsoft.Synchronization.Data.SqlServerCe.dll, in various versions, as a result of installing the sync framework, SDK, and (!) MS Expression Blend.

    Thanks, Crile

    Visusl Studio complains like this:

    Consider app.config remapping of assembly "Microsoft.Synchronization.Data.SqlServerCe, Culture=neutral, PublicKeyToken=89845dcd8080cc91" from Version "2.0.0.0" [C:\Program Files (x86)\Microsoft SDKs\Microsoft Sync Framework\v1.0\Runtime\ADO.NET\V2.0\x86\Microsoft.Synchronization.Data.SqlServerCe.dll] to Version "3.5.0.0" [C:\Program Files (x86)\Microsoft Synchronization Services\ADO.NET\v1.0\Microsoft.Synchronization.Data.SqlServerCe.dll] to solve conflict and get rid of warning.

    Consider app.config remapping of assembly "Microsoft.Synchronization.Data, Culture=neutral, PublicKeyToken=89845dcd8080cc91" from Version "1.0.0.0" [C:\Program Files (x86)\Microsoft Synchronization Services\ADO.NET\v1.0\Microsoft.Synchronization.Data.dll] to Version "2.0.0.0" [C:\Program Files (x86)\Microsoft SDKs\Microsoft Sync Framework\v1.0\Runtime\ADO.NET\V2.0\x86\Microsoft.Synchronization.Data.dll] to solve conflict and get rid of warning.

    Thursday, July 9, 2009 10:36 PM

All replies

  • From your description, it appears that you are redirecting MSF dlls version in your app. Multiple versions side by side is allowable scenario.  However there is no 1.0.0.0 version. If you have these dlls in your gac then you will not need any redirection. You have option  to  either update your dll version to match with that in gac or remove them from app.config.
    For your cleanup, you can use add and remove program in control panel to uninstall older sync versions.

    thanks
    Jandeep


    jandeepc
    Monday, July 13, 2009 7:23 PM
  • Thanks for the reply. The problem is complex. I have uninstalled and reinstalled several times, but there is no clear path to the newest version. It seems that the versioning is odd and there is no official installation method that will give us the latest and greatest bits, especially for Vista Ultimate 64 bit when you must target (due to LINQ weirdness) 32 bit deliverables.

    Thus I am looking for a list of the Sync Framework dll's that work properly as a group. Unfortunately, the files are identified in a way that makes no sense - there even are dll's with incremented version numbers that are physically older than ones with higher versions.

    As it is, without further explicit guidance, it is impossible to compile with and distribute a stable application based on these sync framework dll's.  And it looks as if all the sync framework developers have either gone silent or have been reasssigned to Azure projects.

    Please advise.

    Crile

    BTW, we are Gold Partners - is this the best place to get support?
    Monday, July 13, 2009 7:38 PM
  • anybody there ? :)
    Saturday, July 25, 2009 12:09 AM
  • Hi Crlie,

    Sorry for the confusion. I can understand your frustration as the dlls are not version in the best possible way.

    1. The dlls in C:\Program Files (x86)\Microsoft Synchronization Services\ADO.NET\v1.0\ are part of the sync framework, but date to really pre Sync framework v1.0 bits. These are coming from SQL Server compact installation. The dlls enable you to write sync solutions in the hub-spoke topology beteween a server and SQL Server compact.
    2. The dlls in C:\Program Files (x86)\Microsoft SDKs\Microsoft Sync Framework\v1.0\Runtime\ADO.NET\V2.0\x86\ are the Sync framework v1.0 bits and are installed when you install Sync framework v1.0 MSIs. These are the latest bits. These bits enable you to write apps in the hub-spoke topology and peer-to-peer server databases. The associated namespaces are different ones for the 2 scenarios.

    Depending on your need (topology) you could stick with one or the other or have both of them on the system as they are side-by-side.

    I hope I was able to answer some of your questions. Please respond back if you still have questions or are not clear.


    This posting is provided AS IS with no warranties, and confers no rights
    Sunday, July 26, 2009 12:25 AM