Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Make MFA application projects named 3033-1 and 3033_1
Projects should build and deploy successfully
Numbers and a dash:
Only numbers and underscore:
So I guess in the first case it should fail the build with a descriptive error, like it does in the second case?
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.
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.
Now the problem is not really important.
Why is that eno?
Because most of people would define project name at creation time, not later, no?
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.
Actually, setting severity to enhancement (because it is), but setting importance to normal.