-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AltCover.Prepare
copies wrong FSharp.Core
into Output directory
#68
Comments
I think I see the issue here -- the defensive copying of FSharp.Core is based on .net framework world thinking; there needs to be a check for whether any of the assemblies being instrumented already reference it out of the nuget cache. Also, I need to fix the |
Let me know if you need additional info, currently I think this should be straightforward to reproduce but maybe not Regarding the defensive copy: If it isn't there we shouldn't copy it and if it is there we should copy only the exact same version. |
Pre-release build 6.0.703-pre available for testing. Should address both issues, the unnecessary copying of FSharp.Core, and the need to create the report directory in advance. |
Wow that was fast :) Will probably take me a bit to test |
The change is in the new release, too. |
Indeed it seems to solve the problem, thanks for the fast release! |
I'm not quite sure why but our build started failing and I can basically pin it down to the
AltCover.Prepare
task copying a wrongFSharp.Core.dll
into the output directory. This issue either appeared when updating packages or when changing the target framework fromnet461
tonetcoreapp2.2
Basically we included AltCover like this (in a separate targets file we include):
and call it like this:
Result (when you delete the Workaround line):
Note: A regular "build" doesn't copy any
FSharp.Core
into the output directory, we have the nuget package4.6.2
referenced and 4.5.0 is copied to the directory.Note2: To Debug
I run the project with the debugger in the above state and the issue is a regular exception about unable to find the correct assembly. The bad reporting is not related to AltCover (which I initially thought) but can be reproduced by just running
dotnet run --no-build
in the above state.The text was updated successfully, but these errors were encountered: