Move to a dotnet tool based distribution model

[EWSoftware]

The current project format is MSBuild-based. The Visual Studio extension uses the old MPFProj project system which has been around since about 2008 or so. While it still works with Visual Studio 2026, the older it gets the less likely that is to be the case. Eventually, I think it will become incompatible making a significant change necessary. A recent change to MSBuild 18 has required removal of support for command line property overrides when building projects from the command line (#1146). While there is a workaround, it does complicate building the project if you made use of that feature.

One option was to move to the Common Project System (CPS) (#90). However, that no longer appears to be the best option. Instead, an effort should be made to move to distributing the build engine as a dotnet tool. This has some definite advantages.

• The project would no longer be MSBuild-based which simplifies a number of things internally and removes the dependency of being tied to a specific version of MSBuild which has caused a number of issues in the past.
• It will remove the dependency on a SHFBROOT environment variable to find the tools and their dependencies.
• It is likely that by distributing the build engine as a tool, the older .NET 4.8 tool versions could be removed allowing use of the modern framework and language features going forward.
• It would greatly simplify installation.
  • No more guided installer required with multiple steps.
  • The build engine would be installed and updated with the dotnet tool. It also appears to support installing multiple versions which should allow older projects to continue working with a prior release even if a newer release is installed.
  • The Visual Studio package would still be available to handle managing project settings in a user-friendly manner (though configuration file based rather than in an MSBuild project) and to continue providing custom editors for the content layout files, token files, etc. However, since it would no longer depend on the .shfbproj file format or the build engine itself, it could be distributed via the Marketplace like a normal extension. Updates to it could be made independently of the build engine with no need to keep them in synch with every release.
  • A version of the standalone GUI would still be provided though it too could likely be distributed as a tool rather than using the current MSI installer. As with the Visual Studio extension, this also allows it to be updated independently of the build engine.

[StephenHidem]

I like where you are going with this! It would be trivial to install the tools in a Github workflow and invoke the appropriate commands. Let me know if you would like any help with this; label any issues you create with "Help Wanted" and I'll see what I can do.

[timunie]

🤯 That would be a great imporvement I believe. It would also add the possibility to update the GUI to use Avalonia in the long term, which would add the abilitiy to run it from MacOS and Linux.

Sure, this is a long way until we are there, but I like the direction. 👍

[EWSoftware]

@timunie Yes, I've recently been playing around with Avalonia on a personal project converting it from Windows Forms to get familiar with Avalonia. The plan is to eventually replace the existing standalone GUI the same way but I've never been keen to do it with WPF. I have to say I've taken to Avalonia a lot quicker and like it much better than WPF and don't want to go back. Being cross platform is also a benefit here.

[timunie]

If you need some help with the UI part, I can try to help.