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´m try to Build or Rebuild the project
and show this error.
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2,2): Error XA0000: Unexpected error -
Reason: Ionic.Zip.ZipException: C:\xxxx\xxxx\xxxx\obj\Debug\__library_projects__\Refractored.FloatingActionButton\__AndroidLibraryProjects__.zip is not a valid zip file ---> System.TimeZoneNotFoundException: Exception of type 'System.TimeZoneNotFoundException' was thrown. (XA0000) (xxxx) monodroid
i´m try to clean and rebuild the project, and unsuccessfully
i´m using Xamarin Studio V 6.0 (Build 5174)
Same issue. Happened to me yesterday as a result of upgrading to Xamarin 18.104.22.168.
Do you solve the problem Kevin?
Sort of. I uninstalled Xamarin 22.214.171.124 and installed the older version 126.96.36.1990. Not the best fix but at least I can build my project again.
BTW - even though my error is identical to yours I'm using Visual Studio not Xamarin Studio.
can you give me the link to old version please?
and yes Kevin, if i try to open the project in VS, appear same error
First I went to program files and uninstalled Xamarin from my system(Win10). Then I just went to the Xamarin web site and downloaded it. It gives you the old version by default. Once installed a little 'X' shows up in your task bar telling you there's an upgrade. DONT take the upgrade. For me the download was :http://download.microsoft.com/download/E/9/2/E92A2B4D-E618-4BA2-B511-F3C8AD0CB4EA/U2-25123-20160408.4/vstoolsforxamarin.exe
which I got to from here https://www.xamarin.com/download.
Can you post some diagnostic build output and a simple repo project if possible.
Also some information on the setup of your system (OS, Language, Region etc) might be helpful
*** Bug 42095 has been marked as a duplicate of this bug. ***
Sorry Dean Ellis
actually rollback to version 188.8.131.520 to continue working.
My System :
OS : Windows 10 Enterprise 2015 LTSB
Lenguage : English
Region : Mx
*** Bug 42087 has been marked as a duplicate of this bug. ***
*** Bug 42088 has been marked as a duplicate of this bug. ***
*** Bug 42077 has been marked as a duplicate of this bug. ***
*** Bug 42137 has been marked as a duplicate of this bug. ***
I have the same error, this is my Xamarin Studio Info:
=== Xamarin Studio Enterprise ===
Version 6.0 (build 5174)
Installation UUID: ef0e8e6e-6e4e-4018-b556-9fd731e1746f
Microsoft .NET 4.0.30319.42000
GTK+ 2.24.26 (Light theme)
=== Xamarin.Profiler ===
Location: C:\Program Files (x86)\Xamarin\Profiler\XamarinProfiler.exe
=== Xamarin.Android ===
Version: 184.108.40.206 (Xamarin Enterprise)
Android SDK: C:\Program Files (x86)\Android\android-sdk
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
4.4.87 (API level 20)
5.0 (API level 21)
5.1 (API level 22)
6.0 (API level 23)
SDK Tools Version: 25.1.7
SDK Platform Tools Version: 24
SDK Build Tools Version: 24
Java SDK: C:\Program Files (x86)\Java\jdk1.7.0_79
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) Client VM (build 24.79-b02, mixed mode, sharing)
Android Designer EPL code available here:
=== Xamarin Android Player ===
=== Build Information ===
Release ID: 600005174
Git revision: 694a75f040b7f2309bc43d4f78a3a6572ca898bf
Build date: 2016-06-01 17:11:00-04
Xamarin addins: 33f406fa2dcf214012c78cb846585f062b2e1d24
Build lane: monodevelop-windows-cycle7-baseline
=== Operating System ===
Windows 10.0.10586.0 (64-bit)
Do you need any more info?
Some other interesting information to collect would be the information mentioned in Comment 7:
> Can you post some diagnostic build output and a simple repo project if possible.
> Also some information on the setup of your system (OS, Language, Region etc) might be helpful
("Diagnostic build output" refers to: https://developer.xamarin.com/guides/android/troubleshooting/troubleshooting/#Diagnostic_MSBuild_Output)
Based on the bits of information gathered so far, it seems this issue is likely related to the region and timezone settings of the system environment.
Created attachment 16482 [details]
Demo project with error
Normally gives the System.TimeZoneNotFoundException, once I added the MvvmCross or Xamarin Insights Nuget packages it starts sending the Ionic.Zip.ZipException.
Inside the zip file includes a file called "DiagnosticTrace.txt" that contains the build trace with Log verbosity as "diagnostic"
Do you have a valid region/timezone to do the test?
I disabled the AutoTimeZone and changed it from "Guadalajara, Mexico City, Monterrey" to Central Time (United States and Canada) and it started working!
Hope it gives a hint to correct the issue with all timezones
Excellent. Many thanks for the test case and the results about switching time zones in Comment 19! I have been able to replicate this problem by setting my Windows time zone to "Guadalajara, Mexico City, Monterrey" and building the test case from Comment 17.
I'll leave the engineering team to start investigating the source of the bug while I fill out a few more environment tests to be thorough.
Additional environment tests follow-up:
## Temporary workaround
Change the Window system time zone to a different time zone. For example, as reported in Comment 19, switching the time zone to "Central Time (US & Canada)" seems to work.
## Regression status: regression in Cycle 7 – Service Release 0
> BAD: XamarinVS 220.127.116.11 (34a92cd) / Xamarin.Android 18.104.22.168 (7db2aac) "Cycle 7 – Service Release 0"
> GOOD: XamarinVS 22.214.171.1240 (2e39740) / Xamarin.Android 126.96.36.199 (4e27558) "Cycle 7"
(Note to the Xamarin team: This is admittedly somewhat surprising given how few changes there were between these 2 builds (and I see nothing that looks obviously related to time zones). But I can consistently replicate this change in behavior when I switch back and forth between these 2 versions.)
## Steps to replicate
1. Set the Windows system time zone to "Guadalajara, Mexico City, Monterrey".
2. Attempt to build the test case from Comment 17. For example, on the command line:
msbuild /t:Build AsyncDemo.sln
The build fails due to a "TimeZoneNotFoundException":
> monodroid error XA0000: Unexpected error - Please file a bug report at
> http://bugzilla.xamarin.com. Reason: Ionic.Zip.ZipException:
> is not a valid zip file ---> System.TimeZoneNotFoundException: Exception of
> type 'System.TimeZoneNotFoundException' was thrown.
## Additional testing environment info (brief)
Windows 10 (64-bit), US locale
Tested with command line builds in both a VS 2013 Update 5 environment and a VS 2015 Update 2 environment.
*** Bug 42133 has been marked as a duplicate of this bug. ***
I did some tests on the zip file that was extracted and using Ionic.Zip directly on a machine with the timezone set does not produce the error. This only seems to happen when mandroid is doing the extraction.
I suspect this is to do with mkbundle in this case. I'm not sure how that handles timezones. Since its not relying on the .net runtime but the mono runtime.
I knocked up a test program to extract the file and ran it under mono on the problem machine and it failed in exactly the same way. This seems to be a mono issue.
The test app works fine under mono 4.4.0 on windows, just not under mono 4.3.2. Looks like we need to either
a) bump the mono we use for mkbundle.
b) figure out what fixed this in mono 4.4.0 and back port it to the version we use for mkbundle
The issue is as follows.
Certain versions of Mono were stripping the ")" out out of the TimeZone, this was part of the patch that added the timezone support for Windows:
This was a fix for https://bugzilla.xamarin.com/show_bug.cgi?id=2791
In 2015, we introduced a bug fix for this issue, which stopped the timezone name trimming at ")" because this was valid for Mexico:
The reason is not registered in bugzilla.
The fix happened in NOvember 6th, 2015. So it does not look like it is included in 4.4.0 series (someone better than me needs to check if this was cherry picked or not).
That said, while we have a fix there, it is not clear to me that the original code that trimmed text is correct *at all*. Looking at the CoreCLR implementation, such trimming does not take place.
> The fix happened in NOvember 6th, 2015. So it does not look like it
> is included in 4.4.0 series (someone better than me needs to check
> if this was cherry picked or not).
I cherry-picked it into 4.4 with https://github.com/mono/mono/commit/3c7a0203eeb216656ce9074b42ac612c0d60f462 (the whole thing started as PR https://github.com/mono/mono/pull/2206).
Marking as FIXED, as mandroid.exe doesn't exist in cycle8, and it was mandroid.exe which was producing the System.TimeZoneNotFoundException.
I have checked this issue with latest C8 XVS 188.8.131.529 and observed that now this issue is not exists. I have also reproduce this issue with XVS 184.108.40.206
I am successfully able to build attached sample application after following the steps mentioned in Comment 21.
Hence marking this as Verified.
*** Bug 43234 has been marked as a duplicate of this bug. ***
*** Bug 43340 has been marked as a duplicate of this bug. ***
*** Bug 43339 has been marked as a duplicate of this bug. ***
*** Bug 43341 has been marked as a duplicate of this bug. ***
*** Bug 43720 has been marked as a duplicate of this bug. ***
*** Bug 42704 has been marked as a duplicate of this bug. ***