Bug 5957 - MFA allows you to rename projects with invalid names (names that cause build/deploy failures)
Summary: MFA allows you to rename projects with invalid names (names that cause build/...
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.2.x
Hardware: PC Mac OS
: Normal enhancement
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2012-07-02 20:00 UTC by PJ
Modified: 2016-09-02 21:00 UTC (History)
2 users (show)

Tags: XATriaged
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 5957 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description PJ 2012-07-02 20:00:51 UTC
Make MFA application projects named 3033-1 and 3033_1

Projects should build and deploy successfully


Numbers and a dash:


Only numbers and underscore:


MFA 4.2.3
Windows 7
Comment 1 Mikayla Hutchinson [MSFT] 2012-07-02 20:06:38 UTC
So I guess in the first case it should fail the build with a descriptive error, like it does in the second case?
Comment 2 PJ 2012-07-04 11:55:34 UTC
I was thinking the check could happen at project creation (validation of project names).

In the second case, the expected behavior might be that the generated activity name is valid whenever you create a project template (with whatever name you are allowed to use). The activity does have an invalid name, but it was generated with an invalid name.
Comment 3 Mikayla Hutchinson [MSFT] 2012-07-10 19:47:01 UTC
The validation of project names ad generation of valid templates is covered by bug 1079.

I guess we still need that build error in case the user changes the output name after creation, so leaving this open.
Comment 4 Atsushi Eno 2012-09-20 05:09:34 UTC
Now the problem is not really important.
Comment 5 PJ 2012-09-20 11:08:50 UTC
Why is that eno?
Comment 6 Atsushi Eno 2012-09-20 14:01:17 UTC
Because most of people would define project name at creation time, not later, no?
Comment 7 PJ 2012-09-20 15:00:15 UTC
Update from IRC convo:

bug 1079 isnt fixed

oh, I thought it is covered by the bugfix for that

Then the word "covered" is only to mean it is recorded elsewhere?

hutch was just separating out the behaviors in comment 2


hmm but that's logically irrelevant because that part is a "duplicate of bug #1079"

with 1079 taken out of the bug, the remaining bug is that you can still create invalid project by renaming them (or opening them) and only some of those invalid names give descriptive error message

In the underscore case, you get: http://screencast.com/t/V9X3Jy8RDked

with the dash: http://screencast.com/t/71T7yNcPsdu

the 2nd case *could* be caught by earlier validation

pjbeaman: yes, that's why I didn't close but just set lower priority.

Conclusion (at least from me):

With 1079 fixed this issue becomes almost completely unimportant. For now (while we are still allowing people to create projects with invalid names) this issue is more pressing. If bug 1079 gets fixed then definitely we should lower the priority. 

Not that it's a huge deal, but I'm bumping the severity back up until 1079 is actually fixed.
Comment 8 PJ 2012-09-20 15:01:09 UTC
Actually, setting severity to enhancement (because it is), but setting importance to normal.