Dela via

What is your preffered deployment strategy: SxS/GAC or XCOPY?

  • Artikel

There is an interesting article in the latest MSDN magazine about Reg-free COM and .NET components: https://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/default.aspx

The technology was present for quite a while, but still not very well known. Part of the reason is that the technical details (at least on the COM side) are buried deep in the MSDN technical reference on SxS here: https://msdn.microsoft.com/library/en-us/sbscs/setup/creating_registration-free_com_objects.asp

Side-by-side (SxS) assemblies had an interesting history. Years ago, when people were still counting their disk free space KB or MB, there was a natural need for shared libraries. You didn't want to replicate the same MSVCRT.DLL for every single installed application. So people ended up in... DLL hell. That is what you get when an application can replace the existing MSVCRT.DLL with an older (or newer) version, causing AVs all over the place.

But in the meantime the disk space was not an issue anymore. So the tendency, at least for a while, was to have a separate copy of DLL per application. Now, (almost) each application has its own copy of MSVCRT.DLL. In fact, the version 8 of the runtime (msvcr80.dll) is not even in the latest versions of Windows. The same strategy is usewd also by most Java runtimes. It is recommended that each Java application or service has its own copy of the runtime.

But in the last years, security became a very big issue for practically everyone. So, what you would do when you want to patch a runtime that is spread all over the place? The cheesy solution would be a quick file "search&replace", but will it work? You don't know. But anyway, the fact that you do not have a centralized location certainly helps. And this is where SxS comes into play. In some scenarios, it is actually easier to "patch" the shared version than to go to every single directory for a manual patch. This was the case with the infamous MS04-028 where all applications using the (SxS-based) gdiplus.dll were immediately "fixed" by Windows Update, but applications that had a local copy of the same DLL had to be upgraded manually.

So, what is the final solution? Ultimately, I guess that the best answer depends on your specific scenario. XCOPY deployment might end up creating lots of copies of the same DLL, which are harder to upgrade in case of a security patch. SxS (or GAC for .NET components) might be also a very good solution but doesn't offer an easy deployment experience.

Comments

  • Anonymous
    March 23, 2005
    Another interesting, but not exactly related scenario is when you application has to be able to run strait off of removeable storage with no idea how the environment is setup.

    We had this choice for a product that is currently in development. We would have liked to use C++/CLI, but were not sure that all (or any for that matter) systems would have the .NET Framework in any version. So, we ended up deciding on good old MFC and Win32.

    Through our own semi-serious polls and partner experiences, we have found that for normal consumer applications the .NET Framework is ok. Most have it already through Windows Updates I'm guessing, or they are willing to download it. We have a lot of control over our business clients, they will install it if we ask them to.

    Sorry for the rant, just wanted to let you know that the actual choice of programming language and framework is also determined by the problem that you talked about.

    -Josh
  • Anonymous
    March 23, 2005
    Josh's scenario is what we called KeyChain scenario. Take your favorate app in a KeyChain and plug it into any computer, and it just runs.

    This is one of our long term goal, but it is far from reality now.
  • Anonymous
    March 24, 2005
    With fusionized DLLs, you can still deploy these DLLs application local, and they are still serviceable via the policies.
  • Anonymous
    March 24, 2005
    A problem with private (per-app) deployment is that it reduces system-wide sharing of memory pages. Yeah, disk space is cheap, but now we're potentially hurting performance. (Even if memory is considered cheap too, we are losing LOCALITY...) It seems then SxS should win. I wish it were easier to do and supported on older platforms. Hopefully, with time both issues will be mitigated.
  • Anonymous
    April 04, 2008
    PingBack from http://drinksairportsblog.info/antimail-what-is-your-preffered-deployment-strategy-sxsgac-or-xcopy/