thanks a lot for the discussion so far!
When you said you didn't want to install into the GAC, I had assumed that
>you wanted to leave the assemblies on a publicly available network drive. >If you're going to put them on each user's C: drive, what's the advantage >to putting it in c:\program files\whatever\ rather than in the GAC?
Well, today users can install our code on any drive they want to, i.e. they are not bound to use the drive where the GAC happens to be located. This has a number of advantages:
- Users can install to a network drive which allows other people in the network to run the same code, without requiring them to install locally (except for a few local registry tweaks). - Separating app code from OS components and user data by storing each of them on different drives makes backups easier. - If the C: drive overflows, you can still choose a different drive which has enough space.
Call me a nitpicker, but I personally hate all those apps which push lots of files (sometimes hundreds of megabytes) to my Windows system directory.... probably great for the PartitionMagic folks, but it just doesn't feel right to push half a gigabyte to the GAC. Maybe it's just me.
The other problem with the GAC is that assemblies there need to be strong-named (AFAIK), which means that we cannot change contents of any of the files during installation - please correct me if I'm wrong. This, however, is required in our case since some of the config files are updated during installation, depending on user choices and system configuration. (Actually, sometimes users change some of those "global" config files even after installation. Imagine teaching your end users how to navigate to a config file using the DOS command shell in order to bypass the SHFUSION.DLL facade.... *shudder*)
I guess we could simply exclude those config files from the assembly, but then we couldn't use gacutil to push them to the GAC; maybe we'd even have to copy them there "manually" during installation, i.e. we would make assumptions about the location and structure of the GAC, which is something we'd like to avoid.
If you put it in the GAC, you can have multiple versions installed at once.
>(Testers often think that's useful, if not a requirement for whatever >deployment solution you come up with.)
Well, we pretty much solved the few side-by-side installation issues we ever had, based on the conventional installation approach; therefore, the GAC is nice to have, but not really required for us (at this point in time). Maybe we haven't been bitten enough yet, but personally I can live just fine with a registry-based solution such as the one used for COM components.
But maybe there are other strategies. We could probably wrap all the functionality which is required into a relatively small assembly and push that to the GAC. However, this assembly (consisting of a few DLLs) would refer to symbols in and therefore depend on other (unmanaged) DLLs and executables which we'd like to hold in a standard installation directory. I have no idea, however, how to make that kind of setup work. Comments and ideas most welcome.
Again, thanks for the discussion and the insights!
Claus
[EMAIL PROTECTED] Claus Brod, CoCreate R&D Have you hugged your manager today? CoCreate Software GmbH Phone: +49 7031 951 2152 http://www.cocreate.com Fax: +49 7031 951 6152 --http://clausbrod.com --------------------------#include <disclaimer>--
=================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
