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 on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
i am using empty default namespace (RootNamespace in the build file) for my projects.
This works with Visual Studio 2003/2008, but Monodevelop for some reason always change the empty default namespace to project name.
This affects embedded resource paths and the programs do not work. Attached is sample application:
open it in VS2008, rebuild, run -> you will see text written to console
open in in Monodeveop, rebuild, run -> you get null reference exception
the null reference is because default namespace was changed by monodevelop and embedded resource paths are different.
Created attachment 1598 [details]
Created attachment 1599 [details]
I don't think it's that simple, I did a quick audit of MD that use the value, and looks like most places handle null/empty values, but the web services addin doesn't
Fixed in master, thanks.
This fix (commit 9fb07d423) results in the default namespace not being set for new projects which means the <RootNamespace> element is not in the csproj file. As a result, Mono for Android projects cannot compile properly as they rely on this value existing.
Then we need to special-case M4A projects until they fix the targets.
MD was definitely wrong in two regards
a) always setting DefaultNamespace when deserializing if it was empty
b) assuming that DefaultNamespace always had a value
Most of MD explicitly handled empty DefaultNamespace, so we did it correctly at some point.
I don't think it really matters whether we set it on *new* projects or not, especially considering that in VS, it could vary between project templates. You can do this by reverting the -149,9 +149,9 hunk from DotNetProject.cs in 9fb07d423f.
The M4A targets need to be fixed too, since people can clear the DefaultNamespace.
I'll file a separate bug for the targets file. I reverted that segment of the commit and tested. It seems to be working great. Thanks!