Bug 6169 - Solution configuration maps to debug project configurations by default
Summary: Solution configuration maps to debug project configurations by default
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: C# Binding ()
Version: 3.0.x
Hardware: Macintosh Mac OS
: High normal
Target Milestone: ---
Assignee: Alan McGovern
URL:
Depends on:
Blocks:
 
Reported: 2012-07-18 05:35 UTC by Dylan
Modified: 2012-10-04 07:57 UTC (History)
2 users (show)

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


Attachments
A screenshot of the AppStore configuration (96.60 KB, image/png)
2012-09-17 11:08 UTC, Dylan
Details


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 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.

Related Links:
Status:
RESOLVED FIXED

Description Dylan 2012-07-18 05:35:29 UTC
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:

#if DEBUG
        public const string ServerAddress = "http://van.dyndns-web.com/NashuaMobile/nashuamobileservice/";
#else
        public const string ServerAddress = "https://mobiapp03.exordia.co.za/nashuamobile/nashuamobileservice/";
#endif

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?
Comment 1 Mike Krüger 2012-07-18 05:44:17 UTC
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 ?
Comment 2 Dylan 2012-07-18 08:43:25 UTC
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.
Comment 3 Alan McGovern 2012-09-17 10:57:51 UTC
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?
Comment 4 Dylan 2012-09-17 11:07:17 UTC
Normally I create a new MonoTouch iPhone solution and then add additional library projects to it.
Comment 5 Dylan 2012-09-17 11:08:44 UTC
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.
Comment 6 Alan McGovern 2012-09-18 20:49:13 UTC
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.
Comment 7 Alan McGovern 2012-09-19 12:32:35 UTC
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.
Comment 8 Alan McGovern 2012-09-19 12:32:53 UTC
and also Release csproj configurations to Release sln configurations
Comment 9 Mikayla Hutchinson [MSFT] 2012-09-19 14:03:39 UTC
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.
Comment 10 Alan McGovern 2012-09-20 11:47:35 UTC
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.
Comment 11 Mikayla Hutchinson [MSFT] 2012-09-20 15:48:52 UTC
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.
Comment 12 Alan McGovern 2012-09-24 05:53:40 UTC
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?
Comment 13 Alan McGovern 2012-09-24 06:10:08 UTC
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.
Comment 14 Mikayla Hutchinson [MSFT] 2012-09-24 13:14:24 UTC
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.
Comment 15 Alan McGovern 2012-10-04 07:57:45 UTC
I'll fix the == "" || == "AnyCPU" checks and then close this bug. Thanks for reviewing!