locked
name conflict on Microsoft.Synchronization.SyncProvider in microsoft.synchronization.dll and microsoft.synchronization.data.dll RRS feed

  • Question

  • I'm using Microsoft Sync Framework v1.0 CTP2 and have both microsoft.synchronization.dll and microsoft.synchronization.data.dll added as references to my project. When I then try to use Microsoft.Synchronization.SyncProvider, I get a compiler error saying that this type is defined in both of these dlls. Is this a bug?
    • Moved by Max Wang_1983 Thursday, April 21, 2011 10:02 PM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Friday, July 11, 2008 1:52 PM

Answers

  • Well, there was no real issue anymore, since simply using the 2.0.0.0 version of microsoft.synchronization.data dll solved the matter.

    Thank you for looking into it.

    Gert
    Thursday, July 17, 2008 10:16 AM

All replies

  • I have discussed with one of the developers a change he made since CTP2 regarding namespaces and where classes are defined. He believes this was a known bug in CTP2 and is currently fixed. I am currently installing CTP2 to repro the issue and then verify it has been fixed in the current build.

     

    if I don't complete this today I will have it done tomorrow and results posted.

     

    thanks

    Willie

    wreed@microsoft.com

    Friday, July 11, 2008 9:39 PM
  • I have not been able to repro the issue on CTP2. I noticed you are already specifying the fully qualified name, which should have avoided the ambiguity between the 2 classes.

     

    can you post some code that I can paste into my project?

     

    thanks

    Friday, July 11, 2008 9:59 PM
  • Ah, apparently I have a version 1.0.0.0 and a version 2.0.0.0 of the microsoft.synchronization.data.dll on my system. The problem only occurs with 1.0.0.0.

    There it really is the same name within the same namespace (Microsoft.Synchronization.SyncProvider) that is redefined, so fully specifying the name doesn't solve it.

    I'm pretty sure I only installed CTP2 on this machine. Is it normal that it comes with two versions of the
    microsofts.synchronization.data.dll?

    By the way, the version of
    microsoft.synchronization.dll installed is 0.94.0.0.

    With the two conflicting dlls referenced (
    microsoft.synchronization.dll 0.94.0.0 and microsoft.synchronization.data.dll 1.0.0.0), all it takes to reproduce the problem is using the type:

    Microsoft.Synchronization.SyncProvider prov;
    Monday, July 14, 2008 8:01 AM
  • Yes to the question "is it expected". The 1.0 and 2.0 are supposed to exist side by side on a machine. Version 1.0 is something that comes with SQL, both the beta (Katmai) and the shipping version 2005 (Yukon).

     

    We have set the version of Microsoft.Synchronization.dll to 1.0.1215.0 as the shipping version of Microsoft Synchronization Framework.

     

    At the time I did this test I did not have SQL installed, I'll start over. Not sure if I'll complete this till Tuesday or potentially even Wednesday.

    Monday, July 14, 2008 9:13 PM
  • here is a little more information...

     

    OCS 1.0 is for Hub Spoke scenarios and does not use the Sync Framework, it does all the sync work by itself. It is built right into Visual Studio, and it enables offline cache for SQL CE.

     

    OCS 2.0 is for Peer to Peer scenarios and is built on top of Sync Framework. It comes with a provider for SQL Express. We are in the process of developing a provider for SQL CE.

     

    If you want to do Hub Spoke scenarios, using SQL CE, then Visual Studio is already aware of Sync Services for ADO.NET 1.0 in the Designer Studio, and template projects.

     

    If you want to do P2P, using SQL Express, then you need to create a blank project and add references to the 2.0 version of Microsoft.Syncronization.Data.dll.

     

    Please let me know if that fixes the issue.

     

    thanks

    Willie

    Monday, July 14, 2008 9:39 PM
  • Well, there was no real issue anymore, since simply using the 2.0.0.0 version of microsoft.synchronization.data dll solved the matter.

    Thank you for looking into it.

    Gert
    Thursday, July 17, 2008 10:16 AM