Excellent, thanks for confirming this :)
gasparnagy;18561 wrote:
(I did not expect that our changes will impact NCrunch. Can you comment on which change was problematic (if simply explainable)? Is there a way we could prevent such integration issues with NCrunch on the Reqnroll side?)
I'd need to review the changes to Reqnroll in more detail to understand fully, but I believe the problem with not finding dependencies was likely caused by changes to how Reqnroll finds its dependencies. The IoC system in place seems to expect the dependencies to be located in the build output directory, which is something that NCrunch doesn't do by default as it builds the test environment across multiple paths. It's possible this may have occurred because the dependencies are loaded by Reqnroll manually (i.e. through Assembly.LoadFrom or something similar), which would by-pass the normal resolution steps in the platform (which NCrunch hooks into). So this is kind of one of NCrunch's 'rules' that can cause problems with some toolsets. To solve it, NCrunch just copies Reqnroll.* to the output directory now, so if you introduce a similar library, it should just work fine as long as the namespace is consistent.
The loss of coverage for feature files is something that's less clear to me, as I couldn't find the change responsible for causing this. NCrunch needs to discriminate between 'content' files and 'source' files, and it does this by the names of build items specified from MSBuild. For example, a build item of type 'Compile' is handled differently to a build item of 'None' or 'Content'. For a file to have coverage markers, it needs to be considered as compiled source code. Something must have changed the build item type of the feature file as it was represented by MSBuild. To avoid this being a problem again, I've added a manual override in our Reqnroll adapter that forcefully considers any file with a .feature extension to be source code, so it basically shouldn't matter anymore.
