Template option '--applicationId' doesn't work in standard maui template

[nevse]

Description

When I create my maui app from cli via command dotnet new maui -n TestApp -ap com.my.app it has wrong application id.
It should be 'com.my.app' but it is com.companyname.testapp.

Steps to Reproduce

1. run command dotnet new maui -n TestApp -ap com.my.app
2. see content of TestApp/TestApp.csproj file

...
  <!-- App Identifier -->
  <ApplicationId>com.companyname.testapp</ApplicationId>
  <ApplicationIdGuid>6df18cbf-0885-4a8a-876c-24148e9ceec1</ApplicationIdGuid>
...

Tag ApplicationId has value com.companyname.testapp but should becom.my.app.

Link to public reproduction project repository

not required

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

iOS, Android, I was not able test on other platforms

Affected platform versions

all

Did you find any workaround?

No response

Relevant log output

No response

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[jknaudt21]

This issue seems to be caused by the fact that the template's sourceName is set to"MauiApp.1", which is the same string that's used in the AppIdentifier. Since sourceName replaces all instances of the specified string, by the time the AppIdentifier parameter is evaluated the templating engine can no longer match (and thereby replace) it.

A simple solution would be to change the AppIdentifier to a string that's not the sourceName, but I'll investigate further if we can add conditionals such that the ap parameter can replace strings like com.companyname.

[Redth]

@rolfbjarne @mauroa @emaf @tondat if we removed the com.companyname. prefix in default app id's are there any negative consequences to removing this prefix? Do any of the provisioning profiles or certs that get added expect this convention?

@jonathanpeppers @dellis1972 same question for anything android?

[jonathanpeppers]

I think they have to be unique ids on the Apple App Store.

So, if you just did "helloworld", it's likely going to be taken by someone else already. com.companyname kind of signals you to fill it out so you at least get com.microsoft.helloworld and maybe that name won't be taken.

Android, it actually might not matter? @dellis1972 do you know?

[dellis1972]

The package name/app id MUST be a uri on android in the form of xxx.xxxx.xxx otherwise it won't work.

[jonathanpeppers]

Ok yeah, the package name is unique on Google Play, too:

https://play.google.com/store/apps/details?id=com.nvsgames.snap

So if someone just named their app "snap" it might be taken.

[Redth]

@phenning @sayedihashimi is there any sort of validation / cleansing of parameter input we are able to do with templates?

Ideally we could restrict the value to some lowercase, alphanumeric (plus . and maybe hyphen? i forget) value, so basically a regex pattern, and give an appropriate error message when running dotnet new to ensure the template is inflated with a valid value.

[sayedihashimi]

Also adding @baronfel for the template question above.

[baronfel]

Unfortunately we don't, though I agree this would be a pretty necessary ability. The tracking issue is dotnet/templating#2038, we may end up needing it for the interactive prompting work so I'll see if we can slot it in.

You can specify regex-based transforms, but I'm not sure that those would be able to solve your validation need in the current state.

[phenning]

I think we would also want to do the validation at multiple layers. It would be useful if the core engine would do the validation but also be able to expose the validation rule and the error message so that hosts could pre-validate before passing the parameter to the core engine.

I’ll add this comment to the other issue

[jknaudt21]

@Redth I think the main focus should be the suffix of the AppId, and not the com.companyname prefix. The template establishes the AppID to be com.companyname.mauiapp._1, and the bug originates because of the suffix mauiapp._1 matches against the App's title (i.e the sourceName in the template), and prevents the applicationId parameter from matching.

My suggested solution is to change the template such that all maui apps are created with the applicationId com.companyname.mauiapp. This prevents the AppID from matching to the sourceName and enables the applicationId parameter to work again. Here's the link to the PR: #13509

It seems we can't do much validation from the templating side if the user specifies an invalid AppID, but I believe we could do something from the SDK side. For example, we could prevent a build if the AppID is not in the desired format. This would also guard against situations where the user manually edits the cproj and changes the AppID to be something invalid.

[rolfbjarne]

@rolfbjarne @mauroa @emaf @tondat if we removed the com.companyname. prefix in default app id's are there any negative consequences to removing this prefix? Do any of the provisioning profiles or certs that get added expect this convention?

Here's the documentation for CFBundleIdentifier: https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier?language=objc

You don't need to follow the com.companyname.* convention if you're not publishing to the App Store (the alphanumeric restrictions are likely still in effect though).

If you are publishing to the App Store, then you must choose a CFBundleIdentifier for your app in the App Store Connect site, and I believe the site enforces the com.companyname.* prefix. In most cases I don't think people know their final CFBundleIdentifier when they create the initial project, they'll usually end up changing it later, so I'm not sure how much validation we should do in the template.