Hi, thanks for posting!

My first thought is that the post build event is trying to copy files that don't exist in the NCrunch workspace. This is most likely because the files aren't referenced in a way that NCrunch is automatically aware of them. Try adding the following value to your additional files to include configuration setting for this project:

..\packages\**.*

Does this do the trick?


Cheers,

Remco

Great, that's progress! I'm wondering if the DllNotFoundException is being caused by libgit2sharp making assembly colocation assumptions. A quick fix to this may be to turn on the copy referenced assemblies to workspace configuration setting.

Is this exception being thrown during test execution? It may be worth right-clicking on the project in the Tests Window, and going to "Advanced->Browse to workspace" if you'd like to compare NCrunch workspace files with those in your normal working solution. This is often a quick and easy way to examine whether every file is where it should be.

My guess at the moment is that the post build event is copying the files to the build output directory of GitClassLibrary, although either the test code or the code under test is trying to find the files in the build output directory of TestProject. When running the tests outside of NCrunch, both of these output directories will likely be the same, but in the NCrunch test environment, they are different. The 'Copy referenced assemblies to workspace' option will automatically copy GitClassLibrary into the TestProject output directory, but it won't know about the NativeBinaries directory and thus won't copy it.

Is it possible to also set up the post build event so it will work on TestProject?

Just noting earlier you mentioned that this was a test solution you're working with. If it's something you can share, feel free to submit it to me through the contact form and I'll see if I can find a way to make it work.

Hi Martin,

Thanks for sending through the sample solution. I've managed to get this to work by turning on the 'Copy referenced assemblies to workspace' option for ALL the projects in the solution. It looks as though the issue was that ALL dependencies needed to exist in the build output directory of the test project, and the nested dependencies weren't all being copied without the configuration setting being applied to everything.

The reliance on this configuration setting is unfortunate as it will create more build work for NCrunch while you are coding. Sadly, it look as though the assumptions around assembly referencing are coded into Libgit2sharp itself, so there may not be any other way to make this work without changing the library.

Cheers,

Remco

It's tough to give concrete advice without delving into the source code, but generally you should try to avoid loading assemblies into the application domain dynamically from the current directory. Instead, it may be better if there was a way to configure the search path for the native binaries (which are effectively resource files). As the developer integrating with libgit2sharp, you would have knowledge of where these resources are stored and which project they are primarily related to - allowing you to better control the loading behaviour by injecting a path relative to the location of your primary project (perhaps by using GetType().Assembly.Location).