Hi,

NCrunch does use the standard build process with the command line flags in the same manner as any command line MSBuild action, and I'm fairly certain I've seen it work with /unsafe before without problems. Most likely what you're experiencing is the result of a more subtle issue. Can you share the build error you're experiencing?

Often a good way to analyse build issues such as this is to inspect the workspace used for the project by NCrunch and to try and find a way to build the project in this workspace by using msbuild.exe on the command line. The easiest way to find the workspace is to right-click the failed project in the Tests Window, then choose Advanced->Browse to workspace.

Hi Phil -

NCrunch will always use the default build $(Configuration) and $(Platform) that is specified in your .proj files. This can sometimes be a cause of confusion for people, as the build configuration in the Visual Studio IDE allows you to choose (and thus inject) different values into the build for these two properties. Basically this means that if the build settings in your project files are out of alignment if your IDE, then you may experience different build behaviour to what you are expecting.

The logical solution to this would seem to be for NCrunch to try and follow the selected build configuration within Visual Studio, although there are huge problems with this approach. The chosen build configuration can have implications for the logic and structure of the source code under test, and as such every change to the VS build configuration would need to be associated with completely throwing away all code coverage information and test results. For solutions with tests that can run through under 30 seconds this isn't a big deal, but NCrunch is often also used with solutions with test running times into the hours, for which throwing away this information would be particularly painful.

NCrunch does contain a project-level configuration setting, 'Use build configuration', allowing you to specify which value should be injected as the $(Configuration) MSBuild property. My usual advice is to try and align your .proj build defaults with the configuration and platform you would normally use while developing in Visual Studio, as this is generally better practice and can also help you when working with other tools (such as build servers).


Cheers,

Remco

Hi Phil -

I'll add the platform property to a new configuration option in the upcoming 1.42 release. It really should have been in there much earlier and I'm not sure if I can give any good reason for having left it this late.

As far as I know, the default configuration/platform in the .proj files can only really be reliably edited by changing the project XML manually. Most of the people that have problems with inconsistent $(Configuration) properties usually have projects that they've upgraded from different versions of Visual Studio. VS tends to manipulate the build configurations indirectly through the 'Configuration Manager', although I can't really say exactly what kind of rules the configuration manager follows as it is version specific and perhaps a little over simplified.

Thanks for your feedback!


Cheers,

Remco

The 'Use CPU Architecture' setting is specific to the test environment, and doesn't have an impact on the build. This setting actually exists primarily for frameworks like MSTest, where there is no clear standard between test runners which CPU architecture should be used for execution when the test project is set to build with AnyCPU. The platform configuration option will need to be a separate one for the build (although I guess there is a relation between them!).


Cheers,

Remco