Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
I have a library project that has a dependency on PList.net (https://www.nuget.org/packages/plist.net/1.0.0) that is included in a Mac application. The Mac app runs fine when built under Debug, but fails with a FileNotFound exception loading PList library when built under Release. The problem setting appears to be "Include the mono runtime in the application bundle". When cleared, the Release build works fine.
The description is a bit too general. Can you provide a test case that shows the issue ?
Created attachment 7099 [details]
Reproducible test case
Added project that illustrates bug.
Run under Debug, and you'll get an exception on the PListRoot.Load("test") line, which is fine because file named "test" is nowhere to be found.
Run under Release and the app crashes with FileNotFound exception on PList.dll.
I can reproduce with the issue with the test case.
So I have a work around for you, but it is a bit painful.
When you build your project, if you bring up the errors pad and click "Build Output", one of the lines will look like:
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/bin/mmp -nolink "-minos=10.6" --sdkroot "/Applications/Xcode6-Beta2.app/Contents/Developer" -o "/Users/donblas/Downloads/ReleaseBugTest/MacApp/bin/Debug" -n "MacApp" --profile "4.5" --debug -a "/Users/donblas/Downloads/ReleaseBugTest/LibWithPackageReference/bin/Debug/LibWithPackageReference.dll" -a "/Library/Frameworks/Mono.framework/Versions/3.4.0/lib/mono/4.5/System.dll" -a "/Library/Frameworks/Mono.framework/Versions/3.4.0/lib/mono/4.5/System.Xml.dll" -a "/Library/Frameworks/Mono.framework/Versions/3.4.0/lib/mono/4.5/System.Core.dll" -a "/Library/Frameworks/Mono.framework/Versions/3.4.0/lib/mono/4.5/System.Xml.Linq.dll" -a "/Library/Frameworks/Mono.framework/Versions/3.4.0/lib/mono/4.5/System.Drawing.dll" -a "/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/XamMac.dll" -a "/Library/Frameworks/Mono.framework/Versions/3.4.0/lib/mono/4.5/System.Core.dll" "/Users/donblas/Downloads/ReleaseBugTest/MacApp/bin/Debug/MacApp.exe"
This is Xamarin Studio calling an internal tool called mmp to bundle your application up.
To work around your issue, before the last parameter "/Users/donblas/Downloads/ReleaseBugTest/MacApp/bin/Debug/MacApp.exe" you need to add:
and run the command on the OS X terminal. You'll need to do that after every build until the issue is fixed.
With obviously "<path_to_PList.dll>" being the full path to a copy of PList.dll on your system.
So this *is* rather painful because it throws a monkey wrench into CI. Any word on fix ETA?
I found another work around that is less painful (but still painful).
You can "un-package" your packages and convert them into regular assembly references.
I copied PList.dll to the top level your your example project, removed the package references and added normal assembly references to Plist.dll.
That worked around the bug as well, and would let your CI continue to work, but would require project changes.
I plan on hopefully looking at fixing this soon, but it will take some time for the fixes to reach stable, so I'd like to find a workaround for you until then.
Thanks, Chris, that's definitely a bit less painful. Any chance you could qualify "soon" a bit better? (ie. are we talking days, weeks, or months?)
For normal bug like this with a somewhat reasonable workaround, "soon" normally means the next normal release.
I can not promise anything at the moment, but 1-2 months to reach stable is a very reasonable guesstimate (sooner if you are willing to test it when it hits alpha\beta channel).
-- Chris H
Fixed in master - e55206180408f73139cfddb3cf5d83de387f84ca.