.NET MAUI on Windows without Visual Studio - How to make it work?

Question

The macOS install example works perfectly, but when I try the same thing on Windows... no dice!

First I tried dotnet build -f net6.0-windows on the raw template project and got NETSDK1135: SupportedOSPlatformVersion 10.0.17763.0 cannot be higher than TargetPlatformVersion 7.0.

So I looked over the Windows install instructions for Visual Studio and gave this a go: dotnet build -f net6.0-windows10.0.19041

And got: NETSDK1005: Assets file ... doesn't have a target for 'net6.0-windows10.0.19041'. Ensure that restore has run and that you have included 'net6.0-windows10.0.19041' in the TargetFrameworks for your project.

So, I edited my .csproj file (with vim, of course!) and added net6.0-windows10.0.19041 to the colon-separated list in the TargetFrameworks element.

This time: MSB4185: The function "Is64BitProcess" on type "System.Environment" is not available for execution as an MSBuild property function.

So, after some searching and reading, I found evidence suggesting that the problem was that I was using the current (at time of writing) version of the dotnet CLI utility, which was 6.0.202. (Is it the CLI utility version or the SDK version? The docs don't make it clear to me.)

So I used winget to install a Preview version of dotnet (7.0.100-preview.3.22179.4) and got: To build this project, the following workloads must be installed: wasm-tools

Okay. Patience. dotnet workload install wasm-tools

And now, when I try to build: NETSKD1139: The target platform identifier android was not recognized.

So I removed everything except net6.0-windows10.0.19041 from my .csproj file's TargetFrameworks element, and got:

MSB4086: A numeric comparison was attempted on "$(registry:HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion@CurrentVersion)" that evaluates to "" instead of a number, in condition "'$(AppxUseResourceIndexerApi)' == '' AND '$(registry:HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion@CurrentVersion)' < '6.3'".

Argh!

What... is... going... on...?

So, why don't you just give yourself a break and use Visual Studio?

So glad you asked! It could be one of many things. Perhaps...

• I've tried, but my company Windows device won't let me turn on Developer Mode.
• The licensing terms don't really work for my situation.
• Visual Studio hides the build process, meaning that when problems like the above arise, I'm completely mystified about what's causing them. Or conversely, when things do work, I don't understand why they worked. It's all just "magic".

Answer 1

Hello,

I can reproduce the same issue as you, then I found this GitHub: Build Windows target using dotnet build instead of msbuild.exe, so it looks like that currnetly using dotnet build to build a .NET MAUI app for Windows doesn't work with the current previews of .NET MAUI, but the good news is that we can use the MSBuild to build the MAUI application.

And I have tried it, it works great on my side. In order to use MSBuild without installing Visual Studio, first you can click this link to download Build Tools for Visual Studio 2022.

In Visual Studio 2022, the tool is installed in: C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin, you could set the environment variable for it.

Then, you could run the command line to build your MAUI project.

msbuild -r -p:Configuration=Release -p:RestorePackages=false -p:TargetFramework=net6.0-windows10.0.19041

MAUI is still in preview testing, and we will fix these issues as soon as possible.:)

Thanks for your feedback.

Best Regards,

Alec Liu.

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Got this as well. Just to add what I saw (and eventual fix, in case others find it useful):

Edit: I actually wrote this in response to https://github.com/dotnet/sdk/issues/28993, but posted it here by accident instead. If you view the answer there it will make more sense in that context (reference to "scripts above", etc.)

---

Got this as well. Just to add what I saw (and eventual fix, in case others find it useful):

Got this as well. Just to add what I saw (and eventual fix, in case others find it useful):

I had just tried a reboot anyway (even though nothing else indicated one was needed). Same result after.

I ran the 3 scripts above; the last returned: reg query "hklm\SYSTEM\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
	PendingFileRenameOperations    REG_MULTI_SZ    \??\C:\Users\me\AppData\Local\Temp\da3a9f78-f318-43dc-b501-0bc8bbf2d8ec.tmp\0\??\C:\Users\me\AppData\Local\Temp\06482c31-11b0-4a14-ad6f-847164752608.tmp\0\??\C:\Program Files\Google\Chrome\Temp\scoped_dir16328_1967781880\old_chrome.exe\0\??\C:\Program Files\Google\Chrome\Temp\scoped_dir16328_1967781880\0\??\C:\Program Files\Google\Chrome\Temp\0\??\C:\Program Files\Google\Chrome\Temp\scoped_dir105592_1782936003\old_chrome.exe\0\??\C:\Program Files\Google\Chrome\Temp\scoped_dir105592_1782936003\0\??\C:\Program Files\Google\Chrome\Temp

Seems even though I'd just rebooted and Chrome had relaunched, it hadn't updated itself. Unexpected. I went to Chrome > Help > About and it updated. The registry key remained, though, so I rebooted again (again no other indication to do so).

Reran reg query "hklm\SYSTEM\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations and now nothing there.

Reran dotnet workload restore and it worked as expected this time.

Seems like it might be possible for dotnet to be more discerning in what it considers "reboot required" here? E.g. a Chrome file-rename is almost certainly inconsequential to the outcome. I suppose if it somewhere just asks the OS "any pending operations on reboot?" then fair enough, but this is a fairly less-than-optimal situation, especially as the user gets very little clue to reboot (and in this case reboot > dig around in registry settings > manually update Chrome > reboot).