Hi, thanks for posting!

I wasn't aware that this property was in use - so I've made a note on the backlog to have support for it added in a future revision.

The best way to work around this problem will depend upon why you are making use of this build property. NCrunch specifically sets a number of environment variables inside its build process. You may be interested in used in the $(NCrunchOriginalSolutionDir) or $(SolutionDir) properties to try and infer the solution currently in use, then introduce an override in the project's own build logic to cater for the NCrunch use case. For example:

<PropertyGroup Condition="$(NCrunch) == '1' and $(NCrunchOriginalSolutionDir) == 'c:\projects\mysolution'">
<SolutionName>MySolutionName</SolutionName>
</PropertyGroup>

Thanks for the extra info. I have a workaround that should work for your situation using the current version of NCrunch. It's a bit creative, but I've just tried it out and it should be reliable.

The key problem is identifying inside the project file whether or not the build is running as part of a certain solution. There's no way to do this using environment variables in NCrunch, but we can infer logic based on file paths.

Normally, NCrunch doesn't copy solution (.sln) files to the workspaces of projects being built. However, you can easily tell it to do so using the 'Additional files to include' configuration option that exists at solution level. Inside each of your solutions, simply add a reference to the solution's .sln file using this configuration setting. In this way, NCrunch will copy the solution file into the workspace for each project when the project is being built, and we can then use the existence of this file to infer which solution is being used as part of the build, by introducing build logic into the project file like this:

<PropertyGroup Condition="$(NCrunch) == '1' and Exists('$(SolutionDir)\MySolution1.sln')">
<OutputPath>AlternativeDirectory</OutputPath>
</PropertyGroup>

Assuming that the 'MySolution1.sln' file is included in the 'Additional files to include' for the parent solution, it should exist at the path above whenever the project is being built as part of MySolution1. This means we can change any of the other build properties (such as the OutputPath) to implement alternative logic.

Provided MySolution2 does not include the solution file 'MySolution1.sln' in its Additional Files To Include, there's no way this can go wrong.

I hope this makes sense .. do let me know if it does the trick!


Cheers,

Remco

I just downloaded this today, and after getting it to work well in a little prototyping project I tried applying it to our main project. I've have tracked down that $(SolutionName) is not working.

NCrunch->About lists me at version 1.45.0.12

Here is the error I'm getting when trying to sync:
"NCrunch was unable to load this project because it contains a file path that is structurally abnormal and cannot be handled. The file path specified in the project causing this error is: E:\source\Trunk\ProjectA\*Undefined*.proj.props"

Here is the offending line in my project file
<Import Project="$(SolutionDir)$(SolutionName).proj.props" />

I can replace the $(SolutionName) with the actual name and it starts working.
$(SolutionDir) appears to be working just fine.

Thanks for any help on getting this resolved quickly so I can actually use this during the 30 day trial.

Jeremy