Build fails with project reference outside solution root

I have a large number of repos that are normally built as nuGet packages, but from time-to-time it's practical to just attach projects together in a solution. This solution will contain ProjectReference includes that are outside the solution root (since they are from different repos).

In VS this builds just fine, and in LiveUnitTesting I can specify a "root" folder for testing that's higher up the tree than the Solution, so that works ok too. nCrunch is failing to build, however, complaining about:

The type or namespace name 'Foo' does not exist in the namespace 'Bar' (are you missing an assembly reference?)

The namespace actually in the project that is referenced in via the aforementioned ProjectReference.

I kinda assume the issue is to do with the solution root, but does anyone know of a workaround for this or is this a proper bug?

Anecdotally - I created some "direction junction symlinks" to relocate the distant projects into a subfolder of the main solution, restarted VS and the nCrunch stack fully builds and runs now.

So I guess if you found this, I created a folder inside the solution root called "_imports" but that's not material.
Then I used "mklink /J" to create links to my distant projects and re-locate them inside the solution.

I set the junctions low enough that VS can see all the git folders and it is showing multiple repos as well. So far, so good. Bit of a hack though.

Hi, thanks for sharing this issue.

NCrunch itself actually doesn't care about the solution root. It's possible to have projects specified well outside the solution directory and the tool should be able to find them - but it's important that these project reference each other using correct relative paths specified using ProjectReference elements (absolute paths won't work).

I suspect there is something else going on here that is throwing out the NCrunch build. If you'd like me to examine the problem in more detail, the next step would be to submit a bug report after you've enabled NCrunch and the build has failed. I can then examine the log to see if there is any obvious misbehaviour. Understanding that you've found a workaround for the issue, whether you want to proceed with this is up to you.

Remco wrote:Hi, thanks for sharing this issue.

NCrunch itself actually doesn't care about the solution root. It's possible to have projects specified well outside the solution directory and the tool should be able to find them - but it's important that these project reference each other using correct relative paths specified using ProjectReference elements (absolute paths won't work).

I suspect there is something else going on here that is throwing out the NCrunch build. If you'd like me to examine the problem in more detail, the next step would be to submit a bug report after you've enabled NCrunch and the build has failed. I can then examine the log to see if there is any obvious misbehaviour. Understanding that you've found a workaround for the issue, whether you want to proceed with this is up to you.

Well the workaround is a PITA and I would prefer not to have to do this every time. Happy to share the build logs but there's not too much to see from my initial take - the project in question was not even mentioned in the log at all!

Note that while I'm happy to share the logs I can't do that publicly. Shall I raise a ticket somewhere?

RichardHauer wrote:
Well the workaround is a PITA and I would prefer not to have to do this every time. Happy to share the build logs but there's not too much to see from my initial take - the project in question was not even mentioned in the log at all!

Note that while I'm happy to share the logs I can't do that publicly. Shall I raise a ticket somewhere?

There's an option under NCrunch that allows you to submit a bug report (it's in the NCrunch menu). If you use this option after the build has failed, it'll let you submit an encrypted copy of the internal log of the engine that covers the point of failure along with any major configuration that may be involved. The log isn't always certain to give me the information I need to solve the problem, but it's usually a great place to start because of its convenience.