Revert "Updating TestWindow.Interfaces assembly redirection" #1730
Conversation
| @@ -19,7 +19,7 @@ | |||
| </dependentAssembly> | |||
| <dependentAssembly> | |||
| <assemblyIdentity name="Microsoft.VisualStudio.TestWindow.Interfaces" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> | |||
| <bindingRedirect oldVersion="11.0.0.0-15.0.0.0" newVersion="16.0.0.0"/> | |||
| <bindingRedirect oldVersion="11.0.0.0-14.0.0.0" newVersion="15.0.0.0"/> | |||
There was a problem hiding this comment.
do we need this redirection at all? Can't we remove this entirely?
There was a problem hiding this comment.
So certain extensions seem to be extending both TestWindow related extensibility points(for which they need TW.Interfaces) and TP in the same assembly which sometimes ends up triggering a load of TW.Interfaces in the testhost process. That starts bombing test discovery/execution. Now devenv.exe has a similar redirection so the TW extension points as such work perfectly fine but discovery/execution through the platform would bomb out without this.
There was a problem hiding this comment.
How do these extensions work in portable scenarios, when VS isn't present?
These extensions should either have this interface shipped along with them or not have this dependency in the adapter least.
In Dev16, I wish to stop supporting these extensions and would like them to react to this.
/cc: @smadala @cltshivash
There was a problem hiding this comment.
Well they do not support portable scenarios. I've seen C++ extensions - Google Test, Cmake etc having such dependencies. That should be ok as long as we have documentation on this.
There was a problem hiding this comment.
If we do want to stop doing this, we might want to communicate with the extension authors sooner because these scenarios are blocked in the latest Dev16 bits.
There was a problem hiding this comment.
Can you point to an existing bug for this ?
There was a problem hiding this comment.
|
@AbhitejJohn FYI |
|
This already happened with #1731 |
Reverts #1718