J e r o e n ' s   w e b l o g

Next release: "Summer Edition!"

After the release of a big project that contains lots of plug-ins, I've been thinking about a way to maintain everything in such a way that it won't consume all my time and at the same time will still be easy to deal with for my users. The entire system is built so that plug-ins can be added on the fly afterwards and that different versions of the same plug-in can all be installed at the same time (actually, this is a feature of .NET using strong names that I'm thankfully using). So I could just release lots of plug-ins as DLL-files and be done with it. In practice however, I'm a little scared that if I start throwing around DLLs that I'll have to rely on all those users putting those files in the right place and installing them. Not that the application makes it hard to do or work with, in fact the assembly cache is used so it doesn't even matter where the actual DLL is.

But what if users store these files in temp-directories, install them and see them work, only to discover that there's a problem next time they reboot and the temp-directory is missing? I'm not sure if it's wise to rely on the GAC that much. Or if they want to give a plug-in to other users? I started to think that even though it's possible to release single plug-ins, it might be better to just do this in specific cases where I want to give someone a plug-in for a special use and create full installers everytime a new plug-in is released or the framework is updated instead.

But that can get messy if I end up releasing multiple plug-ins a month (I'm not that productive, but small and important bugs are easily found and need to be fixed quickly) which leads me to think it's probably best to do a full installer release every couple of months, every three or six months for instance depending on how fast developments end up being. It's a good system: users know there's a set time when they can expect fixes and new functionality, the amount of different versions in use is limited (compared to ad-hoc releases anyway) and I can integrate the process of creating a new build into my workflow.

Comments

Frans Bouma said:

"But what if users store these files in temp-directories, install them and see them work, only to discover that there's a problem next time they reboot and the temp-directory is missing? I'm not sure if it's wise to rely on the GAC that much."
If you add an assembly to the GAC, a copy is made in the GAC, so you can even remove hte original file and still have a copy in the gac. :)
# February 8, 2005 3:47 AM

Jeroen van den Bos said:

True yes, but it's kind of risky to depend on nothing ever happening to the GAC.
# February 8, 2005 7:00 AM

Frans Bouma said:

Ok, but it's the savest thing you can have, as it has versioning build in, unlike a folder. Users can remove a folder easily, but not stuff from the gac as they need to know how.

Another thing you can try is to make an installer which has to be run under an administrator account and which installs the .dlls somewhere where only an administrator can remove them. :)
# February 8, 2005 7:51 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)