Ability to override target framework in ElectronDevMode

[epsnm]

Electron.NET is targeting multiple frameworks, including deprecated ones.

While using ElectronDevMode we might use it as a submodule of an existing product where only some targets are available.

In order to enhance developer experience, add the ability to overload the target framework from the Directory.Build.props barrier.

In addition, this will solve the Visual Studio message 'This project is targeting a version of .NET that is not installed' for solutions without multiple target frameworks.

[epsnm]

@FlorianRappl You can assign it to me if you agree

[FlorianRappl]

Can you give an example of a project where this might help / what would be necessary to support the case properly?

[epsnm]

• Some companies have restrictions about installing no longer supported .NET versions and automatically remove them.
• This will help to easily switch to the new target framework for early testing.

[FlorianRappl]

I still don't see it. Just change the target framework in your project file? What am I missing here?

It seems this is more a problem of the project using Electron.NET than of Electron.NET.

[epsnm]

Because of the Directory.build.props barrier, changing TFM in my repository will not be reflected in the Electron.NET directory.

I need to be able to change or restrict the TFM in a centralized manner, without doing any change in our forked repository of Electron.NET

I'm not saying there are no other options, but having a way to customize TFM is more convenient for our solution. As it only adds the possibility to override, actual behavior is unchanged.

[epsitec]

This would indeed be helpful ☺️

[FlorianRappl]

So what you are talking about is development convenience for sb. developing Electron.NET instead of somebody using Electron.NET.

Because the last group is who we actively target and should put effort in - the former is just ourselves. And for the former - why don't you just change the TFM since you have it locally anyway? You can make any change you like.

Maybe I still don't get it - but I don't see what benefits we would have here (as a user the TFM you set for your application is also the TFM that will be used for your deps incl. Electron.NET).

[epsnm]

So what you are talking about is development convenience for sb. developing Electron.NET instead of somebody using Electron.NET.

Yes, with the idea in mind that somebody using Electron.NET as an end-user might become a contributor at some point. Therefore, enhancing DX is not worthless.

Because the last group is who we actively target and should put effort in - the former is just ourselves. And for the former - why don't you just change the TFM since you have it locally anyway? You can make any change you like.

We want to use the upstream version to avoid drifting to a custom fork. This change might not seem like a lot, but it opens Pandora's box of having a patched version and will challenge us to avoid drifting on the long run.

Here are the changes if you want to have a look.

[FlorianRappl]

Yes, for me this is fine. It's generally good, too, as its a single-source for modification of the TFM.

So yes - please create a PR.