I just downloaded the beta. This is the first time that I have used NCrunch.

I cannot run any tests with NCrunch. The Tests windows shows either ? or Bx next to every project. A sample ? project shows:

ERROR (Internal): System.Exception: Unable to find build task for dependency: [SnapshotComponent: Mitutoyo.MiCAT.CIF.Hoops.CLI, 42, 40383818]

Looking at that project (with a Bx), there is an exception. I list that below, but it is long so I will continue typing here. The symptom is a bad path that looks like a bad path concatenation:

C:\src\QC-CAT\Main\Source\Mitutoyo.MiCAT.CIF.Hoops.CLI\C:\src\QC-CAT\Main\Source\PropertySheets\..\obj\Mitutoyo.MiCAT.CIF.Hoops.CLI\Win32\Debug\nCrunchTemp_d3a2d15f-3a00-4aab-86b3-d58e4228abbeResolveAssemblyReference.cache'

You can see that a C:\ rooted path has been appended to another C:\ rooted path.

Here is the exception from the Test window.

System.Exception: An exception was thrown in the remote environment: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.IOException: The path 'C:\src\QC-CAT\Main\Source\Mitutoyo.MiCAT.CIF.Hoops.CLI\C:\src\QC-CAT\Main\Source\PropertySheets\..\obj\Mitutoyo.MiCAT.CIF.Hoops.CLI\Win32\Debug\nCrunchTemp_28350c01-e934-44da-aeb3-3661dc8457e8ResolveAssemblyReference.cache' could not be processed because it is not of legal form
at nCrunch.Common.IO.DiskPath..ctor(String absolutePath, Boolean pathIsChecked)
at nCrunch.Common.IO.FilePath..ctor(String #=qiqzD$6rDXghdJBhCeunhdJj432iWhcch2Q6K8oW7oh0=, Boolean #=qHPM_oft6QRt0oSk5BA6eB9jJ01WW7HZdJH8bBwnfwpg=)
at nCrunch.Common.IO.FilePath.FromDirectory(DirectoryPath directory, String fullFileName)
at nCrunch.Common.IO.DirectoryPath.GetFile(String filePathRelativeToDirectory, Boolean noPathVerification)
at nCrunch.Compiler.RemoteBuildRunner.#=qxdXHvX7_2D7VKl6i7$25w30I2tBEFoR80oNrd_htiflja1KdImp1pwe72BdR12lJ(DirectoryPath #=q08$UUHYkzOncfCKvfofER_zZ4QQQNlvMGUDTCcC3ZzU=, String #=q08dZWTGwRP9I6rhpoIM8eUtcx6YTqlOJ8iynfsn9SKQ=)
at nCrunch.Compiler.RemoteBuildRunner.AnalyseComponentBuild(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.#=qasQjbyXk1XCi6i$viTK7bBtYPgdO4OCtt$ydiyoCMWo=(CallMethodMessage #=qOAe_koMfKeBgNzINYJMLYQ6EsEwxDr7rIUA0QLwO4VI=)
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.ProcessMessageReturningResult(Byte[] data)
at nCrunch.TaskRunner.Ipc.RemoteInstance.#=q4Msyv_qKcoBd77JGMpCTnA==[T](Byte[] #=q_2cVtqai_8qvPQQGDIGD2w==)
at nCrunch.TaskRunner.Ipc.RemoteInstance.Invoke(IMessage msg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at nCrunch.Compiler.IRemoteBuildRunner.AnalyseComponentBuild(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.#=qtL6q6sSBceddHDiqa4FAtSme5sQ4C_B6SoDAWZ9cWNE=.#=q9Dq3TYKPn2EGYFEXxElGtSRZ_7Rgqo894Pe8yyIQCzSJRpKSs8UIxIxPLRaLoJ0z(IRemoteBuildRunner #=q7_Dk_JXc$x573TjoLkHUhVghZeUYB52TWkg8sULl6Ls=)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.#=q$YUIubkdoewVMMAVblv0dle94tSx9zRsRnr815VhTqTmSTslJhWAe7hUdqW6dwwk(Action`1 #=qrLtBog8EFP51BYsrEdl3hQ==, ProcessorArchitecture #=qv6govqAV_yxWuZszGiCVg6vaUcf0HYYQv5JoEU17Gi8=, GridClientId #=q4u8l98HDOM1QuEeATIjSKA==, IBuildableProject #=qd5ir4hPpPH2Xu2Mx16VgNbh9j$dWdTCrPnAxReewOiU=)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate, ProcessorArchitecture processorArchitecture, VisualStudioVersion vsVersion)
at nCrunch.Client.ComponentLoader.SnapshotComponentFactory.#=q4ObbZigyzFk5Z0rlv7CQipbVyAR7FxRaBoC$naWVG1A=(ProcessorArchitecture #=q3VbfAUHI5ndKl44pvfdl9VIpTgXe5$oTvdtmRwZB3Uk=)
at nCrunch.Client.ComponentLoader.SnapshotComponentFactory.CreateSnapshotComponentFromXml(FilePath projectFilePath, BuildXml projectXml, FilePath solutionFilePath, String[] additionalFilesToIncludeAtSolutionLevel, Boolean isLoadedFromFile, ISnapshotConfig snapshotConfig, VisualStudioVersion vsVersion)

In the future, should I post either a bug report or a forum post, or both? Thanks.

I've had a bit of a dig through this one, and I'm wondering if you could share some more details about this project.

Which language is it written in? Does the project have any absolute file paths in it? Is there any chance you can share the .proj XML with me? You can submit this through the support contact form if you're not comfortable with placing it here in the forum.

For some reason, it looks as though this project is overriding the MSBuild BaseIntermediateOutputPath property with an absolute path - where normally this should be a simple relative 'obj' value. It isn't clear to me at the moment if the code responsible for this is inside the project itself or whether there is a related SDK/library that is manipulating this value. Absolute values tend to wreck havoc with NCrunch as they prevent the engine from properly shadowing the project into a workspace.

Something that may work to override behaviour in this instance is to introduce a new property value into the project XML, as follows:
<PropertyGroup>
<BaseIntermediateOutputPath>obj\</BaseIntermediateOutputPath>
</PropertyGroup>

.. This will force the project to use a relative intermediate output path, possibly getting the project past the analysis step that it's currently failing on ... although as I'm not yet sure why the value is wrong in the first place, there may well be other dragons hiding in here...

Cheers,

Remco

I just upgraded from v1.48.0.5, and now I have run into this issue, too. This was not a problem in v1 of the product.

The relevant portions of my C# project file are below:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
<DebugSymbols>true</DebugSymbols>
<OutputPath>$([System.IO.Path]::GetFullPath('$(MSBuildProjectDirectory)\..\..\..\output\Win32\$(Configuration)\bin\'))</OutputPath>
<DefineConstants>CODE_ANALYSIS;DEBUG;TRACE</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<RunCodeAnalysis>true</RunCodeAnalysis>
<ErrorReport>prompt</ErrorReport>
<CodeAnalysisRuleSet>..\..\..\CorepointDotNetMinimum.ruleset</CodeAnalysisRuleSet>
<BaseIntermediateOutputPath>$([System.IO.Path]::GetFullPath('$(OutputPath)..\obj\$(MSBuildProjectName)\'))</BaseIntermediateOutputPath>
<IntermediateOutputPath>$([System.IO.Path]::GetFullPath('$(OutputPath)..\obj\$(MSBuildProjectName)\'))</IntermediateOutputPath>
<RegisterForComInterop>true</RegisterForComInterop>
</PropertyGroup>

As you can see, we have full paths specified in several places (making use of some System.IO.Path processing). We have well over 100 C# projects, and we build to a common output directory. Using full paths like this has some advantages for us:
- It is far simpler to verify that the various build directory settings are correct, since they are all based on the root of our source tree. The only exception is the <OutputPath> element, which needs to be set up with the correct number of ".."s.
- When moving projects around, it is easier to adjust the paths to point at the right new location since there are fewer places to adjust.

It would be great if NCrunch handled this in some fashion; as it is, NCrunch v2 is just refusing to work at all. Unfortunately I'll need to work in v1 until this is addressed.

That new installer did the trick for me - thank you!

+1 on the fix. I had the same problem with some of my projects and the build you posted above worked beautifully! Thank you.

I can see those option, but it looks like I need to set those by hand per project. There are about 25 project x 2 fields. Does that mean I need to manually set 50 textboxes each time I change either the configuration or platform in VS?

This posting became long. You can go to the end to see the summary.

Ok. I sorted by column and made the edits. I set Configuration first. That went as expected. Then I clicked into Platform. I began typing x86. However, only x showed. So I typed x86 again. Then only 8 showed. I waited a moment. Tried typing again. The text that I typed disappeared. Then I waited for about 30 seconds. I saw the text change a few more times. I waited some. Then the cursor started flashing normally. I was able to type x86 without a problem.

So it seemed changing the first value perhaps started some process which interfered with expected behavior of the second textbox.

Anyway, that changed the affected projects from Failed to NotBuilt.

The next problem was that various CLI and Native projects were failing because header files could not be found. In VS those files are listed under External Dependencies folders. I selected the "solution" entry in the Tests window and added an expression to include other files. In particular, I added the parent folder of a number of other folders that hold a bunch of header files. NCrunch began to reload the projects. However, it took a long time. Perhaps 6 times longer than before. Any chance that code code could be optimized?

NCrunch has become rather unresponsive. My computer has too, but not as much as NCrunch. For example, I can right-click on an item in the Tests window, select Configure selected component, and it takes about 30 seconds for the dialog to appear.

Ok. I think I understand what is happening. The Queue windows shows 10 tasks being processed. They are builds of native libraries. They are taking a very long time to build. I could build the entire solution in VS in about 2 minutes. NCruch has been building now for about 15 minutes and is still building. It is really pounding the drive, so I think that explains why my computer is so slow. I think now it has been about 20 minutes and still NCrunch is building. It has taken a while to type this because of how slow my computer is running.

I have now managed to get VS to stop. It took killing NCrunch processes and then waiting. Now my computer is responsive again.

In summary,
1. Using multiselect in the test window allowed me to set the configuration and platform properties. Good.
2. Since then my computer started becoming less responsive. Not good.
3. I then added extra directories so that NCrunch could find "missing" header files for our native code. Those projects were no longer showing as failed builds. Good.
4. NCrunch then started building. Instead of taking 2 minutes to build the whole solution, I had to stop VS and kill NCrunch processes after 20 minutes. Bad.

Any ideas? Should I try 1.4 instead of the beta?

Thank you very much for many options and detailed explanations about them.

I removed the solution level includes and that solved the performance problem. Of course, I am back to the previous issue which, given how NCrunch works, is a problem with out solution. I think that I need to begin a process of talking to various teams here about how to change our solution to solve these issues. Then I will come back to NCrunch. I really want to get continuous testing working.

One possible outcome of this is that no significant changes will be made to our solution because it currently builds and works. A consequence of this is that I would need to have NCrunch ignore the problematic projects but still have those projects included to build and test. Hopefully the "Additional Files To Include" option will work in this case. I can manually edit the NCrunch projects to include the specific files that have been ignored. As you wrote, this will require the rebuilding that you mentioned.

Perhaps I can write a Powershell script that can examine the VS projects and the ignored projects and update the NCrunch projects. At least this would make maintenance of this situation simpler.

I tried ignoring some projects. Now they do not show in Tests window, as expected based on documentation: "will cease to exist in the tests window and processing queue". Is there a way to list ignored projects so that they can be unignored? Or do I need to manually find and edit the NCrunch files that have the setting and edit them?

I keep repeating myself, so here I go again. I really appreciate the prompt and detailed help. Thank you very much.

tl;dr skip to the bottom summary.

I do appreciate your situation regarding limited knowledge about our processes here. I too have that limitation. We have seven teams distributed around the world working on the software. It is not always fruitful for one person to try to change how everyone else works because the one person wants to try a new tool. I do not mean this in a critical way. I think it makes sense because there is work to be done, and process improvement is only one part of that work. There is management support for continuous testing. Adoption by the teams will likely be gradual. And then there are the people who are working on native code and CLI code who won't be able to use a tool that works well for C#.

The motivation for my current thinking is that I want to get NCrunch to work. I also want to do so with ideally no changes to our solution because I do not want to disrupt current work with unknowns that could appear. Hence, I think I would like to try writing some adapter that will introduce fixes. If I spend a few days doing that and get NCrunch working for most managed code without requiring changes to the solution or current process, that will be a good way to start. We can evaluate NCrunch without committing to any changes to out process otherwise.

I think this will work because I plan to exclude all the CLI and native code from NCrunch. At that point I hope getting managed code to work will be easier.

Summary:

Anyway, I think the MSBuild property will be a good option eventually. I hope to leverage the other build options in the NCrunch projects. For example, instead of manually ignoring the project, I will have a script ignore the project but add the library as an additional file.

However, this work will happen piecemeal over the next month at which point I will have more time. (After a milestone.)

Thanks again.