Bug 1374 - Project Options / iPhone Build / additional mtouch arguments not saved correctly!!
Summary: Project Options / iPhone Build / additional mtouch arguments not saved correc...
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Model ()
Version: 2.8
Hardware: Macintosh Mac OS
: Low normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-10-09 02:01 UTC by Wei-Yuen Tan
Modified: 2016-12-16 16:56 UTC (History)
6 users (show)

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


Attachments
somehow this SLN file is storing TWO sets of additional mtouch arguments, inconsistently displayed!!! (6.16 KB, application/x-zip-compressed)
2011-10-09 02:03 UTC, Wei-Yuen Tan
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 Wei-Yuen Tan 2011-10-09 02:01:48 UTC
Replication steps:

1. Create a new solution: C# / MonoTouch / iPhone / Empty Project.  Call it anything.

2. Being a new solutions, there should be only included project. Open the project options.

3. Click immediately on the iPhone Build category in the left pane.  Enter something into the Additional mtouch arguments (e.g. "foo").

4. Click on another category in the left pane, e.g. iPhone Bundle Signing.  Then click back again on iPhone Build.  The Additional mtouch arguments are gone!!!!

5. Stay where you are...entering something again into the Additional mtouch argument, but something different from what you first entered (e.g. "bar").

6. Click OK to save the project options.

7. Re-open the project options, go to iPhone Build.  In Additional mtouch arguments, it shows you what you entered the FIRST time!!!!

8. Click again on another category (e.g. iPhone Bundle Signing), then click back again on iPhone Build.  In Additional mtouch arguments, it now shows you what you entered the SECOND time!!!!

Furthermore, I have examined the build output on building my projects, and this yields actual differences in what build actions happen.  Very frustrating...

The SLN file that I just replicated the problem with from scratch is attached.
Comment 1 Wei-Yuen Tan 2011-10-09 02:03:25 UTC
Created attachment 648 [details]
somehow this SLN file is storing TWO sets of additional mtouch arguments, inconsistently displayed!!!
Comment 2 Wei-Yuen Tan 2011-10-09 02:18:33 UTC
I just noticed that this applies too to other options that you change in the iPhone Build category.  E.g. if you change the Linker behaviour on first visiting the iPhone Build category, click away to another category and then come back, your options have "disappeared"!!

But again, if you save your project options and then re-open then, you'll see that the changes you made are visible on first visiting iPhone Build options!!!
Comment 3 Mikayla Hutchinson [MSFT] 2011-10-09 10:07:51 UTC
Additional mtouch arguments are per build configuration. This is by design. You can switch which configuration you're editing using the combos at the top of the options panels.

The reason it's changing automatically in the sequence of operations you originally describe is that is that the signing options panel doesn't apply to "iPhoneSimulator" configurations, so it switches the configuration to a device "iPhone" configuration. We could fix this by having it instead display a blank panel and a "The options are not valid for the current configuration" message.
Comment 4 Lluis Sanchez 2011-10-10 12:14:10 UTC
Showing a "options are not valid" message isn't a good solution, because it will require manually selecting the iPhone configuration every time you want to change the signing options.
Comment 5 Mikayla Hutchinson [MSFT] 2011-10-10 17:58:44 UTC
Lluis, that's not really a good argument - that "problem" applies to changing configuration-specific options for *any* configuration other than the selected configuration.

The fact that when you switch to the "Bundle Signing" panel it can automatically switch the selected configuration from "Debug|iPhoneSimulator" to "Debug|iPhone" only helps if that was the configuration whose signing options you wanted to alter. If it wasn't, it's confusing. Many people don't notice that the selected configuration change and get surprised when they switch back to another panel and things have changed. Often they didn't actually want it to change - they were simply looking through all the panels to find an option.

On the whole the automatic switching seems to be more confusing than useful.
Comment 6 Lluis Sanchez 2011-10-11 00:18:05 UTC
I know that the current behavior can be confusing, I'm not discussing that. I'm just pointing out that the behavior you propose may also cause confusion and may be annoying to the users. I think so because I implemented it and I found it annoying. Consider this scenario:

* I want to change the signing options, so I click on the Bundle Signing node.
* I see a message saying that the options are not valid for the current configuration. I wonder why they are not valid and how is that related to the current configuration.
* I discover that I can access the options by selecting the only single option available in the configurations combo.
* It leaves me wondering why MonoDevelop can't just select that only option by default. All I want to do is set the signing options. Why do I have to tell MonoDevelop to use the device configuration if that's the only possible option? Let's file a bug...
Comment 7 Wei-Yuen Tan 2011-10-12 02:26:31 UTC
Luis, I get you now, but I gotta disagree with you strongly. I think this is poor interface design. If options are not valid for the current configuration, there should be an alert to the user to that effect!  The configuration that your IDE is in should NOT automatically change on the user -- and then if it did then there should be a VERY obvious alert to the user.

The fact that you are the one who implemented this "feature" indicates that you've tailored the application behaviour to suit your personal habits and preferences, rather than consider how the application behaviour could be easily misinterpreted by other users.  You've sacrificed transparency and clarity for the sake of your own idea of convenience.
Comment 8 Rolf Bjarne Kvinge [MSFT] 2011-10-12 04:47:06 UTC
(In reply to comment #4)
> Showing a "options are not valid" message isn't a good solution, because it
> will require manually selecting the iPhone configuration every time you want to
> change the signing options.

It will require manually selecting the iPhone configuration every time you want to change the signing options *and the current configuration is iPhoneSimulator*. How often does that happen?

I find the current behaviour very confusing and was just about to file a bug about it until I figured out what was going on.

As a sidenote I think the best option would be to gray out the entire page if it's not applicable to the current configuration.
Comment 9 Wei-Yuen Tan 2011-10-12 04:50:40 UTC
I like Rolf's idea of graying out (i.e. disabling) options that are irrelevant or appropriate in the current context.
Comment 10 Lluis Sanchez 2011-10-13 06:51:47 UTC
> Luis, I get you now, but I gotta disagree with you strongly. I think this is
> poor interface design. If options are not valid for the current configuration,
> there should be an alert to the user to that effect!  The configuration that
> your IDE is in should NOT automatically change on the user -- and then if it
> did then there should be a VERY obvious alert to the user.

I agree that there is a problem here. I never defended the current behavior, I just pointed out that the proposed solution may also have its share of problems.

> The fact that you are the one who implemented this "feature" indicates that
> you've tailored the application behaviour to suit your personal habits and
> preferences, rather than consider how the application behaviour could be easily
> misinterpreted by other users.  You've sacrificed transparency and clarity for
> the sake of your own idea of convenience.

You are mistaken. I did not implement that feature, so I could hardly sacrifice anything for my own convenience.
Comment 11 Greg Munn 2016-12-16 16:56:29 UTC
This specific issue has been resolved, since all of the iOS specific project options have the configuration selector.