Testing code in GAC deployed assemblies

Question

Quite often I have unit tests using MSTest for code that is in a GAC deploy assembly. Typically on my development machine I also have a version of code deployed to the GAC. This results in an issue when making changes in the code under test because the unit tests keep running against the GAC deployed assembly.

So, to actually test the changed code I have to re-deploy the assembly to the GAC before running the tests. Thats is quite error-prone and not easy to work with. Does anyone have a good sugestion on how to work-around this problem? I think simply running GACUtil or similar in the post-build event is not a workable solution as it might cause problems for fellow developers...

Answer 1

I would recommend you to never deploy any assemblies into the GAC on your development machine as well as your build server. Use a local copy for third party assemblies or project references while developing. This way you know exactly what you are building against and another developer who decides to checkout the code from the repository on his machine will be able to get it running very quickly without the need to install things.

Assemblies should be placed into the GAC as part of your deployment process only on the target machines.

Answer 2

I agree with Darin and I'd avoid deploying assemblies to the GAC on my dev machine. Your unit tests have to run against your local assemblies (That's why we call them unit tests, right?).

If you want to do an integration test with the entire app or parts of it deployed on your machine, just script two gacutil calls that install the assemblies to the GAC, run the tests, then clean up the GAC.

Answer 3

use other assembly version when you make changes

Answer 4

I find this to be rather annoying as well. My test project CLEARLY references the PROJECT, not the GAC'ed assembly... I'm unsure whether this is the CLR load process choosing the GAC instead of the local directory, or MSTest indicating a preference (I assume that MSTest isn't handling the appdomain's assembly resolve event, which causes the default behavior to check the GAC first).

I agree that it'd be ideal to have a separate DEV and CI/Test server... but development for SharePoint DOES involve installing assemblies into the GAC on a regular basis (required in some cases), and forcing the developer to retract/uninstall the code before UNIT TESTING, just to ensure that the tests use the correct assembly, is somewhat lame.