Stable Release: Xamarin.Android 5.1.4, Cycle 5 – Service Release 2

BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
edited July 2015 in Xamarin.Android

Windows

  • Xamarin.VisualStudio_3.11.666.msi (ebae43a)

Mac

  • mono-android-5.1.4-16.pkg (5f55a9e)

Reason for release: Additional bug fixes for the "Cycle 5" Stable Release on April 29. (See the release blog for a short description of "Cycles" and "Service Releases.")

Release notes: http://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#Xamarin.Android_5.1.4

Date published: See https://releases.xamarin.com/.

Previous versions, downgrading

You can downgrade back to the previous Stable version by manually reinstalling each old package. See the KB article on downgrading. If you have a Trial or Starter subscription, feel free to contact hello@xamarin.com to request the older versions.

Older Mono package versions are not currently listed on https://store.xamarin.com/account/my/subscription/downloads. The Mono package for the previous Stable version ("Service Release 1") is available here:

Older versions (from before April 29)

If needed, you can also downgrade back to older versions (from before April 29) by manually reinstalling each old package. See the "Previous versions, downgrading" section on the April 29 release thread for the older downgrade links.

Guidelines for this thread

  1. This first post will be updated regularly.

  2. Hopefully this thread will help answer "what might break if I update to this release?"

  3. If you find a new problem that is specific to this version, please file a bug report.

  4. Please discuss older bugs that are unchanged in this release compared to the previous Stable version in Bugzilla instead.

  5. Of course for questions and discussions about topics other than bugs, feel free start new forum threads.

Fixes for widely reported known issues from older releases

  • Bug 26841 - [XamarinVS] [Android] [iOS] "The process cannot access the file ... MyApplication.dll.mdb because it is being used by another process" after debugging an app, stopping debugging, and starting debugging again. Note: see Bug 31423 under "New known issues" for a similar problem that has appeared recently for .dll files rather than .dll.mdb files.

Fixes for remaining known issues from the April 29 Stable Channel release

  • Non-public Bug 28995 - [Android] On certain devices, certain apps crash frequently due to "System.ExecutionEngineException: SIGILL".

  • Bug 30318 - [Android] Windows only: Breakpoints in PCL projects do not work after cleaning solution, redeploying, and restarting debugging. Partial workaround: delete all the bin folders in the solution after cleaning. (The next Alpha build should include this fix.)

  • Bug 30371 - [XamarinVS] [Android] Project Properties display incorrect default values for "BundleAssemblies" and "EmbedAssembliesIntoApk" if they are not explicitly specified. This means that these properties can "automatically" change to incorrect values when you update other properties under "Project Properties -> Android Options". The incorrect values can cause secondary symptoms like Bug 30334 where breakpoints are not hit in the Debug configuration.

  • Non-public Bug 30057 - [Android] Windows only: the debugger will not be able resolve breakpoints unless "Shared Runtime" is ON and the Linker is OFF (under "Project Properties -> Android Options" in Visual Studio or "Project Options -> Android Build" in Xamarin Studio). (The next Alpha build should include this fix.)

  • Bug 30072 - [Xamarin Studio] [Android] Xamarin Studio sometimes crashes with SIGABRT in gtk_text_view_validate_onscreen() after password is entered during "Import an Existing Key" in "Build -> Archive for Publishing -> Sign and Distribute" workflow.

  • Non-public Bug 29538 - [Android] Profiling via the graphical Xamarin Profiler ("Run -> Start Profiling") causes the app to crash at startup.

  • Non-public Bug 29725 - [Xamarin Studio] [iOS] [Android] Expressions in the Watch window are cleared each time you stop debugging.

Remaining known issues from the April 29 Stable Channel release, with more common or severe issues near the top

  • Bug 30513 - [Android] The logged stack traces from exceptions thrown within async methods do not include the actual location where the exception was thrown. Partial workaround: switch back to the old Xamarin.Android 4.x exception propagation style by setting the XA_BROKEN_EXCEPTION_TRANSITIONS environment variable to true (see also Bug 30513, Comment 11).

  • Bug 29326 - [Android] String resources defined in NuGet packages overwrite string resources defined in app project, causing the displayed app name to be incorrect for example. Workaround: avoid using the same string key that is used in the NuGet packages.

  • Non-public Bug 30481, Bug 29557 - [Mono] [Android] [iOS] SqlConnection.GetSchema() fails with "SourceTable is required to be a non-empty string". (A fix for this issue is planned for the upcoming "Service Release 3.")

  • Bug 30548 - [Android] Under certain conditions new threads take several seconds to start. This problem seems to be triggered by Xamarin.Insights 1.10. Partial workarounds: upgrade Xamarin.Insights to version 1.10.3, downgrade to version 1.9, or remove it entirely.

  • Bug 30915 - [Xamarin Studio] [Android] Xamarin Studio repeatedly asks for the password for the selected certificate when attempting to sign using SHA1withDSA certificates from keystore files. Xamarin Studio should instead display the error message from jarsigner: "private key algorithm is not compatible with signature algorithm" as it did in Xamarin Studio 5.8. (SHA1withRSA or MD5withRSA certificates do work without error.)

  • Bug 29731 - [Android] Android.Bluetooth.BluetoothAdapter.Enable is incorrectly marked as [Obsolete("deprecated")] for API level 20 and higher.

New known issues

  • Bug 31423 - [XamarinVS] [Android] [iOS] Locked .dll files: "Could not copy "... PortableClassLibrary1.dll" to "bin\Debug\PortableClassLibrary1.dll". Exceeded retry count of 10. Failed." This is a different problem than Bug 26841 because it affects .dll files rather than .dll.mdb files. It appears to be less common than Bug 26841, but it is under active investigation for the next service release ("Service Release 3").

  • Bug 31527 - [Android] "The following assembly referenced from ... could not be loaded: Assembly: System.Runtime ... Version: 4.0.0.0" when using the "Shared Runtime" with the linker enabled. Workaround: set "Project Options -> Android Build -> Linker [tab] -> Linker behavior" to "Don't link" in Xamarin Studio or "Project Properties -> Android Options -> Linker [tab] -> Linking") to "None" in Visual Studio. Enabling linking when the "Shared Runtime" is enabled is an intentionally untested scenario (partly because the on-device "shared runtime" assemblies will necessarily never be linked). )

  • Bug 31597 - [Android] For some projects the generated .mdb files are incorrect, causing breakpoints to be skipped or incorrect line numbers to appear in the call stacks. Candidate fix now on the Alpha channel. (Old workaround: add Condition="'$(AndroidLinkMode)' != 'None' AND '$(AndroidUseSharedRuntime)' != 'true'" to the StripEmbeddedLibraries task in C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets on Windows or /Library/Frameworks/Xamarin.Android.framework/Versions/Current/lib/xbuild/Xamarin/Android/Xamarin.Android.Common.targets on Mac.


EDIT July 01: Typo correction.
EDIT July 07: Add Android bug 31527. Add Android bug 31597.
EDIT July 17: Mark bug fixes from new Alpha channel release: 31597. Add "release announcement" tag.
EDIT July 21: Add Android bug 30513.

Posts

  • nousgoalsnousgoals AUMember, University
    edited July 2015

    Xamarin Android 5.1.4 breaks something, I backtracked to 5.1.3.1 and my Android build now works again.

    This is the sort of errors I was getting on the App crashing:
    [Mono] Assembly: System.Runtime (assemblyref_index=0) [Mono] Version: 4.0.0.0 [Mono] Public Key: b03f5f7f11d50a3a [Mono] The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/mnt/sdcard/Android/data/au.com.nousgroup.nousgoals/files/.__override__/). [Mono] Failed to load assembly PWCrossPlatformInterfacing[0x83b418] [Mono] Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. [Mono] Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. [Mono] DllImport attempting to load: '/system/lib/liblog.so'. [Mono] DllImport loaded library '/system/lib/liblog.so'. [Mono] DllImport searching in: '/system/lib/liblog.so' ('/system/lib/liblog.so'). [Mono] Searching for '__android_log_print'. [Mono] Probing '__android_log_print'. [Mono] Found as '__android_log_print'. [MonoDroid] UNHANDLED EXCEPTION: [MonoDroid] System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. [MonoDroid] File name: 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
    As it says, the error seems to be an inability to load System.Runtime which is pretty bizarre, being a standard part of the .NET portable class library.

    And going back to this previous version of Xamarin Android and everything now working again hunky-dory indicates an issue.

    Platform: Xamarin Studio 5.9.4 (build 5) on OSX 10.10.3 Yosemite.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @PhilipRyan, thanks for the report!

    The most direct way forward would be if you would be able to zip up and attach a minimal test case that demonstrates the problem on a new bug report, and then paste a link to the report back in this thread. See the bug filing KB article for some additional hints and tips about filing a bug report and minimizing the test case. Thanks!

    At first guess, this looks like it could maybe happen if the app includes a desktop .NET assembly somewhere in its dependency tree. If so, the problem would be related to the following limitation:

    Xamarin.Android is not ABI compatible with existing assemblies compiled for a different profile

    (http://developer.xamarin.com/guides/android/under_the_hood/assemblies/)

    This would also explain why the behavior could change from one version of Xamarin.Android to the next: it is an untested scenario.

  • nousgoalsnousgoals AUMember, University
    edited July 2015

    As advised, created a bug in Bugzilla: https://bugzilla.xamarin.com/show_bug.cgi?id=31527

    I wasn't able to create a minimalist version of the app which replicated the issue. Noting that doing this means: backing out of version 5.1.4 of XamAnd, working in 5.1.3.1 to create the build, then forward-upgrading back to 5.1.4 to try it out, and then finding that it does or doesn't do it, in which case, have to cycle around again.

    I did post a full Application Output log, though, of when the App failed: yes it builds, but it hangs since it can't find some file (System.Runtime, Version 4.0.0.0), where as far as I can tell, that file is there, and findable, for 5.1.3.1.

  • TomStandaert.0575TomStandaert.0575 BEMember ✭✭

    same problem, downgrading to 5.1.3.1 solved it. As soon as we upgrade to 5.1.4 we have the system.runtime not found (in our case referenced from xamarin.forms). Strangely enough on one device the problem only became apparent after clearing all application data, before that, it worked.

  • JeremyKolbJeremyKolb USMember ✭✭✭

    Now my breakpoints don't work even after deleting the bin directory.

  • JeremyKolbJeremyKolb USMember ✭✭✭

    When setting breakpoints I now get an exception "Cannot set breakpoint on the specified IL offset"

  • nousgoalsnousgoals AUMember, University

    Look at the bugzilla comments, amazingly, the Android version builds and runs properly on a "Release" build. So anyone else facing this issue, at least try that out as well. It may be that you can get away with ALWAYS doing Release builds.

    I'm still going to go back to 5.1.3.1 until someone's worked out the bug though.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @JeremyKolb, thanks for the report.

    The QA team has been trying some preliminary experiments in an effort to reproduce the "Cannot set breakpoint on the specified IL offset" error, but so far they haven't found the correct set of conditions.

    If by chance you have a particular project where breakpoints fail frequently (and a new template app does not show the same problem), then the fastest way forward would likely be if you would be able to zip up and attach that full project (or a trimmed down version of it that still has the problem) on a new bug report. (Of course, if you have a Business license or higher, you are also welcome to contact the support team and share the project that way instead.)

    In the bug report be sure to mention whether you are hitting the issue in Xamarin Studio or in Visual Studio.

    Any additional logs you can include from the build process, the IDE, or the device itself will also be helpful (see also the bug filing KB article).

    Other steps to try

    In case you haven't yet double-checked the project configuration settings for any problematic entries that might be present, it would be worth checking those quickly before filing a bug. See: http://forums.xamarin.com/discussion/comment/129263/#Comment_129263.

  • rogiheerogihee NLMember ✭✭✭

    @JeremyKolb, @BrendanZagaeski I got this same error in a popup today when debugging a normal class library (no PCL, no shared, yes they do exist ;-) and trying to add a breakpoint.

    I also have the feeling not all my breakpoints are being hit, but can't pinpoint it yet.

  • rogiheerogihee NLMember ✭✭✭

    @BrendanZagaeski : ok, this is getting weird, I an Android class library that is referencing a PCL. A breakpoint in one method is working, a breakpoint in another is not working. I have some logging, in both methods that I do see in the output.

  • I_am_a_duckI_am_a_duck GBUniversity ✭✭
    edited July 2015

    I am also seeing complete mismatch of breakpoints and actual source location in XA libraries (not PCL), resulting in breakpoints not being hit at all or being hit at completely the wrong time/location, under both VS 3.11.666 and XS 5.9.4.5.

    For example in VS2013 debug output I see:

    Resolved pending breakpoint at '[...]\Apptelic\Components\Source\CastCompanionLibrary\CastCompanionLibrary.Android\Widgets\MiniController.cs:109,1' to Android.Gms.Cast.MediaInfo Apptelic.Components.CastCompanionLibrary.Util.Utils.BundleToMediaInfo (Android.OS.Bundle wrapper) [0x00000].

    In the above case, BundleToMediaInfo.cs is not even in the same directory as MiniController.cs!!

    Note: This is resolved by rolling back to VS 3.11.590 / XS 5.9.3.1 (tested twice by rolling forward again to 666 and back to 590).

    Can someone from Xamarin please explain how such a fundamental function could be so completely broken in a 'stable' release? Surely there are QA tests for such basic functionality that are performed before a release can be shipped?!

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @I_am_a_duck, thanks for the report.

    A few things to check:

    • Do you by chance have the linker enabled in the debug configuration? If so, that could cause a problem (see for example Bug 18824). Moreover, that problem could in theory change unpredictably between releases due to differences in the IL offsets after compilation and linking. Due to these complications, the scenario of using debug symbols on Android with the linker enabled has to date not been included in the Xamarin QA testing regimen. It is in that sense "unsupported."

    • If you haven't yet double-checked the project configuration settings for other problematic entries that might be present, it would also be worth checking those quickly before filing a bug. See: http://forums.xamarin.com/discussion/comment/129263/#Comment_129263.

    • Finally, if you can reproduce the problem consistently (at least some percentage of the time) using a particular project, then the fastest way to proceed would probably be to file a new bug report that includes the example project and the steps to reproduce. See also my previous comment in the thread for a few more details. Thanks!

  • MikhailMelnikMikhailMelnik AUMember ✭✭

    Debugger is just going crazy. Application stopped on breakpoint in method A while callstack displays something like B - C - D where all three are my methods but C and D are displayed in italic and I can't activate these stackframes.

  • I_am_a_duckI_am_a_duck GBUniversity ✭✭

    Hi @BrendanZagaeski, thanks for the quick response. Sorry I didn't mention in my original message that I tried the 'usual suspects' to see if I could narrow it down for you:

    1. I tried linker both enabled (SDK only) and disabled; library breakpoints not working either way
    2. I deleted all intermediate (bin/obj) files and made clean builds; still no luck
    3. I've only seen it in my (quite large) project, which is why I presume 666 passed QA :-/

    Remember, this is a regression introduced in 666; it is not a problem with 590, with the exact same project and settings.

    I know there was an earlier problem (last year sometime?) with breakpoints in async code not being hit, but this problem is specifically a mis-match between breakpoint source location and the actual source file and location the debugger resolves it to, as shown in my output snippet above.

    HTH,
    Philip

  • UdoJoostUdoJoost DEMember

    Hello, I have problems since the last update too. The App stops direct past starting. But the if I clear the option >> Android Options/ Packaging / Use Fast Deployment (debug mode only) << it starts correctly

  • SuhaOnaySuhaOnay TRMember
    edited July 2015

    As some other posters noted, something is seriously broken mono-android-5.1.4-16. Our Xamarin.Forms application crashes just after splash screen:

    [Mono] The following assembly referenced from /storage/sdcard0/Android/data/com.mobile.xxx.android/files/.__override__/Xamarin.Forms.Core.dll could not be loaded: [Mono] Assembly: System.Runtime (assemblyref_index=0) [Mono] Version: 4.0.0.0 [Mono] Public Key: b03f5f7f11d50a3a [Mono] The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/storage/sdcard0/Android/data/com.mobile.xxx.android/files/.__override__/). [Mono] Failed to load assembly Xamarin.Forms.Core[0x5acaad60] [Mono] Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. [Mono] Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. [Mono] Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. [] Can't find custom attr constructor image: /storage/sdcard0/Android/data/com.mobile.xxx.android/files/.__override__/XXXForms.Android.dll mtoken: 0x0a000fa7 [] * Assertion at /Users/builder/data/lanes/1879/5f55a9ef/source/mono/mono/metadata/class.c:5748, condition !mono_loader_get_last_error ()' not met [mono-rt] Stacktrace: [mono-rt] [mono-rt] at <unknown> <0xffffffff> [mono-rt] at (wrapper dynamic-method) object.53d9ae64-69e5-4c8c-8575-96472241de84 (intptr,object[]) <IL 0x00018, 0x0004b> [mono-rt] at Java.Interop.TypeManager.n_Activate (intptr,intptr,intptr,intptr,intptr,intptr) [0x000c2] in /Users/builder/data/lanes/1879/5f55a9ef/source/monodroid/src/Mono.Android/src/Java.Interop/TypeManager.cs:156 [mono-rt] at (wrapper dynamic-method) object.8d65155d-3dda-4865-b91d-70b2768ea42b (intptr,intptr,intptr,intptr,intptr,intptr) <IL 0x00029, 0x0007b> [mono-rt] at (wrapper native-to-managed) object.8d65155d-3dda-4865-b91d-70b2768ea42b (intptr,intptr,intptr,intptr,intptr,intptr) <IL 0x00030, 0xffffffff>

    This also happens on Windows, 3.11.666. We had to revert back to mono-android-5.1.3. This does not occur on all devices, but we have encountered this on Asus Transformer Pad TF300GT (API 16), Genymotion Google Nexus 4 (API 19) a number of Samsung Phones. Release/Debug settings do not affect outcome.

    Unfortunately I do not have time to produce a self-containing example that demonstrates the problem, I've already spent three days to resolve this.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @SuhaOnay, that issue was filed earlier as Bug 31527. That bug report will be the best place to keep track of the details on the investigation of that problem.

    Best,
    Brendan

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    For anyone seeing issues with skipped breakpoints or incorrect line numbers in call stacks, see the first post in the thread for some new information about "Bug 31597," including a possible workaround.

  • rogiheerogihee NLMember ✭✭✭
    edited July 2015

    @BrendanZagaeski: I have check my project configuration / csproj files and did clean/rebuild many times but I get the following error when trying to set a breakpoint in VS:

    It is in the same project (Android class library) that is not hitting breakpoints at random other points when debugging. Some are hit though. The error message pops up when I try to enter a breakpoint in the editor

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @rogihee, I believe the workaround for Bug 31597 from the first post in the thread is likely to help with the "Cannot set breakpoint on the specified IL offset" error as well. I suspect the error has essentially the same underlying cause as the other reported problems with breakpoints: incorrect .mdb files.

  • SimonTaylor.2787SimonTaylor.2787 AUMember ✭✭

    My app is crashing on a Galaxy Nexus (Android 4.3) when built for debug with the "Use Shared Runtime" option. Works without that option.

    Compile using Android version is "Use Latest Platform (API Level 21), min Android to target is "API Level 15", target Android version is "Use Compile using SDK version".

    07-09 11:32:30.400 W/monodroid( 9918): Using override path: /data/data/au.com.obansolutions.mobile/files/.override
    07-09 11:32:30.400 W/monodroid( 9918): Using override path: /storage/emulated/0/Android/data/au.com.obansolutions.mobile/files/.override
    07-09 11:32:30.400 W/monodroid( 9918): Trying to load sgen from: /data/data/au.com.obansolutions.mobile/files/.override/libmonosgen-2.0.so
    07-09 11:32:30.400 W/monodroid( 9918): Trying to load sgen from: /storage/emulated/0/Android/data/au.com.obansolutions.mobile/files/.override/libmonosgen-2.0.so
    07-09 11:32:30.400 W/monodroid( 9918): Trying to load sgen from: /data/app-lib/au.com.obansolutions.mobile-1/libmonosgen-2.0.so
    07-09 11:32:30.400 W/monodroid( 9918): Trying to load sgen from: /data/app-lib/au.com.obansolutions.mobile-1/libmonosgen-32bit-2.0.so
    07-09 11:32:30.400 W/monodroid( 9918): Trying to load sgen from: /system/lib/libmonosgen-2.0.so
    07-09 11:32:30.400 F/monodroid( 9918): cannot find libmonosgen-2.0.so in override_dir: /data/data/au.com.obansolutions.mobile/files/.override, app_libdir: /data/app-lib/au.com.obansolutions.mobile-1 nor in runtime_libdir as: /system/lib/libmonosgen-2.0.so
    07-09 11:32:30.400 F/monodroid( 9918): Do you have a shared runtime build of your app with AndroidManifest.xml android:minSdkVersion < 10 while running on a 64-bit Android 5.0 target? This combination is not supported.
    07-09 11:32:30.400 F/monodroid( 9918): Please either set android:minSdkVersion >= 10 or use a build without the shared runtime (like default Release configuration).
    07-09 11:32:30.416 I/ActivityManager( 377): Process au.com.obansolutions.mobile (pid 9918) has died.

  • rogiheerogihee NLMember ✭✭✭

    @BrendanZagaeski : I modified my Android.Common.Targets to have this:

    <Target Name="_StripEmbeddedLibraries" Inputs="@(ResolvedAssemblies)" Outputs="$(_AndroidStripFlag)" Condition="'$(AndroidLinkMode)' != 'None' AND '$(AndroidUseSharedRuntime)' != 'true'" DependsOnTargets="_CopyIntermediateAssemblies;_CopyMdbFiles"> <StripEmbeddedLibraries Assemblies="@(ResolvedAssemblies->'$(MonoAndroidIntermediateAssemblyDir)%(TargetPath)%(Filename)%(Extension)')" /> <Touch Files="$(_AndroidStripFlag)" AlwaysCreate="true" /> </Target>

    I then set 2 breakpoints: 1 from my shared project with my viewmodels and then the Android Class library, the first line in the method I call.

    In the output I then see:
    Error while resolving expression: Object reference not set to an instance of an object.

    In the Xamarin.Log tab I see, dunno if it is related:

    [E:]: Error finding Android/Java SDKs System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\Rogier\Documents\Android\ndk\android-ndk-r8d\toolchains'. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileSystemEnumerableIterator1.CommonInit()
    at System.IO.FileSystemEnumerableIterator1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler1 resultHandler, Boolean checkHost)
    at System.IO.Directory.EnumerateDirectories(String path, String searchPattern)
    at Xamarin.AndroidTools.AndroidSdkBase.Initialize(String androidSdkPath, String androidNdkPath, String javaSdkPath)
    at Xamarin.AndroidTools.AndroidSdk.Refresh(String androidSdkPath, String androidNdkPath, String javaSdkPath)`

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @rogihee, you'll want to move the Condition onto the StripEmbeddedLibraries task itself:

    <Target Name="_StripEmbeddedLibraries"
      Inputs="@(ResolvedAssemblies)" 
      Outputs="$(_AndroidStripFlag)"
      DependsOnTargets="_CopyIntermediateAssemblies;_CopyMdbFiles">
        <StripEmbeddedLibraries
          Condition="'$(AndroidLinkMode)' != 'None' AND '$(AndroidUseSharedRuntime)' != 'true'"
          Assemblies="@(ResolvedAssemblies->'$(MonoAndroidIntermediateAssemblyDir)%(TargetPath)%(Filename)%(Extension)')" />
        <Touch Files="$(_AndroidStripFlag)" AlwaysCreate="true" />
    </Target>
    
  • SeanMattoxSeanMattox USMember ✭✭

    Oof, this has broken debugging at a really inopportune moment. -_-

    The StripEmbeddedLibraries workaround is not working for me. I've tried additionally clearing all obj and bin files, but no joy.

    How does one revert to the previous release?

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    How does one revert to the previous release?

    @SeanMattox, see the "Previous versions, downgrading" section in the first post in the thread. It's mentioned briefly there, but really don't hesitate to write in to the email support to request the complete set of previous downgrade links. I find it easier to work with the complete list of links rather than picking each individual one from the downloads page. (Side note: I have also requested a change in the structure of the downloads page to make this easier in the future.)

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @ Simon.Taylor, thanks for the preliminary report. I have copied this initial information into a new bug report here: https://bugzilla.xamarin.com/show_bug.cgi?id=31807. I have included some follow-up questions about the issue on the bug report.

  • JeremyKolbJeremyKolb USMember ✭✭✭

    @BrendanZagaeski How do the incorrect mdb files work with Visual Studio? Are they converted to pdbs?

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @JeremyKolb, for the purposes of the incorrect .mdb files, the .pdb files are "ignorable." The Mono soft debugger uses only the .mdb files. On Windows, I think all the .mdb files that are generated during the build are created by pdb2mdb. As I understand it, the problem for Bug 31597 is that the assemblies are being modified after the .mdb (and .pdb) files have been created. The IL offsets in the modified assemblies therefore no longer match up with the .mdb files.

This discussion has been closed.