Bug 22116 - Project name mangling results in failed Xamarin.Mac builds.
Summary: Project name mangling results in failed Xamarin.Mac builds.
Status: RESOLVED NOT_ON_ROADMAP
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Other ()
Version: 1.10.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Chris Hamons
URL:
: 22087 ()
Depends on:
Blocks:
 
Reported: 2014-08-14 13:01 UTC by Brian Berry
Modified: 2014-11-14 15:48 UTC (History)
6 users (show)

Tags:
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:
Status:
RESOLVED NOT_ON_ROADMAP

Description Brian Berry 2014-08-14 13:01:50 UTC
Observed: The new Xamarin.Mac build pipeline is
mangling the names of build artifacts when project
names contain "." in them, resulting in failed builds.

Steps to reproduce:
   * Load the current alpha build (1.11.0.1).
   * Create a new Xamarin.Mac project.
       - Default location is fine.
       - Name the project "Test.OSX".
       - Attempt to build and run.

Result:
   * The build completes without errors.
   * An attempt to run produces a modal dialog with:
      "The application has not been built."
   * Attempts to run the .app manually result in a crash.

Expected: Viable builds with compound names and no mangling.

Notes:
   * The mangling is actually something that Xamarin.iOS has been
     doing as well, though without build/run failures (just annoyance
     in having our scripts/add-ins have to look for artifacts that
     may have the mangled names).
   * By mangling I mean that the build system is removing the "." in
     the project for certain artifacts.  For the new Xamarin.Mac, this
     includes:
         - The app directory (e.g. bin/Debug/TextOSX.app in this case).
         - NOT the assembly in the X.Mac case (still Test.OSX.exe[.*]).
   * In the Xamarin.iOS case, both the .app folder *and* assembly artifacts are mangled,
     which may be a hint as to why those builds actually do run (at least consistent?).
   * If you instead make a "Test.Android" project for Xamarin.Android, a build produces:

        bin/Debug/Test.Android-Signed.apk
        bin/Debug/Test.Android.apk
        bin/Debug/Test.Android.dll
        bin/Debug/Test.Android.dll.mdb

      ... not mangled.

The net effect until today has been some dirtiness in our scripts/add-in support
in order to deal with the per-platform inconsistencies in artifact naming/locations.
Today, however, we're now faced with a target that won't even build (OSX).

Request: Honor project names literally and consistently wherever possible.  Don't mangle.
Compound names should work fine (they're useful, like "Xamarin.{Mac,Android,iOS}" are).

Many thanks!
Comment 1 Brian Berry 2014-08-14 13:24:42 UTC
*** Bug 22087 has been marked as a duplicate of this bug. ***
Comment 2 Brian Berry 2014-08-15 12:15:15 UTC
Note:  The minimum local fix to get running with the Test.OSX example above is to edit project properties and change the assembly name manually to the mangled form.  I don't think that should be the fix, of course, but FYI.
Comment 3 Chris Hamons 2014-08-15 13:06:42 UTC
I can reproduce this. It only shows up in unified projects, so probably a problem with the msbuild toolchain.

Thanks for the report.
Comment 4 Chris Hamons 2014-08-15 13:12:40 UTC
Given a project named:

A.Second.Project.With.Periods

You can work around the issue by renaming the inner executable:

ASecondProjectWithPeriods.app/Contents/MacOS/ASecondProjectWithPeriods

to

ASecondProjectWithPeriods.app/Contents/MacOS/A.Second.Project.With.Periods

This is obviously unacceptable and the build system will be taught better.
Comment 5 Brian Berry 2014-08-15 13:23:30 UTC
The temp fix here per above (confirmed to work) was to go the other way, having the assembly name lose the .'s to match the mangled pattern wholesale (the .app and the inner artifacts all the same mangled name.)   So it's probably just a matter of consistency.

However, the mangled forms *still* require us to have our addins and scripts know to remove these dots for the platforms (X.iOS, X.Mac) that do this mangling--it'd be awful nice to just have the mangling go away entirely.

This is no longer a blocker, however---just an untidiness.  So please feel free to prioritize accordingly.

Many thanks!
Comment 6 Chris Hamons 2014-11-14 15:47:20 UTC
From what I can tell, there are two issues:

1) The fact that we "sanitize" the bundle name to only have alphanumeric and _ characters. 
     I talked to the Xamarin Studio team. Requiring these "sanitized" bundle names is hard coded in more places that we'd like, and fixing that isn't happening any time soon. That is primarily what this bug is complaining about. I'm going to reject this bug as WONTFIX as this behavior will be too painful to fix compared to the benefit.

2) The fact that we crash or fail to launch if your assembly names does not match your bundle name. This is the unacceptable behavior. You ran into this by having differences in periods, but changing the assembly name to FooBar also shows the same behavior. This is now bug: https://bugzilla.xamarin.com/show_bug.cgi?id=24545