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 can confirm this bug :
On Release on PC Proguard not working.
it's NOT working on PC (nor VS nor XS on windows)
But it's working on mac.
please fix it .
Related to character encoding as described here:
Issue is related to Proguard not being able to read the cfg file. Closing bug report.
but i cannot open the link (404).
can you post a good one , please?
it is not that.
changed to utf-8 without BOM and still don't work.
Information from the private Github (my mistake - I didn't realise it was private):
When creating a proguard.cfg file in VS/XS it may not have the proper encoding and thus will throw errors such as Unknown option '-keep' in line 1 of file 'proguard.cfg' This will throw any error with respect to what you're doing in proguard
Thus when creating a file, you can use Notepad++/etc to change the Encoding:
Encoding -> Encode in UTF-8 Without BOM
Zahi has confirmed that this fix has not worked for him. Information provided for the sake of anybody else who has a problem that may benefit from the potential fix.
The path to Zahi's Android SDK contained space characters which was causing a problem with Proguard.
A symlink was created pointing to the SDK and the problem is now resolved:
Open over a year and no fix for the spaces in path problem. The bug isn't resolved by a workaround IMO.
GuardRex is correct. A workaround is no fix. It should be fixed by Xamarin.
Most others report that the Android SDK is usually in %localappdata%. That would be a path without spaces and with write permission.
Just Reopend it.
Heard it's still now working
Can confirm, this bug still exists. Using Xamarins latest as well as VS 2015.
Also having this issue when trying to build in release mode.
This look like an issue in android targets. Moving to android team in order to verify it.
The reason for the error is there is a space in the path to the PROGUARD. Proguard is in the Android folder in Program Files (x86) and there is a spaces between "Program Files (x86)".
I solved it using a symbolic-link for the program files..
*** Bug 56393 has been marked as a duplicate of this bug. ***
Created attachment 22254 [details]
IDE Logs and Detailed Output Stack Trace
Issue is reproducible on the following build as well:
- Microsoft Visual Studio Enterprise 2017
- Version 15.2 (26430.6) Release
- Microsoft .NET Framework Version 4.7.02046
- Xamarin 188.8.131.529 (846ca8f)
- Xamarin.Android SDK 184.108.40.206 (4c5719b)
- Xamarin.iOS and Xamarin.Mac SDK 10.10.0.34 (462bb65)
Detailed Build Info:
Logs and Detailed Output Stack trace attached for reference.
I will copy and paste an excerpt from the log file in Comment 16 so that the text of the bug report will include the most common error message users see in this scenario.
## BAD Results with XamarinVS 220.127.116.119 (846ca8f), 18.104.22.168 (4c5719b) (from the build log attached in Comment 16)
The build fails because ProGuard hits an error "C:\Program Files (Access is denied)":
> Environment Variables passed to tool: (TaskId:229)
> PROGUARD_HOME=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\proguard (TaskId:229)
> JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8 (TaskId:229)
> C:\Program Files\Java\jdk1.8.0_131\\bin\java.exe -jar
> "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\proguard\lib\proguard.jar"
> -include "C:\Program Files (x86)\Android\android-sdk\\tools\proguard\proguard-android.txt"
> -include obj\Release\proguard\proguard_xamarin.cfg
> -include obj\Release\proguard\proguard_project_references.cfg
> -include obj\Release\proguard\proguard_project_primary.cfg
> "-injars 'obj\Release\proguard\__proguard_input__.jar';'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v7.1\mono.android.jar'"
> "-libraryjars 'C:\Program Files (x86)\Android\android-sdk\platforms\android-25\android.jar'"
> -outjars "obj\Release\proguard\__proguard_output__.jar"
> -optimizations !code/allocation/variable (TaskId:229)
> PROGUARD : error : C:\Program Files (Access is denied)
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 (TaskId:229)
> The command exited with code 1. (TaskId:229)
Created attachment 22649 [details]
IDE and Debug Pad logs
*A* problem, incredibly, is the need to *double-quote* `-include`:
This is bad:
> java -jar proguard.jar -include "path with spaces.txt"
This is good:
> java -jar proguard.jar -include "'path with spaces.txt'"
This issue *should* have been fixed with:
...and will be present in the forthcoming Xamarin.Android 7.4 preview ("d15-3").
Right idea, wrong location: xamarin-android/6829b7d1 fixes the <CreateMultiDexMainDexClassList/> task, but *not* the <Proguard/> task.
The <Proguard/> task -- and all other tasks which hit `proguard.jar` -- needs to be fixed as well.
Fixed in xamarin-android/master/8467ad6c
*** Bug 54642 has been marked as a duplicate of this bug. ***
This is still reproducible using:
> Xamarin 22.214.171.1247 (750994b)
> Xamarin.Android SDK 126.96.36.199 (5f3167a)
Diagnostic build output:
Fixed in Xamarin-android/master/fa0f2694
You set the status to resolved/fixed very early.
I'd rather you set that only after a version with the fix has been released to the public (can be alpha) and tested with that version.
> only after a version with the fix has been released to the public
In short, that is not how the statuses are used by the Xamarin team on Bugzilla, and changing that convention across the Xamarin team would not be a small change. Having an open bug tracker that is used both directly by the Xamarin engineering team for internal tracking purposes and by users involves some trade-offs. The usage of the statuses for engineering tracking is one such trade-off. The "RESOLVED FIXED" status means that a fix has been committed to the source code branch for the appropriate product. That status indicates to the Xamarin team that the bug will be ready for _verification_ in an upcoming build.
Also in case it is of interest, do note that xamarin-android is an open source repository [1-2]. That open source repository has continuous integration builds. For example, the commit mentioned in Comment 25 corresponds to:
The build results from that job are browsable here: