Interop.ActiveDS causes unreliable build in ncrunch

Our project uses Interop.ActiveDS and the build does not work.
When I say build the ncrunch processing queue

Are you able to give any more information about how the build is failing? I.e. the messages showing etc.

Also, if you haven't already - it's worth having a look at troubleshooting build issues in the wiki.

The problem is intermittent. When I first load the solution the ncrunch process queue reports the error below. After I 'rebuild solution' from the VS Build menu, it will be fine. I have also added a **.* as the additional files in the affected project but am unsure if this helps because the problem is intermittent.

error I get

"SGEN (0): Could not load file or assembly 'Interop.ActiveDs, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a8927aaac6c90a93' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)"

Thanks

Is the Interop.ActiveDs assembly being referenced directly from the output directory of the location it's built from? This would make sense, as rebuilding the entire solution would update the file (and therefore NCrunch would grab a new reference to it).

I have little knowledge about this assembly or how it's derived, but should it perhaps be a project reference rather than an assembly reference?



Cheers,

Remco

The interop assembly is referenced in the References folder of the troublesome project within the solution (containing many projects). I am not sure if it is referenced from the output directory. I cannot be a project reference as we did not create the ActiveDS component but Visual Studio creates the Interop.

The next time you see the SGEN failure, could you use the Submit Bug Report option in the dropdown menu? I'd like to have a look at the logfile to see what's going on.


Cheers,

Remco

Submitted

Hi, I wondered if you had a chance to look at the error log relating to this yet?

Sorry for the delay in getting back to you on this one. I've had a thumb through the report, although it looks like the log file didn't make it through intact. Did the report submission form show everything as OK when you submitted the report?

It would be great if you can try pushing another report through. Another way to get more information about the build issue is to go to your global configuration, turn on 'LogToOutputWindow', and set 'LogVerbosity' to 'Detailed'. When you select the failed task in the processing queue, you should see a much more detailed dump of the MSBuild output leading up to the error. Copy/pasting this dump into the forum is an alternative to submitting the bug report.

I've also had a bit of a look at the assembly reference you're having issues with, and it seems this is quite a common assembly with which to have issues when working between x86/x64. Is there anything more you can tell me about the target CPU for the projects you're building?

I'd be interested to know whether removing your wildcard **.* reference makes much difference in how this build issue behaves. NCrunch wasn't really designed to work with a wildcard that might also include build output files (which **.* would tend to do).

Remove **.* breaks it again immediately. There is no pattern to what breaks it and what actions make it work again. It seems completely random when ncrunch decides to build that part of the solution again. **.* seems to have a positive affect though.

After turning on LogToOutputWindow and Detailed LogVerbosity and clicking on the failed task in the processing queue I get the same amount of detailed message which is
"SGEN (0): Could not load file or assembly 'Interop.ActiveDs, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a8927aaac6c90a93' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)"

Sometimes I get this message
"
(0): Unable to find built assembly. Checked locations: C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\debug\Interconnect.Framework.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\debug\Interconnect.Framework.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\debug\CIF.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\debug\CIF.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\Interconnect.Framework.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\Interconnect.Framework.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\CIF.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\CIF.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\debug\Interconnect.Framework.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\debug\Interconnect.Framework.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\debug\CIF.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\debug\CIF.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\Debug\Interconnect.Framework.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\Debug\Interconnect.Framework.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\Debug\CIF.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\bin\Debug\CIF.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\.\Interconnect.Framework.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\.\Interconnect.Framework.exe
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\.\CIF.dll
C:\Users\JeremyBR\AppData\Local\NCrunch\6740\3\x\x\.\CIF.exe
"

I believe the **.* is acting as a crutch for your NCrunch build, allowing it to work in situations where probably it should be failing consistently .. That's a theory anyway :)

Would you be able to copy/paste the MSBuild output leading up to the SGEN failure?

Something else you can try is to set CopyReferencedAssembliesToWorkspace property on all of your projects to TRUE. This will help us identify whether the SGEN problem is a symptom of a dependency resolution issue.

It seems that the SGEN issue is caused by the build process attempting to derive a serialization assembly from a project that is set to be signed during the build.

Basically, NCrunch is forcing MSBuild to delay sign the assembly so that it has the opportunity to properly instrument it post-build. SGEN kicks in too early, and the delay signing messes it up.

I'm working on a fix for this to be released in 1.33b.

Meanwhile, the cleanest workaround for this issue is to turn off the 'Generate serialization assembly' option for your project when building in DEBUG mode. Otherwise, you can shut off NCrunch's instrumentation for this project by adjusting the InstrumentAssembly configuration option (though you will lose all code coverage for the project if you do this).

Remco wrote:It seems that the SGEN issue is caused by the build process attempting to derive a serialization assembly from a project that is set to be signed during the build.

Basically, NCrunch is forcing MSBuild to delay sign the assembly so that it has the opportunity to properly instrument it post-build. SGEN kicks in too early, and the delay signing messes it up.

I'm working on a fix for this to be released in 1.33b.

Hi - just wondering if this fix will be in the next release :)

Absolutely! :)

Everything works straight away in v1.33b - I've even deleted all of our crunch config files! Brilliant! :D