Search code examples
.netreferencegacsetup-deployment

Differences (from the deployment point of view ) between adding a reference to an assembly from GAC and an assembly NOT from GAC?

What happens when I add a reference which is located in GAC (%SystemRoot% \assembly) to my project and an assembly located NOT in GAC (from the deployment point of view)? I mean differences between adding SHARED references and Private references to a project from the deployment point of view?

Solution

  • We generally do not use GAC and prefer to stash all dependencies in the %installdir% folder itself. I guess this is what you are calling private references as opposed to GAC installed shared references. Here are my reasons why.

    1. GAC requires the assemblies to be versioned and strong named. While dot net does provide some excellent versioning means, it also does confuse the hell out of the (noob) programmers. Here comes the full burden of assembly-version, file-version, application-version and knowing what sort of changes in an assembly impacts which of these version. Also that GAC and strong name only bothers with assembly-version.

    2. Versioning impacts patching. With GACed dlls, patchig is problematic, if not impossible.

    3. Installation to GAC requires admin rights. This is a huge problem if a big chunk of your target audience is of corporate users and your app is more like trialware.

    4. GAC dependent apps are not xcopy distributable. It has to be properly installed by a installer. My app for example carries a command line utility. Things like these are not generally supposed to be installed. People expect the exe to copy/paste between computers. All I need to do is to ask them to copy the whole folder instead.

    So from deployment point of view, GAC is not-so-beneficial. It does give some performance benefits because of being ngened, but that shows up only if the performance bottleneck is CPU. My app has perf-bottleneck at network and DB, so native code does not help. This might not be your case though, so evaluate your options.

    One another thing is that not using GAC does not hurt either. I have four apps bundled in one installer. User ticks which of them to install. All have 90% common DLLs. When installed those 90 dlls does repeat in all the application folders (program files\myapp1, myapp2), but the installer is intelligent enough to carry only one copy of all of them. So installer size does not increase. The installed size increases, but that rarely matters in today's Tera byte disks. Nobody pays attention to what the installed size of an app is. All are people concerned about, is the time it takes for the installer to download. GAC does not help there.

    Of course framework DLLs, those which come with dot-net framework itself, are best to use used from GAC and not carried along.