Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Please provide the following information when submitting an issue.
My issue is related to (check only those which apply):
Steps to reproduce the problem:
works fine with .NET 4.6.x and OpenCover 4.6.519 but after update to .NET 4.8 I got the result above (tried also the actual Version of OpenCover 4.7.922.
So my questions are ...
Thanks for your help.
During this week and last week, all of our build servers have received Windows updates, including an update to the .NET Framework 4.8.03761.
Since then, CI Server (TeamCity) can no longer generate OpenCover reports, whether they are MS tests or NUnit tests.
But when I surprisingly open a Developer Command Prompt (elevated as TeamCity User) on the server and explicitly call the command (e.g.):
the reports are generated without problems.
It looks like no more reports can be generated if our build script is executed by the CI server (TeamCity) since the framework updates were installed...
I can darkly remember that we already had a similar problem last year. The calculation didn't work then either, because the profiler didn't seem to be able to register anymore.
After days of research, I came across this Knowledge Base article at Microsoft:
After installation of the described update from the KB-Article (windows8.1-kb4346406-x64_03d960444b42b5838683d4791c9f782b2c242593.msu)
According to Microsoft, the update is also said to have reached the normal update process:
To be clear: The patch KB4346406 fixed this issue the last time - after updating .NET framework to 4.6-4.7.2.
I guess the probability that this patch will help again is rather low, because meanwhile, according to Microsoft, this patch should already be included and Opencover does not function anymore when started through our CI-System and after the framework was updated to 4.8.0.
It is likely that using
My gut feel is that the non-interactive build process is somehow being sandboxed sufficiently that it can't perform registration, even as a user.
We also just updated our build servers to 4.8 and OpenCover now complains about no results. Here's how we're calling OpenCover (new lines added to show each argument):
@sawilde There is no such thing as ".NET framework core". There is ".NET Framework" (latest version 4.8) and there is ".NET Core" (latest version 3.0). Within a year there will be ".NET 5" (which will be actually .NET Core, removing the "Core" moniker)
I guess that you refer to ".NET Core", which is cross-platform, and therefore cannot use Windows-specific things such as the Registry.
But ".NET Framework 4.8" is Windows-only and can use the Windows Registry as usual.
For the record:
It happens that for some (likely stupid) reason most IT admins turn off UAC on Windows Server (some of them turn it off on Windows client for end users too, more stupidly) but I digress...
I don't know yet why per-user COM registration doesn't work on Windowes Server with .NET Framework 4.8, admin user accounts and UAC deactivated (and I don't have much time for further investigation) but I suspect it's a bug of .NET Framework 4.8 with Windows Server. Some pointers:
I am sure that the "server part" of the per-user COM registration (-register:user in OpenCover) works fine and Registry entries are created correctly; it's the "client part" what fails to "see" the per-user COM registration Registry entries. When talking about per-user COM registration we must talk always about the UAC feature introduced in Windows Vista:
UAC provides two kinds of user accounts: standard user accounts (no admin rights ever) and admin user accounts (admin rights depending on UAC):
Per-user COM registration and UAC are somewhat tricky:
1.1) The admin user account, which runs processes actually without admin rights (not elevated), can "see" per-user COM registration. For this reason, "-register:user" works correctly on Windows Server 2012 and Windows 10 with an admin user account and .NET Framework 4.8.
1.2) If the admin user account "elevates" a process (for example, right-clicking "Run as administrator" to launch the process), then the elevated process cannot see per-user COM registration. This is a security safeguard to prevent a process running with admin rights to use a COM DLL that didn't require admin rights to be registered (per-user COM registration writes to HKEY_CURRENT_USER\Software\Classes rather than to HKEY_LOCAL_MACHINE\Software\Classes, being HKEY_CLASSES_ROOT a fusion of both)
2.1) On the original Windows Vista, an admin user account could not "see" per-user COM registration. Since this decision didn't make much sense (with UAC deactivated the admin user account runs "unprotected" anyway so there is no point on protecting it from rogue per-user COM DLLs) Microsoft reverted it on Windows Vista SP1.
2.2) On Windows Vista SP1 and higher, an admin user account should "see" per-user COM registration...unless something breaks this behavior unintentionally. This breaking actor can be a security patch (that must be reverted or fixed) or maybe .NET Framework 4.8.
Bottom line for users hitting this issue: avoid per-user COM-registration (-register:user) as much as possible and use either per-machine COM-registration (-register) or, better yet, no COM-registration (-register:Path64, -register:Path32)
For OpenCover: at the very least, it should not fail silently when the client part of per-user COM registration doesn't work. Rather than the generic "Committing...No results, this could be for a number of reasons..." message, it should show the specific reason:
That would save long hours to users hitting this problem.
Further investigation should isolate this problem to simple code and report it to Microsoft for triage and fixing.