Targeting .NET 7 instead of .NET Framework

[bdovaz]

If you are worried about dependencies, we can publish in portable mode: https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained

Once #595 is merge it will be much easier.

The benefits are clearly to be able to use a more updated code base, more secured, much more optimized, with more modern APIs, etc...

[tom-englert]

How can you run a .NET 7 dll in a NetFramework executable?

[bdovaz]

@tom-englert I have not explained myself well.

I mean stop targeting .NET Framework and target .NET 7.

WPF applications do not depend on .NET Framework only, they are also compatible with .NET Core / .NET 5/6/7:

https://learn.microsoft.com/en-us/dotnet/desktop/wpf/migration/?view=netdesktop-7.0

[tom-englert]

Visual Studio is NetFramework 462, so extensions must be the same

[tom-englert]

So if you want to contribute something here, you could migrate to the new extensibility model, so the extension does no longer run in process with Visual Studio:

https://learn.microsoft.com/en-us/visualstudio/extensibility/visualstudio.extensibility/visualstudio-extensibility?view=vs-2022

[bdovaz]

Visual Studio is NetFramework 462, so extensions must be the same

But it can be made multi target and that if the extension (at least for the moment) has to be net framework that it is but for the rest that it can take advantage of the benefits of being in .NET 7.

[bdovaz]

So if you want to contribute something here, you could migrate to the new extensibility model, so the extension does no longer run in process with Visual Studio:

https://learn.microsoft.com/en-us/visualstudio/extensibility/visualstudio.extensibility/visualstudio-extensibility?view=vs-2022

I can look at it but as I say, so that it is not blocking you can make it multi target, you already do it in several projects.

[tom-englert]

Multi-targeting for no need is very annoying, because constraints and warnings are often different in NetFramework vs DotNet.
So instead of benefit from DotNet 7, you have to suppress all the hints and refactorings for DotNet7 that are not possible in NetFramework.

[bdovaz]

Where necessary (in cases where there are API changes in the .NET Framework vs. .NET 7), it can be used as:

#if NET7_0_OR_GREATER
#else
#endif

So there is no need to suppress or avoid anything.

https://learn.microsoft.com/en-us/dotnet/standard/frameworks#preprocessor-symbols

[tom-englert]

I will definitely not start to write conditional code unless there is a very strong demand to do so.
It will just make the code unmaintainable, with very low to no benefit.

[tom-englert]

Another con is that when targeting different frameworks, VSIX and standalone will start to behave different, which IMO is a no-go.