Windows packaging fails when MAUI project name has an underscore in it

[MSLukeWest]

Description

When creating a new .NET MAUI app, the Package.AppxManifest file found under "Platforms\Windows" starts with the following Identity element:

<Identity Name="maui-package-name-placeholder" Publisher="CN=User Name" Version="0.0.3.0" />

Then, during the build, "maui-package-name-placeholder" gets replaced by "com.companyname.". So, if the app name is something like "MAUI_app", it will be "com.companyname.MAUI_app".

The problem is that underscore is an invalid character here, so this leads to build errors shown below. Since the MAUI targets are generating this value, it should make sure only legal characters are used.

See:

maui/src/SingleProject/Resizetizer/src/GeneratePackageAppxManifest.cs

Line 89 in 7a3da15

if (!string.IsNullOrEmpty(ApplicationId))

Steps to Reproduce

1. Create a new MAUI app with an underscore in the name, like MauiApp_21_Debug_AnyCPU_net9.0-windows10.0.19041.0_Build_2024-12-09T17_50_26.5698675-08_00.binlog.txt

2. If you're using .NET 9.0, set the WindowsPackageType property to "MSIX" (this is the default in .NET 8.0 )

3. Create a sideload published app, using either Visual Studio or the CLI (my attached binlog is from the IDE)

Result: Build Errors:

1>MakeAppx(0,0): Error : Error info: error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 10, Column 13, Reason: 'com.companyname.MauiApp2_21' violates pattern constraint of '[-.A-Za-z0-9]+'.
1>MakeAppx(0,0): Error : Package creation failed.
1>MakeAppx(0,0): Error : 0x80080204 - The specified package format is not valid: The package manifest is not valid.

Link to public reproduction project repository

No response

Version with bug

9.0.12 SR1.2

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

All Windows versions

Did you find any workaround?

You can set the value of this element to something valid in the input manifest. However, this isn't obvious to most customers, as the error is reported to them as coming from AppxManifest.xml under the bin directory.

Relevant log output

binlog attached, rename it from .binlog.txt to just .binlog

[MSLukeWest]

MauiApp_21_Debug_AnyCPU_net9.0-windows10.0.19041.0_Build_2024-12-09T17_50_26.5698675-08_00.binlog.txt

[jfversluis]

I mean, technically the error is sufficient, right? This is probably what happens if I would go into the manifest file for a WinUI app and edit it manually to be an invalid value. The only thing probably stopping me from doing that is that the graphical editor will pop up, but that is not 100% fail safe.

cc @mattleibow

[MSLukeWest]

I mean, technically the error is sufficient, right? This is probably what happens if I would go into the manifest file for a WinUI app and edit it manually to be an invalid value. The only thing probably stopping me from doing that is that the graphical editor will pop up, but that is not 100% fail safe.

cc @mattleibow

@jfversluis / @mattleibow - You're right that you'd see that same error if you edited the Package.appxmanifest of a WinUI/UWP app and put an underscore in the name. However, there's a significant difference with those project types: at project creation time this value is set to a guid, so it will never be invalid unless the user edits it. Not only that, but for WinUI/UWP once the user goes and looks at their Package.appxmanifest file they'd see the underscore in the name, so it'd be more obvious what they need to do to fix it. For MAUI, the value they'd see is the valid string "maui-package-name-placeholder", so it's not at all obvious what they need to change.

In the case of MAUI, we're essentially creating this value dynamically at build time, so it's reasonable to expect that we would avoid invalid values. A simple .Replace("_", "-") on this value at some point should be sufficient.

[jfversluis]

at project creation time this value is set to a guid, so it will never be invalid unless the user edits it.

As far as I know that is not the case anymore, we did this in the past and learned that that is not something desirable so we stopped doing that?

A simple .Replace("_", "-") on this value at some point should be sufficient.

It absolutely is an easy fix, no argument there! But then someone will open an issue: I want to use an underscore in my name, why can't I do that?! This is of course a bit exaggerated but I hope you see where I'm going with this. If we want to make that replacement for a valid value, why aren't they doing that in the underlaying WinUI build chain? Then we fix it for both WinUI and .NET MAUI.

And if we do it here, I can think of more places where we want to do things. The version number fields will probably also throw up if you enter something weird in them at this point.

I'm all for making it better, but I feel in this case it's not really our responsibility? If anything the tooling could help with this?

[MSLukeWest]

at project creation time this value is set to a guid, so it will never be invalid unless the user edits it.

As far as I know that is not the case anymore, we did this in the past and learned that that is not something desirable so we stopped doing that?

Yes, this is still the case. I just confirmed this in a new WinUI project.

A simple .Replace("_", "-") on this value at some point should be sufficient.

It absolutely is an easy fix, no argument there! But then someone will open an issue: I want to use an underscore in my name, why can't I do that?! This is of course a bit exaggerated but I hope you see where I'm going with this. If we want to make that replacement for a valid value, why aren't they doing that in the underlaying WinUI build chain? Then we fix it for both WinUI and .NET MAUI.

And if we do it here, I can think of more places where we want to do things. The version number fields will probably also throw up if you enter something weird in them at this point.

I don't really see this as part of the underlying build chain, it's part of an xml schema. And if someone wants to put an underscore in their package identity name they will be alerted to the fact that this violates the schema.

I'm all for making it better, but I feel in this case it's not really our responsibility? If anything the tooling could help with this?

Fair point, but I'd argue that by using the "maui-package-name-placeholder" token in the template and replacing it at build time the sdk is essentially acting as the tooling. So, if the SDK is already handling this scenario, why not just handle it correctly by not using invalid characters?

[South2AK]

@MSLukeWest I have this exact issue..

I´ve set the WindowsPackageType to MSIX, am in release mode and also tried replacing the the placeholder inside package.appxmanifest to a valid one such as com.company.tool

But i´m still getting the error:
1>MakeAppx(0,0): Fehler : Error info: error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 19, Column 48, Reason: '8.0' verst÷▀t gegen pattern-Einschrõnkung von '(0|[1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])(.(0|[1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])){3}'.
1>MakeAppx(0,0): Fehler : Package creation failed.
1>MakeAppx(0,0): Fehler : 0x80080204 - The specified package format is not valid: The package manifest is not valid.
========== Veröffentlichen: 0 erfolgreich, 1 mit Fehler, 0 übersprungen ==========

[maexsp]

Also running into this issue when MSIX packaging does not allow to use a special sematic version which was set by CI/DI pipeline before msbuild was started. In this case E.g. '4.0.95.0-alpha' <Identiy Version="4.0.95.0-alpha" was not accepted.

MakeAppx : error : Error info: error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 19, Column 220, Reason: '4.0.95.0-alpha' violates pattern constraint of '(0|[1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])(.(0|[1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{
2}|655[0-2][0-9]|6553[0-5])){3}'. [C:....myproj.....csproj::TargetFramework=net9.0-windows10.0.19041.0]