Hi, thanks for posting.

The .EXE file you are referring to is just a shim that invokes the runtime to load the .DLL. Because it doesn't form part of the normal dependency structure of the solution, the 'Copy referenced assemblies to workspace' setting won't automatically copy it to the test project's output directory.

I don't believe this EXE file changes as your software does, so it might be possible to simply set it up a copy of it as a resource file in your test project that can be copied to the output directory on build (i.e. basically a copy local content file).

If you can share any more detail about why you need this file in your test, I might be able to help with providing a more suitable workaround.

My understanding of this .EXE file is that it functions in the same way as calling dotnet.exe with your DLL.

If you use dotnet.exe (usually under C:\Program Files\dotnet) to call the DLL instead of calling the .EXE directly, it should be possible to run the code without requiring it.

Another option could be to use the methods available on the NCrunchEnvironment class to find the workspace that contains the stub .EXE, and copy it over manually as part of your test code.

Agreed. I've noted this down for review. I was just hoping to help you work around this limitation until I could make a fix available.

No need to configure. We have enough settings already. It should just happen, like the other files in the workspace.

I think the reason it's not happening already is because the .EXE shim must be getting generated through a separate build step that will require special handling.