Bug 24361 - Project Name Hard Coded to App Bundle Directory Name
Summary: Project Name Hard Coded to App Bundle Directory Name
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: iOS ()
Version: 3.7
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-11-08 01:17 UTC by Anonymous
Modified: 2016-12-23 19:10 UTC (History)
4 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 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 Anonymous 2014-11-08 01:17:33 UTC
For some crazy reason someone at Xamarin decided to have the Project Name be hard coded to also be the App "bundles" directory name in the build out put folder. This is crazy because you get a warning when the Executable Name and the App Bundle name are different, a warning that explains bad things could happen if they are not the same.

I would suggest since the App Bundle name and the Executable Name should never be different really, that you make it impossible for them to be different. This should be easy to do since there is this great field where you set the Assembly Name (aka Executable Name) on the project. 

The nice thing about using this field is that they will always be the same, which means you no long need to check to see if they are different which means you can delete the code that monitors for this and triggers the warning which is a good thing when you can delete code and make things simpler.

The field "Project Properties > Application > Assembly Name" should also be used to create the folder in the build output that has the extension of .app (aka an App Bundle I assume).

Comment 1 Parmendra Kumar 2014-11-10 12:35:22 UTC
I have checked this issue with steps mentioned in the bug description, I have observed that When we have changed the ("Project Properties > Application > Assembly Name") Assembly Name the project build/deploy successfully.
Please check the Screencast and let we now if I have missed anything.

Build Log:https://gist.github.com/Parmendrak/5714587fb68b7b008d2f
Mtbs Log:https://gist.github.com/Parmendrak/604ea17dbc7f47b89a96
ZipXap Log:https://gist.github.com/Parmendrak/5047a6de2e587b577787

Environment Info:
Microsoft Visual Studio Professional 2013
Version 12.0.30723.00 Update 3
Microsoft .NET Framework
Version 4.5.51641

Comment 2 Anonymous 2014-11-10 12:55:44 UTC
That is a workaround NOT A SOLUTION and is implied in my bug. Plus this is how everyone currently today has to workaround the warning. 

The solution is not to ever depend on naming any file after the name of a Project. The only file that should be in sync with the name is the name of the CSProj file itself and thats it.

The point is the WARNING shouldn't exist, you shouldn't need this warning, you should already base the name of the app bundle on the assembly name, and not the project name. If you base it on the assembly name it can never be different and you get to delete code that is used to provide the warning. 

The point is that doing it by the assembly name and not the project name prevents bugs, and makes it so the user can't make them different.

This shouldn't be difficult to fix unless you code it in some crazy obtuse way, you should only need to change where you pull the name of the app bundle from, I mean you don't have to remove the checks for the assembly name mismatching with the app bundle name in the first release of the fix, just a recommendation since it should never get executed once this is fixed.
Comment 3 Anonymous 2014-11-10 12:56:18 UTC
Changed from needs info to reopened.
Comment 4 Jose Gallardo 2016-12-23 19:10:27 UTC
Hi Rodney,

Since this is an old bug, and we've implemented several improvements in our build system, and we're indeed using the Assembly name for generating the app bundle folder, I'll mark this bug as Resolved / Fixed.
If you can still reproduce it with latest bits, please feel free to reopen it and we'll investigate.