Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Code analysis doesn't work if copy of assembly is in GAC
Options
Previous Topic Next Topic
AndrewSwerlick
#1 Posted : Thursday, September 1, 2011 1:38:07 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 9/1/2011(UTC)
Posts: 7
Location: Cincinnati OH
I've encountered an issue where the code coverage analysis piece of ncrunch doesn't work if a copy of the assembly under test is in the GAC. This happens frequently when doing sharepoint development, since all sharepoint development has to be done on the server, and sharepoint deploys the assemblies to the GAC when the solution is registered with sharepoint.

I suspect the issue is deeper than ncrunch, because this generally causes issues with pretty much all the test frameworks I use but I figured I'd see if anyone knew of a solutions for this issue.
Back to top
Remco
#2 Posted : Thursday, September 1, 2011 7:06:10 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
The underlying cause of this issue has a great deal to do with the prioritisation of assembly resolution within the .NET framework. The CLR tends to favor assemblies in the GAC, giving them priority over all other accessible assemblies. Even binding redirections seem unable to work around this problem.

A crazy idea that may help to work around this could be to make sure that the version number of the assembly used by NCrunch is different to the one that is registered in the GAC.

I'm not sure how difficult it would be to rig this up in your infrastructure, but whenever NCrunch is building a project in MSBuild, it sets an MSBuild property '$(NCrunch)' = '1'. You could use this property to introduce a hack in the .proj file, overriding the MSBuild properties to change the version number in the output assembly. In this way, the assembly instrumented by NCrunch will have a different strong name to the assembly hosted within the GAC, and therefore the CLR won't pull hook up the wrong one to the test application domain.

I'm keen to hear if this fixes the problem ... if so, I might look at introducing a configuration switch that could fix this without the need for custom build hack.
Back to top
AndrewSwerlick
#3 Posted : Friday, September 2, 2011 3:03:18 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 9/1/2011(UTC)
Posts: 7
Location: Cincinnati OH
Remco,

I played with this, but I don't have alot of MSBuild experience, so I couldn't quite get it to cooperate. I tried just adding this to the .proj file

<PropertyGroup Condition="'$(NCrunch)' == '1'">
<Version-Major>99</Version-Major>
<Version-Minor>99</Version-Minor>
</PropertyGroup>

But that had no effect. So instead I tried a manual approach . I changed the version number in Assembly.cs, and then let Ncrunch rebuild without copying the new assembly to the GAC. Code analysis came back on fine. So in theory, with the right set of MS-Build commands it should work fine, I just don't happen to know what those are.

For the mean time, I'm fine with removing the file from the GAC and manually adding it back when I'm doing UI testing and need it.
Back to top
Remco
#4 Posted : Friday, September 2, 2011 6:50:55 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
It looks like a way to set the assembly version using MSBuild is by download a set of build extensions and including an extra build target. You can then use some specific properties in the same way as you have above to define the version number. Have a look at (- BROKEN LINK -)(- BROKEN LINK -)[/url].

Another way I can think of would be using a compiler conditional (#IF) in your AssemblyInfo.cs to swap the version number based on the build configuration. You can change the build configuration that NCrunch uses by adjusting NCrunch's UseBuildConfiguration property on the target project (build configuration will default to 'DEBUG'). However, I expect you may need to introduce a whole new specialised build configuration to every affected project, which could be rather tedious, though this approach would probably also work for testing tools other than NCrunch.
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.034 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download