"System.InvalidProgramException : Common Language Runtime detected an invalid program." when running some tests about minicover HOT 11 CLOSED

I do not have the issue with 2.0.0-ci-20180517205544

from minicover.

@bhugot I can't share the actual code generating this but I can try to come up with a reproduction.

from minicover.

would be very helpfull

from minicover.

I tried to write a new minimal test case based on one of our failing tests, but I could not get it to fail. So, I've taken one of our internal solutions, pared it down, and made some naming modifications. It's probably not as small as it could be but it does reproduce a failing test. See saxonww/minicover-failure for the project.

I can build this project in VS2017 and run the test with no errors. I can run dotnet test on the test project with no errors. But if I run dotnet test while instrumenting with minicover, I get a CLR failure.

Note that I don't think this code would actually work, it just compiles and the test completes successfully (or not). The original project does work and produces output that is in active use; the exception and stack trace are the same in the original vs. this altered version so hopefully it's a good indicator for what's going on with minicover.

from minicover.

Hello thanks for sharing, your problem was fixed with the last version

from minicover.

Hi! I have the same problem in my CI-pipeline (I assume that this is due to the fact that the command dotnet test was launched with minicover instumenting because without minicover instrumenting the dotnet test command completed without errors) with version 2.0.0-ci-20180329054201, but if I use the Minicover version 2.0.0-ci-20180328123752 then tests ran without this error and code coverage analysis was finished successfully.

from minicover.

@bhugot I've verified that all of our tests work with 2.0.0-ci-20180329054201. Thanks for looking at this!

from minicover.

@Valeriy1991
Is there any chance you inverted the versions on your comment above?
Version 20180329054201 should be the good one and 20180328123752 is the one with issue.

from minicover.

I also am experiencing this issue with 20180329054201, but NOT with 20180328123752. I can't share the code under test, sorry.

from minicover.

I have the same issue for both versions. After some digging, I noticed this only happens if I provide --configuration release setting to dotnet build. with --configuration debug, or with no configuration setting at all, it works okay.

Also another weird issue is, the coverage report differs for different dotnet versions. 2.1.4 and 2.1.101 respectively. The same files are listed with same number of lines but number of covered lines are quite different.

Edit: Different coverage reports are not caused by different dotnet versions. On a regular Ubuntu 16.04 both versions create the same result. But somehow, on Microsoft provided VSTS build agent Docker container (also Ubuntu 16.04) the results are different with dotnet 2.1.101.

from minicover.

@saxonww @Valeriy1991 @SapientGuardian
Can you please check if you have same issue with version 2.0.0-ci-20180517205544?

from minicover.