Luciferius;7702 wrote:Yes, with Fody I add some additional attributes above all test methods in all test projects. For this I need the "FodyWeavers.xml" file as config file inside the source directory of the test assemblies. Because they are all identical I have just one config file which I copy with the above pre build step into each test folder. The pre build step only exists inside basic test project which is referenced by all other projects. As I explained above this reduces the maintenance overhead for me when I create a new test project. With ncrunch I have seen, that there are separate folders for each test project and their sources. Therefore this pre build step only copies the "FodyWeavers.xml" file into the basic test assembly, but not into any other assembly. This in the end leads to build errors.
A possible, but not the best workaround would be to exclude the Fody task from the build, if that is even possible. Better would be a possibility to copy the config file to every test project as I do in the normal environment.
Gotcha. This makes sense, and we can make this work with NCrunch .. but it will need to be redesigned slightly.
For NCrunch to do its work, it needs to be able to separate each project from the parent solution. Although there is a certain level of emulation that it can perform to do this (like making a fake $(SolutionDir)), projects do still need to have a certain level of atomicity. This means that it isn't really possible to have one project that implicitly copies files into the working directory of another project.
The solution to this is to have a pre-build step inside each of the test projects so that each one can copy the config file into its own working directory. For NCrunch to be able to perform the build step, each test project will also need to have a declared dependency on the file that needs to be copied - this can be done using either the 'Additional files to include' setting (for each project) or by including the file inside each project using a build item inside the project XML.
I realise this probably is going to seem rather repetitive as you'll end up with the same copy logic inside each test project, but there is a way to re-use this logic by including a custom build targets file. If you create your own .targets file and <Import> this into each of your test projects, you'll be able to place both the build item and the pre-build step inside this .targets file. Having a shared build targets file is also very useful to have if you need to introduce other common build logic in future.
I hope this makes sense .. do let me know if you need me to clarify the above a bit further.
