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.
So I am using all the cross-platform techniques as shown in the seminars and stuff. So one bit of code I used in Visual Studio for Win 7 and M4A is this:
public const string ServerAddress = "http://van.dyndns-web.com/NashuaMobile/nashuamobileservice/";
public const string ServerAddress = "https://mobiapp03.exordia.co.za/nashuamobile/nashuamobileservice/";
So I then made a release build of a MonoTouch application in MonoDevelop on Mac and published it. On further inspection, MonoDevelop still compiled the DEBUG portion of the code above. This was a massive error which required me to submit a new version to the app store.
Why does MonoDevelop use the DEBUG preprocessor for absolutely all of the profiles that have been setup even in release modes?
I can't reproduce the issue.
Where did you set the release build ?
Check if the DEBUG define is set into the release configuration in the project options - it shouldn't.
Or can you give me the project ?
Ok yes the configuration was set to Debug by default for the AppStore|iPhone configuration. Not sure why it came with set to Debug by default.
Also something else I found is that when changing between Debug and Release modes, the colours in the code editor do not change to reflect the currently active code. So in Debug mode the chunk of code that is active is highlighted and the other code looks commented out but when you change to release mode the Debug code still looks active.
Dylan, Just to double check something. You had a solution which contains a single MonoTouch project and when you selected AppStore|iPhone, it built with the debug symbol enabled?
Or did you create a Solution with a MonoTouch project and an additional MonoTouch library project and the additional library project was compiled in Debug mode instead of Release mode?
Normally I create a new MonoTouch iPhone solution and then add additional library projects to it.
Created attachment 2556 [details]
A screenshot of the AppStore configuration
Attached is a screenshot of project I have been working on. I have not changed any configuration settings but as you can see the AppStore configuration is automatically set to Debug. This caused a massive headache for me resulting in an expedited app store review to fix the problem.
Perfect, that's what I suspected had happened as that's how I triggered the issue when trying to replicate your issue. I'll have to see what the best way of fixing this is, but it's definitely something we need to look at sooner rather than later. Maybe we could additionally print out the configuration used for each project in the build output to make it clearer as to exactly what was compiled and how it was compiled.
It looks like this bug could be resolved if we kept things simple and just had a 'Debug' and 'Release' configuration and then Simulator, IPhone and AppStore platforms. By making 'AppStore' a configuration we break the code which matches Debug csproj configurations to Debug sln configurations.
and also Release csproj configurations to Release sln configurations
That's not "keeping things simple". Overloading the use of "platform" makes things much more complicated.
I think that the logic for automatically creating solution configuration mappings should have some additional heuristics - which would improve other behaviors, not just this. When MD is looking for configurations in each project to add to each solution configuration, it could try looking for project configurations in the following order, and use the first that matches:
1) Same name and platform as the solution configuration
2) Same name as the solution configuration, and anycpu platform
3) Same name and platform as the mapped project configuration in the startup project
4) Same name as the mapped project configuration in the startup project, and anycpu platform
5) Same value of "debug" setting and same platform as the mapped project configuration in the startup project
6) Same value of "debug" setting as the mapped project configuration in the startup project, AnyCPU platform
7) First configuration with same platform as the solution configuration
8) First configuration with same platform as the mapped project configuration in the startup project
9) First configuration with anycpu platform
In this case, it would match on step 5 and find Release|iPhone.
I implemented some better heuristics in git which should help us pick out a better configuration by default. One of the tricks is the matching based on whether or not the 'DEBUG' symbol exists and it does fixthis specific case. New projects will now use their 'Release' configuration for the 'AppStore' and 'Adhoc' configurations as these do not define the 'DEBUG' symbol.
Matching on the DEBUG define is a good idea. Itook a look through the code and it's pretty close to what I proposed, AFAICT it's now:
1. Same name and platform as the solution configuration
2. Same name as the solution configuration, and anycpu platform
3. Same name and platform as the mapped project configuration in the startup project
4. Same name as the mapped project configuration in the startup project, and AnyCPU platform
5. Same value of "debug" setting and same platform as the mapped project configuration in the startup project
6. Same value of "debug" setting as the mapped project configuration in the startup project, AnyCPU platform
A. first configuration with the same value of the DEBUG define as the mapped project configuration in the startup project
7. First configuration with same platform as the solution configuration
8. First configuration with same platform as the mapped project configuration in the startup project
9. First configuration with anycpu platform
B. First configuration with same name as solution configuration
C. First configuration
The difference is the steps marked A, B, C. These are very questionable, as they could result in completely inappropriate platform combinations, and IMO would be better not to map it than to create a broken mapping. A is particularly bad since it prevents reaching 7,8,and 8, which are all better matches.
I'm reviewing the logic and matching it against what you've described. The other question I have is: Should I use 'Any CPU' or 'AnyCPU' ? I'm a little confused as both seem to be used. Is it a case of 'Any CPU' is for SLN files but AnyCPU is for csproj files?
I removed 'A' and switched the 'Any CPU' usages to 'AnyCPU'. Items 'B' and 'C' were part of the original code and I didn't want to remove them. I don't know if there are any real world examples of how the user could end up selecting a configuration using step 'B' or 'C' now that we have all the other checks in there, but it might be better to always map to something. If it is possible that a newly added project can map to 'do not build', then we need to improve the workflow so the user is automatically prompted to select the right configuration.
If you're happy with the code as-is, we can close this bug and open a new one to track that enhancement.
Good catch, it looks like sln files use "Any CPU", project files use "AnyCPU". But my point was that you didn't need them at all - the MD deserializer transparently converts them to " - inside the MD codebase you should only ever see "".
I disagree about always creating a mapping, I think that building something unexpected is worse than not building it at all. Though I guess that's debatable, so we can close this one.
I'll fix the == "" || == "AnyCPU" checks and then close this bug. Thanks for reviewing!