Support VS 2019

[twenzel]

Please add support for Visual Studio 2019.

[p10tyr]

It should work to be honest. Did you try?

-EDIT
You can install it but it wont work. Sorry. when I get some free time I will try and get to it.

[p10tyr]

unless the installer is locked to vs2017.. otherwise its just a config thing in the installer.
ill check

[twenzel]

That's the problem, the installer is locked to VS2017 and the Extension gallery within VS2019 does not list your extension.

[p10tyr]

I installed VS2019 and tested it. There was an issue on installer with dependancy
Please use 1.16.4 as there was some dependency that I did not need and is not installed in VS2019 anyway.

[bobted]

I have 1.16.4 installed in 2019 Pro, but get the below error when running MSTest unit tests.

System.TypeAccessException: Attempt by method 'PrestoCoverage.PrestoCoverageCore.OnTestExecutionStarting(System.Object, Microsoft.VisualStudio.TestWindow.Extensibility.OperationStateChangedEventArgs)' to access type 'Microsoft.VisualStudio.TestWindow.Controller.TestRunConfiguration' failed.
   at PrestoCoverage.PrestoCoverageCore.OnTestExecutionStarting(Object sender, OperationStateChangedEventArgs stateArgs) in C:\Projects\PrestoCoverage\PrestoCoverage\PrestoCoverage\PrestoCoverageCore.cs:line 66
   at PrestoCoverage.PrestoCoverageContainerDiscoverer.OperationState_StateChanged(Object sender, OperationStateChangedEventArgs e) in C:\Projects\PrestoCoverage\PrestoCoverage\PrestoCoverage\PrestoCoverageContainerDiscoverer.cs:line 73
   at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   at Microsoft.VisualStudio.TestWindow.Controller.OperationData.OnStateChanged(OperationStateChangedEventArgs e)
   at Microsoft.VisualStudio.TestWindow.Controller.OperationData.Microsoft.VisualStudio.TestWindow.Controller.IOperationData.OnRequestStateChanged(Object sender, RequestStateChangedEventArgs e)
   at Microsoft.VisualStudio.TestWindow.Controller.Request.SetState(RequestStates newState

Hopefully this helps.

[p10tyr]

I am looking into this. I noticed this after installing but didnt get round to it yet.

[replaysMike]

I too get this exact issue. Using 1.16.4 on VS 2019 16.0.3. Unfortunate as I was hoping to use this.

[replaysMike]

I should note for others as well, you actually need to uninstall the extension to be able to run tests again as disabling it didn't affect the error.

[p10tyr]

Sorry guys... Something has changed in VS2019 and I am not sure when I will have time to sort it out.

[p10tyr]

Well I found the problem.. They changed the TestWindows dll in VS2019 so when you try and run a test I try to use reflection to get some information about what is going on with the tests.

Why they did is beyond me but I am too stupid to work out how to get this information using the "Extensions way" because there is no docs anywhere about this. I got this working in 2017 thanks to hours of debugging Visual Studio in Visual Studio and trying all sorts of magic out.

The thing I was using in VS2017, the DLL I had to manually reference had a public sealed class and the 2019 version is internal sealed which prevents me from casting to this type. I can probably go deeper into reflection and get this... but for the love of god.. why?!

#region Assembly Microsoft.VisualStudio.TestWindow.Core, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Microsoft.VisualStudio.TestWindow.Core.dll
#endregion

namespace Microsoft.VisualStudio.TestWindow.Controller
{
    **public** sealed class TestRunConfiguration : RequestConfiguration, ITestRunRequestConfiguration, TestPlatform.ObjectModel.Client.ITestRunConfiguration, Controller.ITestRunConfigurationProvider
    {

#region Assembly Microsoft.VisualStudio.TestWindow.Core, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Microsoft.VisualStudio.TestWindow.Core.dll
#endregion

namespace Microsoft.VisualStudio.TestWindow.Controller
{
    **internal** sealed class TestRunConfiguration :

So this is why we are getting the error message ... access type 'Microsoft.VisualStudio.TestWindow.Controller.TestRunConfiguration' failed.

[p10tyr]

Well digging in a bit deeper everything got changed to internal.

If I was conspiracy theorists I would say that one of the Microsoft guys from the Coverlet git saw this and the only reason to close this up to keep this kind of feature for Enterprise users only. But I have no proof of that, I am tired and pissed about this and just speculating. So sorry guys....

No VS2019 support!

[replaysMike]

Ah man don’t you hate when they do stuff like this? I wonder if it was to prevent not having Enterprise to get these stats. I wonder how they do it in DotCover?

[p10tyr]

Well if I play the conspiracy card I have to be fair and play the good guy theory card too.

I believe VS2019 is going to force all extensions to run async and they are probably locking down sync access like this down. The thing is the plugin and coverlet run under the VS Thread, luckily its not a massive issue because it doesn't slow down usage while writing code.. and when we run tests we usually go make a brew so nobody notices a minor speed slowdown.

So really.. I have to redo everything to be async and it would be nice if dependency injection worked from VS into extensions (which it doesnt) And all the shit I have seen is still COM hooks, weird export attributes and then my attempt with meta programming.

I have actually stared at the DotCover (and others) source code for hours. I can hardly make head and tails of it but I have literally nicked their VisualStudioExtensions file to help with a few things.

But I just cannot work out how they hook into the Test Window. Usually when I struggle with these things its because I am doing it wrong. But I cannot find any good useful information about Extension developing (like not the shitty examples that avoid using anything useful from VS) 😢

So why do I need the test window?
A private object "Configuration" contains the following information about the test runner.

1. Is the debugger attached?
   1. If yes then do not attach Coverlet because coverlet modifes part of the binary and causes debugging to fail
2. Which Test projects are being run?
   1. and iterate over them to give me the exact path of the DLL so I can tell Coverlet what to use

I have spent lots of time trying to get that information from the IDE Interfaces but its just not available. The only reason I found the Configuration object was because I installed Rosyln Analysers that expose private and polymorphic things while debugging... and I spent a lot of time in that shitty little inspector window clicking into layers of properties trying to find something useful. And now they took it away.

[p10tyr]

I wonder how they do it in DotCover?

I replied before I was staring at the DotCover source code... there is no source code.. I got confused with another open source project AxoCover I think.

The way DotCover does it is by running its own TestRunner out of process. They gather the data then from their own internal gubbins.