Is using GACUtil in your coding/svn/development workflow considered Bad Practice?

1
votes

There's plenty of information/blogs/msdn articles around on NOT using GACUtil in your Deployment/Release scenarios and that MSI or another windows installer technology is a far better option.

However is it still appropriate to use GACUtil in your Development work flow.

We have a number of DLLs that are strong named & referenced from the GAC. In order to keep the development team in sync, once a new version of the GAC-able DLL is generated it's automatically added to all other developers GAC's as part of their daily trunk checkout. Workflow goes something like:

  • A Developers makes a change to one of our GAC-able assemblies, tests it locally, and once signed off, compiles a release version of the DLL
  • Release version is copied from \Project_DIR\bin\Release*.dll -> \COMPANY_GAC\Current*.dll
  • Other devs run our Source Control check out batch scripts which:
    • Check out newest versions of COMPANY_GAC\Current*.dll
    • Run GacUtil.exe on each DLL

This has worked for us up until now, but it's getting a little more complex with: - Larger Team, more stringent management of GAC Changes. - CLR2.0 & CLR4.0 compiled Company_Gac assemblies requiring different versions of GACUtil.exe - Managing assemblies on Build/Integration Servers which have multiple feature branches (and hence having to hot-swap different GAC Dlls)

Should we be looking at something more robust that GACUtil & Scripts to manage this?

One consideration was to roll something ourselves in powershell to check the Assembly type and add the assemblies to the correct GAC. Has anyone done this?

Any other suggestions on how developers manage their GAC workflow would be welcome.

1
version-control.net-4.0gacgacutil

1 Answers

2
votes

Not using gacutil.exe during deployment is an easy one: it isn't available on the target machine since it is a Windows SDK utility and it is not a re-distributable component.

Using it during development certainly isn't popular. Most typically you'd use a solution with the dependent projects included so that you'll automatically get the latest build with local deployment and no need for the GAC. That goes well up to a point, build times can require starting distributing swords when the solution gets too massive.

No magic solutions past that point, the GAC certainly helps to get build times down again. In general, churn in the foundation assemblies should start with minus 1000 points, they can cause a lot of pain. Save them up for only, say, weekly release updates. Off hand, there's also the core need to get all this stuff properly installed on the client machines. If nobody has focused on that yet, maybe now is a good time to get that solid. Which automatically gets debugged when everybody uses it to get the assemblies they need on their machine.