🎛 Event-Catcher with variety of advanced Actions to service projects, libraries, build processes, runtime environment of the Visual Studio, MSBuild Tools, and …
+ SDK17
+ netfx4sdk since Microsoft officially dropped support of the Developer Pack (SDK) for .NET Framework 4.0.
+ Now SDK15 is limited to VS2017 and VS2019 only
+ Fixes SDK10 incorrect manifest for VS2010 9dfbec415972c5a9e7edd648f22f778f19f4f91f
Problems
In addition to x64 feature, seems like we have an incompatible type binding using SDK15.
EnvDTE
EnvDTE reference from SDK15 just produces this at runtime evaluation in modern VS2022
{"Method not found: 'Void EnvDTE._dispCommandEvents_BeforeExecuteEventHandler..ctor(System.Object, UIntPtr)'."}
With public API use (exactly not a EnvDTE.dispCommandEvents internal use)
cmdEvents.BeforeExecute += OnCommandEventBefore;
That's weird because it can also be found at least for SDK15
Looks like it can be really due to .ctor(System.Object, UIntPtr) because of .ctor(System.Object, IntPtr) now.
Modern VSSDK Interop types
Microsoft aggregates now all their VSSDK Interop types inside single Microsoft.VisualStudio.Interop.dll
Now Microsoft.VisualStudio.Interop can produce CS0433 because we are referencing legacy assemblies in SDK15 to make them work for VS2017+
SDK15 & SDK17
Today I really don't want to separate it for a new SDK17 distr (in additon to SDK10 and SDK15).
Thus we need to think how to make friends with modern Microsoft.VisualStudio.Interop etc.
Obviously Microsoft.VisualStudio.Shell.15.0 cannot be upgraded to modern versions (17+) without breaking in VS2019.
I've checked it.
So... why hasn't it been sliced into another layer of API such as Shell.17.0 and why at all Shell.15.0 v17.0.31902.203 targets VS2022 ... these are good questions to the team because this works well in VS2022 but crashes VS2019
Tl;dr
I'll try to review some SDK15/SDK17 combinations as soon as possible to complete this PR but any comments and suggestions are welcome.
FYI, at this moment you can still use our nuget package together with VS2022 which should work fine
Reviewed. Possible solutions
❌ Csc isolation of Microsoft.VisualStudio.Interop through aliases is difficult or impossible due to Shell.15 which reference EnvDTE. For example, I've checked some scenario when it really helps and everything works well (like CommandEvents subscription) but for overriding like GetAsyncToolWindowFactory I'm not really sure what to do without modifying the assembly to rebind types etc.
public override B.Microsoft.VisualStudio.Shell.Interop.IVsAsyncToolWindowFactory GetAsyncToolWindowFactory(Guid toolWindowType)
✅ To cut everything except EnvDTE/EnvDTE80 from Microsoft.VisualStudio.Interop is prohibited by license :( But I'm pretty sure for 90% that technically this is a working option in a just few clicks because, again, the main problem is the aggregation of unnecessary assemblies into one. At least for actual VS2022 version where crash indicates the error which 100% covers public API.
❌ To implement own EnvDTE (even to cover only used API in this project) will be more difficult thing than SDK17 support in addition to SDK15.
I come to the conclusion that I need to do SDK17 :( because I have no rights for item №2
Extends support to modern VS2022.
Closes #76
+ SDK17 + netfx4sdk since Microsoft officially dropped support of the Developer Pack (SDK) for .NET Framework 4.0. + Now SDK15 is limited to VS2017 and VS2019 only + Fixes SDK10 incorrect manifest for VS2010 9dfbec415972c5a9e7edd648f22f778f19f4f91f
Problems
In addition to x64 feature, seems like we have an incompatible type binding using SDK15.
EnvDTE
EnvDTE reference from SDK15 just produces this at runtime evaluation in modern VS2022
With public API use (exactly not a EnvDTE.dispCommandEvents internal use)
That's weird because it can also be found at least for SDK15
Looks like it can be really due to .ctor(System.Object, UIntPtr) because of .ctor(System.Object, IntPtr) now.
Modern VSSDK Interop types
Microsoft aggregates now all their VSSDK Interop types inside single Microsoft.VisualStudio.Interop.dll
Before it was a separate assemblies here https://www.nuget.org/packages/EnvDTE and so on
Now Microsoft.VisualStudio.Interop can produce CS0433 because we are referencing legacy assemblies in SDK15 to make them work for VS2017+
SDK15 & SDK17
Today I really don't want to separate it for a new SDK17 distr (in additon to SDK10 and SDK15). Thus we need to think how to make friends with modern Microsoft.VisualStudio.Interop etc.
Obviously Microsoft.VisualStudio.Shell.15.0 cannot be upgraded to modern versions (17+) without breaking in VS2019. I've checked it.
So... why hasn't it been sliced into another layer of API such as Shell.17.0 and why at all Shell.15.0 v17.0.31902.203 targets VS2022 ... these are good questions to the team because this works well in VS2022 but crashes VS2019
Tl;dr
I'll try to review some SDK15/SDK17 combinations as soon as possible to complete this PR but any comments and suggestions are welcome.
FYI, at this moment you can still use our nuget package together with VS2022 which should work fine
Reviewed. Possible solutions
✅ To cut everything except EnvDTE/EnvDTE80 from Microsoft.VisualStudio.Interop is prohibited by license :( But I'm pretty sure for 90% that technically this is a working option in a just few clicks because, again, the main problem is the aggregation of unnecessary assemblies into one. At least for actual VS2022 version where crash indicates the error which 100% covers public API.
❌ To implement own EnvDTE (even to cover only used API in this project) will be more difficult thing than SDK17 support in addition to SDK15.
I come to the conclusion that I need to do SDK17 :( because I have no rights for item №2
damn