none
Sync Framework 2.1 Private Deployment RRS feed

  • Question

  • We have chosen sqlce, partly because it can be privately deployed, resulting in a very fast and small installer for customers. We use Sync Framework 2.1 to sync databases between computers, and now we need to add Sync Framework to our installer. Is there some way we can install the dlls, just like for sqlce? I have read elsewhere that this may not be possible - but I don't understand why that would be the case?

    I have also read here of a procedure to install sync framework 2.1 for Azure - can that technique be used for sqlce?

    If the only solution is to use the redistributables available from here, is there a tutorial that explains the steps to integrate those resistributables into our installer?

    Thanks for any assistance,
    Tim

    Monday, May 30, 2011 11:38 AM

Answers

  • I assumed you use Windows Azure SDK 1.3 or later which has already had Admin privillege.

    what you can do it add the startup section for the servie defination and specify the "regsvr32 /s synchronization21.dll" in it to get it registered during service start up.

    Hope this helps.

    thanks

    Yunwen

     

     


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, June 1, 2011 2:52 PM
    Moderator
  • Yunwen & Magnus,

    Just to follow up on this issue, I confirmed the solution you provided, using "regsvr32 /s synchronization21.dll" did solve this problem.

    However, what I found was even better was to just use two manifest files as described in Deploying of Sync Framework Components to Windows Azure. Note that our application is WPF and does not use Azure at all - but this procedure seems to work. By using the manifest files, there is nothing special to build into the installer / or post-install requirements. I did not need to do step 6, create an activation context - I think this is implicit in the use of sync framework.

    I'm not sure if this approach is supported by Microsoft, however it has worked in our testing internally and we now have this successfully deployed to one customer for testing.

    Thanks,
    Tim

    • Marked as answer by ausadmin Monday, June 13, 2011 10:15 PM
    Monday, June 13, 2011 10:14 PM

All replies

  • Hi.

    Well, in theory you can do a private deployment of the Microsoft Sync Framework v2.1 DLLs.

    However the MS Sync team, in their infinite wisdom, introduced a COM dependency in v2.1. A COM dependency means that you will need local admin rights to register the COM component in question.

    This unfortunately breaks the whole beauty of using MS Sync Framework in a ClickOnce application. ClickOnce applications could be installed without admin rights, but if you make a dependency on MS Sync v2.1, you must install with admin rights.

    Sigh...

    I, for one, really hope that the next version of the sync framework is not dependent on COM dlls.

    Hope this helps.

    Regards,

    Magnus


    My blog: InsomniacGeek.com
    Monday, May 30, 2011 2:41 PM
  • Magnus,

    Thank you very much for your valuable reply. This clears up a lot of the information I have been reading.

    In our application, we will not use ClickOnce - we will have an installer running under admin rights. We already have other code running in a custom action to perform various other tasks at Administrator level, at install time. So if you could point me to the steps to register the COM compoenent (preferably in code), that would be really helpful. Alternatively a link to the steps. I am assuming it is Synchronization21.dll that needs to be registered?

    Thanks,
    Tim

    Monday, May 30, 2011 8:37 PM
  • I assumed you use Windows Azure SDK 1.3 or later which has already had Admin privillege.

    what you can do it add the startup section for the servie defination and specify the "regsvr32 /s synchronization21.dll" in it to get it registered during service start up.

    Hope this helps.

    thanks

    Yunwen

     

     


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, June 1, 2011 2:52 PM
    Moderator
  • Hi Tim.

    Yes, that's the pesky littl DLL.

    So if you already have a admin priv required custom action , then I'll suppose you can add this reg as well.

    If you want to do it from code, you can do it something like this:

    public void RegisterDll(string dllPath)
    {
     try
     {
      string fileinfo = "/s" + " " + "\"" + dllPath + "\"";
    
      Process reg = new Process();
      reg.StartInfo.FileName = "regsvr32.exe";
      reg.StartInfo.Arguments = fileinfo;
      reg.StartInfo.UseShellExecute = false;
      reg.StartInfo.CreateNoWindow = true;
      reg.StartInfo.RedirectStandardOutput = true;
      reg.Start();
      reg.WaitForExit();
      reg.Close();
     }
     catch (Exception ex)
     {
      // Handle error
     }
    }
    

    Hope this helps.

    Regards,

    Magnus


    My blog: InsomniacGeek.com
    Wednesday, June 1, 2011 3:38 PM
  • Yunwen & Magnus,

    Thanks for the replies - will let you know what I find out.

    Yunwen, no we are not using Azure SDK, this is not an Azure app. It is a WPF app with a sqlce database. I was looking at the other post on private deployment with Azure and was wondering if the same technique could be applied for our installation. In any case, I think you provided the information I need.

    Regards,
    Tim

    Wednesday, June 1, 2011 8:08 PM
  • Yunwen & Magnus,

    Just to follow up on this issue, I confirmed the solution you provided, using "regsvr32 /s synchronization21.dll" did solve this problem.

    However, what I found was even better was to just use two manifest files as described in Deploying of Sync Framework Components to Windows Azure. Note that our application is WPF and does not use Azure at all - but this procedure seems to work. By using the manifest files, there is nothing special to build into the installer / or post-install requirements. I did not need to do step 6, create an activation context - I think this is implicit in the use of sync framework.

    I'm not sure if this approach is supported by Microsoft, however it has worked in our testing internally and we now have this successfully deployed to one customer for testing.

    Thanks,
    Tim

    • Marked as answer by ausadmin Monday, June 13, 2011 10:15 PM
    Monday, June 13, 2011 10:14 PM
  • Tim:

    I too am installing a windows application, but winforms.  However, I my app doesn't require elevated privileges. I've tried the manifest file procedure that you found, but I can't get it to work.  Would you mind posting what if anything that you changed in the manifest files?

    Thanks,

    Vince


    Saturday, August 20, 2011 9:58 AM