Hi, thanks for sharing this issue!

I can understand the frustration behind looking at the wrong source file (earlier versions of NCrunch did this to me very often).

NCrunch basically fixes up the stack traces through its instrumentation. Because the instrumentation doesn't support C++ assemblies, the stack traces don't get adjusted. This problem also appears for projects that have instrumentation disabled for one reason or another.

The issue is already on the backlog, though I hadn't considered that it would also impact non .NET assemblies. Thanks for bringing this up as it definitely helps with prioritisation.


Cheers,

Remco

Setting files as read-only is certainly one way, but this would also make the workspaces less aligned with the foreground solution (i.e. where the files are not read-only), increasing the risk of people experiencing unexpected problems. One quick-fix could be to simply remove all stack trace navigation for files that are inside the workspace, so there's no way you can open up a workspaced file using NCrunch. It is, of course, better to just translate the paths if possible :) I may have an opportunity to do something about this in the 1.43 release. I'll see what I can do!

Cheers,

Remco

Remco,

This does seem to be fixed for C++ (thanks), but I'm now tripping over it on .TS (typescript) files.

Can you just stop nCrunch opening ANY files in the IDE which are located in the temporary build folders? Frankly I don't care the response is a flashing purple modal exception dialog with a loud bell sound, just don't open the wretched temp files in the IDE. I waste so much time making changes to the wrong file and then wondering why nothing's rebuilding...

Unrelated, but while I have your attention, does 2.0 fix the long-standing bug in the test window tree control, where you have to left click an item before right clicking it for a context menu? That's been driving me made for 18 months too...

Great product though, keep at it.

Hi -

Sorry to resurrect this thread, but I'm currently trying to establish how you've managed to navigate to a source file in the NCrunch workspace using Visual Studio.

Do you remember how you opened the file? Was this done via a hyperlink in the NCrunch Tests Window? Or a mechanism that didn't directly involve NCrunch?


Cheers,

Remco

Thanks. I've had no luck in reproducing any issues where NCrunch allows hyperlinking to files inside the workspace through the Tests Window... the fix released 10 months ago included code specifically intended to prevent this from happening, which is why I'm confused about how it's managed to happen in your environment.

My suspicion at the moment is that something in your environment opened the code window in response to something else happening ... perhaps a debug event of some kind? Do let me know the details if you manage to get it to happen again.

I've just sent you, via the contact form, a screen shot of it. It's definitely a hyperlink in nCrunch pointing to the temp location, and it's definitely me clicking on that hyperlink which opens the (wrong) file.

It's in an excessively complex solution which would probably take you as long to open as it would me to zip up all the dependencies, so I'll try and build a simple repro.

Will

[Update: I just created a solution from scratch which repro'd this instantly here - so I can definitely help you track this down - I've mailed the whole lot to the support email address.]

Ah yes, the decision to treat file paths as simple strings in .NET blights us into its second decade... Glad you found it, anyway.

Absolutely! You're welcome! And thanks for taking the time to report the issue :)

Hi,

I'm sorry to hear that this has costed you time. Since this issue was first raised, there have been several fixes to avoid NCrunch from introducing any kind of hyperlink from the UI into files in the workspace. It should now be impossible to navigate to a workspace file via NCrunch, though of course NCrunch cannot control the behaviour of Visual Studio's debugger.. so I'm not sure if there's much I can do about this specific situation.

C++ is a very complex area to play in, largely because the build process for it is much more sophisticated than that of other languages used by Visual Studio. It took years of trapping and fixing build issues for NCrunch to reach the current maturity it is now at for C#/VB.NET/F#, and I expect that with considerable focus, it would also take much time to reach the same level with C++. Because C++ is not a language targeted by NCrunch (i.e. it is not supported by the instrumentation nor is there integration with C++ test frameworks), there is very limited value in trying to reach rock-solid build support for it. The only way this would become viable is to fully expand NCrunch support into C++, which is a major project for which no plans currently exist.

So C++ build support is just best effort at the moment. You're welcome to report specific issues that you experience with it and I will look at ways to try and improve things, but the priority is on C#/VB.NET/F# for now.

Yes - this is definitely one way the problem can be solved, or at least managed better.

There was a feature recently added in NCrunch that can disable the auto-build for certain files in the solution. This configuration setting was based off wildcards and could be adjusted at project level. It is possible that a read-only-applying setting could be introduced along similar lines.

My first preference though would be to have this solved using a pre or post build step in your project. The list of configuration settings for project files is getting longer and longer in NCrunch, and some people have mentioned they feel a bit daunted by it. I'd rather use a new config setting as an absolute last resort.

If writing a script to do this in your build process ends up being particularly untidy, you might want to look at MSBuild's item batching features. It's possible to create a custom MSBuild target that can batch compiled files over to command-line invoke or custom build task to set the read-only flag.