Repository navigation
Ability to override target framework in ElectronDevMode #1095
Description
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.
Activity
epsnm commentedon Aug 7, 2026
@FlorianRappl You can assign it to me if you agree
FlorianRappl commentedon Aug 7, 2026
Can you give an example of a project where this might help / what would be necessary to support the case properly?
epsnm commentedon Aug 10, 2026
FlorianRappl commentedon Aug 10, 2026
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 commentedon Aug 10, 2026
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 commentedon Aug 10, 2026
This would indeed be helpful☺️
FlorianRappl commentedon Aug 10, 2026
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 commentedon Aug 12, 2026
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.
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 commentedon Aug 12, 2026
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.
Merge remote-tracking branch 'origin/feat/ElectronNET#1095' into epsi…
Merge pull request #1104 from epsitec-sa/feat/#1095
FlorianRappl commentedon Sep 3, 2026
Any update on this one?
epsitec commentedon Sep 3, 2026
Samuel is on vacation and will be getting back to you by mid-September.
epsnm commentedon Sep 22, 2026
Solved by #1104