Bug 544 (dpisimfail) - Deployment to iPhone Simulator fails
Summary: Deployment to iPhone Simulator fails
Alias: dpisimfail
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 4.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Jeffrey Stedfast
Depends on:
Reported: 2011-08-30 13:45 UTC by Derik Palacino
Modified: 2011-08-31 14:47 UTC (History)
3 users (show)

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

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:

Description Derik Palacino 2011-08-30 13:45:41 UTC
When an iOS project in MonoDevelop, create using the MonoTouch add-in, has a project name that does not match the folder containing the project, the app will not deploy to the simulator. No errors, warning, or informational messages are displayed. There is no notification of failure to the user/developer. This issue does not exist when the project name is identical to the containing folder name, and can be corrected by changing the name of the project back to the name of the containing folder.

1) MonoDevelop 2.4.2
2) XCode/IB 3.2.6
2) MonoTouch

Steps to reproduce:

1) Open MonoDevelop
2) Select File -> New -> Solution
3) Expand "C#"
4) Select "iPhone and iPad"
5) Select any project type
6) Provide a solution name and project name and directory
7) Right click the project and select "Rename" (Command+R)
8) Provide a different name, without or without spaces
9) Run the project on the iPhone simulator

You'll observe that the simulator may start with only a black screen. If you start the emulator first and then run the project on it, you'll observe the emulator in its resting state without the app installed or running.

For additional information please reference the forums @ http://monotouch.2284126.n4.nabble.com/App-won-t-install-launch-in-emulator-td3778978.html
Comment 1 Mikayla Hutchinson [MSFT] 2011-08-30 13:52:56 UTC
The blank screen is caused by having an app bundle with an invalid character in its name, such as a space. Newer version of MonoDevelop automatically correct this.

To change the name of the app bundle, you need to change the output name in the project options, not the project name. Changing the project name doesn't change the app bundle name.
Comment 2 Derik Palacino 2011-08-30 14:10:18 UTC
This is an issue regardless of the characters used in the project name and has nothing to do with the bundle name or identifier.

I carefully documented the steps to reproduce and if you follow them you'll find the issue that I'm reporting. Please specifically note step #8 which indicates the issue exists without or without spaces in the name.

The issue is that unless the project name (not the bundle name) is identical to the containing folder name, the deployment will fail.
Comment 3 Mikayla Hutchinson [MSFT] 2011-08-30 14:33:05 UTC
By the "bundle name" I mean the name of the actual app bundle on the disk, not the bundle identifier. Step 8 doesn't change the name of the app bundle, it only changes the display name in the manifest.
Comment 4 Derik Palacino 2011-08-30 14:37:25 UTC
Right, but it also changes the name of the csproj file (is that what you mean by bundle on disk). When the project file name doesn't match the containing folder name the deployment fails.

This fails to deploy:

This successfully deploys:

Are we talking about the same issue?
Comment 5 Mikayla Hutchinson [MSFT] 2011-08-30 17:55:17 UTC
My apologies, I investigated and found that the project name does set the bundle name. The output name set the name of the native executable inside the app bundle. However, I'm still pretty sure that the name of the folder containing the project has nothing to do with it.

It may be that MonoDevelop is miscompiling the app bundle in the case where the project name and the output name are not the same, or it might be a problem with the mtouch simulator deployment. Jeff, could you investigate?
Comment 6 Derik Palacino 2011-08-30 17:59:38 UTC
No worries, I'm glad you were able to make some sense of my ramblings. The folder name may not have anything t odo with it, but naming the project the same as the folder was the only thing I could get to work. Like you said, it may have nothing to do with it, it may be another variable, but from a user perspective it appeared to be the folder name so that what I posted because it's what made it work for me.
Comment 7 Jeffrey Stedfast 2011-08-30 18:07:40 UTC
Sure, I can look at this tomorrow.
Comment 8 Jeffrey Stedfast 2011-08-31 13:48:50 UTC
I must be doing something wrong because I haven't been able to reproduce this on MonoDevelop 2.8 master, MonoDevelop 2.6, nor MonoDevelop 2.4.2(+hotfix) using MonoTouch 4.0.6

I also tried building the project before renaming in case that made a difference (figuring that maybe the problem was caused by an unclean build), but that didn't cause it.

I've been naming my project "Bug544" and renaming the project node to "Bugzilla544"

I also just tried creating a project called "MyProject" and renaming it to "ChangedProject" and still it continued to work, launched in a fresh simulator.

I also tried keeping the simulator up and going through the steps (creating a new project, renaming it) and running the app installs it to the already-running simulator and it starts up just fine.
Comment 9 Derik Palacino 2011-08-31 14:14:28 UTC
I just tried again and couldn't reproduce it either. Perhaps it was a fluke or other issue with temporarily corrupt state. I'm sorry you took the time to research this one. Next time I'll tripple check before sending a bug in.
Comment 10 Jeffrey Stedfast 2011-08-31 14:47:41 UTC
Don't worry about it, but thanks for confirming my sanity ;-)

I guess we close this for now?