Error compiling project on Debian linux: error NETSDK1100: Windows is required to build Windows desktop applications.

[ndbroadbent]

Hello,

I would like to be able to modify and compile the code on my Debian Linux server, or on my Macbook.

I installed the latest Mono on Debian from here: https://www.mono-project.com/download/stable/#download-lin-debian
I also followed these instructions to install the .NET SDK:

• https://learn.microsoft.com/en-us/dotnet/core/install/linux-debian
• https://learn.microsoft.com/en-us/dotnet/core/install/linux?WT.mc_id=dotnet-35129-website

sudo apt-get install -y dotnet-sdk-5.0

Then I ran msbuild in the project directory. Here's the output:

root@debian-server:/opt/HTFanControl# msbuild
Microsoft (R) Build Engine version 16.10.1 for Mono
Copyright (C) Microsoft Corporation. All rights reserved.

Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
Build started 22/12/2022 10:20:42 p.m..
Project "/opt/HTFanControl/HTFanControl.sln" on node 1 (default targets).
ValidateSolutionConfiguration:
  Building solution configuration "Debug|Any CPU".
Project "/opt/HTFanControl/HTFanControl.sln" (1) is building "/opt/HTFanControl/HTFanControl/HTFanControl.csproj" (2) on node 1 (default targets).
/usr/share/dotnet/sdk/5.0.408/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1004: Assets file '/opt/HTFanControl/HTFanControl/obj/project.assets.json' not found. Run a NuGet package restore to generate this file. [/opt/HTFanControl/HTFanControl/HTFanControl.csproj]
Done Building Project "/opt/HTFanControl/HTFanControl/HTFanControl.csproj" (default targets) -- FAILED.
Project "/opt/HTFanControl/HTFanControl.sln" (1) is building "/opt/HTFanControl/FanTrayIcon/FanTrayIcon.csproj" (3) on node 1 (default targets).
/usr/share/dotnet/sdk/5.0.408/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(89,5): error NETSDK1100: Windows is required to build Windows desktop applications. [/opt/HTFanControl/FanTrayIcon/FanTrayIcon.csproj]
Done Building Project "/opt/HTFanControl/FanTrayIcon/FanTrayIcon.csproj" (default targets) -- FAILED.
Done Building Project "/opt/HTFanControl/HTFanControl.sln" (default targets) -- FAILED.

Build FAILED.

"/opt/HTFanControl/HTFanControl.sln" (default target) (1) ->
"/opt/HTFanControl/HTFanControl/HTFanControl.csproj" (default target) (2) ->
(ResolvePackageAssets target) ->
  /usr/share/dotnet/sdk/5.0.408/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1004: Assets file '/opt/HTFanControl/HTFanControl/obj/project.assets.json' not found. Run a NuGet package restore to generate this file. [/opt/HTFanControl/HTFanControl/HTFanControl.csproj]


"/opt/HTFanControl/HTFanControl.sln" (default target) (1) ->
"/opt/HTFanControl/FanTrayIcon/FanTrayIcon.csproj" (default target) (3) ->
(ProcessFrameworkReferences target) ->
  /usr/share/dotnet/sdk/5.0.408/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(89,5): error NETSDK1100: Windows is required to build Windows desktop applications. [/opt/HTFanControl/FanTrayIcon/FanTrayIcon.csproj]

    0 Warning(s)
    2 Error(s)

Time Elapsed 00:00:01.16

I found this on StackOverflow: https://stackoverflow.com/a/73038414/304706

Starting with net6 SDK 6.0.4xx, it will be possible to build WPF/WinForms projects on non-windows operating systems.

It requires <EnableWindowsTargeting>true</EnableWindowsTargeting> to be set in the csproj or a Directory.Build.props file.

dotnet/docs#30076

Would it be possible to make some changes so that I can compile it on Mac / Debian / Raspberry Pi?

[nicko88]

I don't think you should need mono as modern .NET is the cross-platform replacement for it.

Even when I build the RasPi and Linux builds on Windows, I have to ignore the WinForms code in the FanTrayIcon project. That code is just to create a tray icon on Windows.

To do this I have a conditional in the main project file to exclude the FanTrayIcon project when targeting linux arm and linux x86.

https://github.com/nicko88/HTFanControl/blob/master/HTFanControl/HTFanControl.csproj#L85

Rather, it only includes the project when targeting ReleaseWin and Debug.

You could just remove this project reference entirely as it's not used or needed on macOS or Linux.

Then you need to remove the only code reference to this project here:

https://github.com/nicko88/HTFanControl/blob/master/HTFanControl/Program.cs#L52

I am using a pre-processor directive to automatically conditionally include the code only when I am building with the ReleaseWin or Debug targets.

I am not very familiar with the command line build tools unfortunately, but maybe there are ways to use my build targets and have this conditional stuff work as well. Otherwise, just removing these small parts should work.

I am not sure about the build error in the main project though. That file is created by Visual Studio automatically for me, and the obj folder is by default not included in source control. It says you need to "Run a NuGet package restore to generate this file." I am not sure what the exact command for that it.

Have you considered trying Visual Studio Code? It may make things easier for getting this to build.

https://code.visualstudio.com/

As far as improving this in general, yeah I can look into the newer .NET 6 and brand new .NET 7 changes as I am sure this can be done in a better and more compatible way. There were some reasons I wasn't ready to move on from .NET 5 and Visual Studio 2019 (I have to use Visual Studio 2022 for .NET 6+). But I can't or shouldnt stay here forever and should find a good way to move forward.

[nicko88]

In the long term I wouldn't mind getting this all in a better state and on a newer .NET framework (since .NET 5 is out of support).

However, I want to do this in a way I am happy with the solution and so I am not quite ready to just rush right into these sorts of project and framework changes.

I know I could do like a branch and PR for your fork to help you fix your build issues, but for simplicities sake for me I just checked out your fork and made the minimal changes that should allow you to compile successfully and just stuck the directory into an archive here:
HTFanControl_nonwin_build.tar.gz

Honestly I've never really used .NET on non-windows and the CLI tools, but I think I understand enough to have this working from it's current form.

You should be able to do dotnet build for debug builds, and dotnet publish -p:PublishProfile=linux to make a release build for linux. Replace 'linux' with 'raspi' or 'raspi64' for those release builds as well.

And to run should just be ./HTFanControl in the respective Debug or publish directories.

If you want proper debugging, I assume you will need an IDE like vs code.

I hope this is an OK solution for you for now, because I want to get you up and running so you can start to play with changes for your roku and fog/strobe stuff.

[nicko88]

Leaving this open to help others with this issue for now...

And as my reminder to potentially track and discuss upgrading this project to a newer .NET framework as well as any changes that will need to be made in how the platform-specific code is included and built.

[ndbroadbent]

Thanks for your help! I'm able to run dotnet build if I remove the FanTrayIcon files, but I'm sure I'm missing an obvious command-line flag or something. I'm not sure how to get it to just build for Linux instead of trying to build the Windows stuff as well.

[nicko88]

Hmm, running dotnet build should only automatically build the local native platform version in the bin/Debug or bin/Release folders. It build Debug for me, I am not sure how to switch it to Release, but I didn't try to look as I would rpefer using the publish command to build Release builds anyways since it lets you do more things.

Yes there are .dll files in the output which seems like Windows, but it's not Windows (or at least it shouldn't be). There should be no HTFanControl.exe, only a Linux executable HTFanControl along with a bunch of other files including .dlls. But you should be able to run the app from there or copy the entire contents of this folder somewhere and run it from there so long as the machine has the appropriate .NET framework installed.

To produce a single file output (like my releases), or an output that includes the .NET framework inside the executable itself (so the machine doesn't need the framework installed at all), you have to use the dotnet publish option for that. My repository includes 4 publish profiles that are already defined and can be used: win, linux, raspi, raspi64

dotnet publish -p:PublishProfile=linux

This is how I normally build a release build (with compiler optimizations and without debug data), but you can use the output from dotnet build too and it will run and work just fine too.

I am not even that well-versed in all this CLI building as I normally just use the build and publish buttons and GUI menus in Visual Studio do do my building, debugging, and release building, but I looked up and testes these commands on a Debian VM with only the .NET 5 framework installed (apt-get install dotnet-sdk-5.0) and it all worked fine once I removed the FanTrayIcon project and code referencing it.

I would just uninstall mono if you still have that as I can only see that causing problems and confusion. dotnet is the official cross-platform compiler from Microsoft. mono was an unofficial .net compiler which should be abandoned now IMO.

[ndbroadbent]

Oh yes sorry I mean it’s working fine for me in Debian as well when I remove the FanTrayIcon files, but I was just wondering if there’s a way to leave them in the project and skip them on Linux. Maybe there’s a way to add some more compiler flags to ignore these projects on Linux? Otherwise I can just keep using my commit that removes the files

…

On 3 Jan 2023 at 3:24 PM +1300, nicko88 ***@***.***>, wrote: Hmm, running dotnet build should only automatically build the local native platform version in the bin/Debug or bin/Release folders. It build Debug for me, I am not sure how to switch it to Release, but I didn't try to look as I would rpefer using the publish command to build Release builds anyways since it lets you do more things. Yes there are .dll files in the output which seems like Windows, but it's not Windows (or at least it shouldn't be). There should be no HTFanControl.exe, only a Linux executable HTFanControl along with a bunch of other files including .dlls. But you should be able to run the app from there or copy the entire contents of this folder somewhere and run it from there so long as the machine has the appropriate .NET framework installed. To produce a single file output (like my releases), or an output that includes the .NET framework inside the executable itself (so the machine doesn't need the framework installed at all), you have to use the dotnet publish option for that. My repository includes 4 publish profiles that are already defined and can be used: win, linux, raspi, raspi64 dotnet publish -p:PublishProfile=linux This is how I normally build a release build (with compiler optimizations and without debug data), but you can use the output from dotnet build too and it will run and work just fine too. I am not even that well-versed in all this CLI building as I normally just use the build and publish buttons and GUI menus in Visual Studio do do my building, debugging, and release building, but I looked up and testes these commands on a Debian VM with only the .NET 5 framework installed (apt-get install dotnet-sdk-5.0) and it all worked fine once I removed the FanTrayIcon project and code referencing it. I would just uninstall mono if you still have that as I can only see that causing problems and confusion. dotnet is the official cross-platform compiler from Microsoft. mono was an unofficial .net compiler which should be abandoned now IMO. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[nicko88]

Oh, yeah that I have no idea how to do. There is likely a way though.

But the best solution will just be me moving the project to .NET 6+ and making the appropriate changes to use the new features that it provides in order to create a multi-project solution that can build on all platforms without changes.

Something I want to explore doing sooner than later.