Stable Release: XamarinVS 3.11.836, Cycle 5 – Service Release 3

BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

Windows

  • Xamarin.VisualStudio_3.11.836.msi (ed5c750)
  • Xamarin.VisualStudio_3.11.837.msi (f10676f) (Hotfix)

Mac Build Host

  • monotouch-8.10.4.46.pkg (2c66d2f)

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

Release notes: http://developer.xamarin.com/releases/vs/xamarin.vs_3/xamarin.vs_3.11/

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

Apart from the hotfix for Android SDK Tools 24.3.4, these versions are unchanged from the Cycle 5 – Service Release 3 Beta release.

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 [email protected] 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 2") is available here:

Older versions (from before April 29)

If needed, you can 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 Stable 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 known issues from recent releases

  • 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. Possible 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.

  • Bug 30958 - [iOS] "Invalid UIDeviceFamily - The Info.plist of Apple Watch application 'MyApp.app/PlugIns/com.myapp.watchkitextension.appex/MyAppWatchKitApp.app' contains an invalid UIDeviceFamily value of '1'" when submitting WatchKit application. This appeared recently due to a change in the ckecks Apple performs during app submission. See https://releases.xamarin.com/ios-hotfix-for-watch-app-submission-technical-bulletin/ for additional details.

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).

  • Non-public Bug 30481, Bug 29557 - [Mono] [Android] [iOS] SqlConnection.GetSchema() fails with "SourceTable is required to be a non-empty string". Now fixed on the Beta channel.

  • 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 29745 - [iOS] Error due to duplicate symbols during native compilation for device: "duplicate symbol _monoeg_g_array_new" (and many similar messages). Workarounds: disable profiling under "Project Properties -> iOS Build", or if your app uses the -all_load linker flag (via either gcc_flags or LinkerFlags) try removing it.

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

  • Bug 31379, Bug 31560 - [iOS] Enabling the linker when the app references PCL projects that include "duplicate" System.Threading.Tasks references (for example when using the "Microsoft.Net.Http" NuGet in a .NET 4.0 PCL) causes "Could not load file or assembly 'System.Threading.Tasks'" on the simulator. This bug has in fact existed since the original April 29 release of Cycle 5, but until Service Release 2 it had been obscured by the closely related Bug 29211. The bug only affects simulator builds and has fairly easy workarounds, so it is minor in severity. Workarounds: disable the linker in the iPhoneSimulator configurations or add -linkskip=System.Threading.Tasks under "project options -> iOS Build -> Additional mtouch arguments".

Remaining known issues from Cycle 5 – Service Release 2

  • 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. The results to date suggest that it is a bug in Visual Studio itself rather than in the Xamarin extensions. For example, it appears to be possible to hit the problem using a Windows Phone project, with no Xamarin involvement at all. The recent changes to the Xamarin "Clean project" process to properly remove stale files might have caused this to become easier to hit with Xamarin projects. In any case, it is still under investigation.

Remaining known issues from before the April 29 Stable Channel release

(For issues that might behave differently for some customers after updating to this new release, or that might be difficult to find via Bugzilla.)

  • Bug 28027 - [XamarinVS] [iOS] The debugger sometimes fails to connect properly after the app launches. This means breakpoints will not be hit during that launch of the app and the "Output -> Debug" window will be blank. Repeating the steps of (a) stopping the debugger and (b) relaunching the app will eventually lead to a successful connection. This problem has existed since at least XamarinVS 3.9.483, but some recent reports suggest that it has become more common for certain users recently. The problem might be caused by a race condition. Based on that guess, the recent releases might have changed some timings and increased the probability of hitting the issue on a wider range of system configurations. The bug is under active investigation.

  • Bug 29897 - [XamarinVS] [iOS] Breakpoints sometimes don't work when debugging on iOS device. Based on the observed behavior of this problem, it appears to have the same underlying cause as Bug 28027.


EDIT Aug 20: Update version numbers for Android SDK Tools 24.3.4 hotfix.
EDIT Aug 21: Correct the section on downgrading.
EDIT Aug 25: Update for Service Release 4 Beta versions. (Bug 30481)

Posts

  • NMackayNMackay GBInsider, University mod
    edited August 2015

    @BrendanZagaeski

    Debugging is broken yet again in iOS VS2013 (SP4) with 3.11.836. Even when you delete bin and obj folder, clean etc etc the breakpoints no longer trigger at all, it wasn't perfect by any means in .666 with iOS but they did trigger.

    It's kind of hard not to have a sense of humor failure with Xamarin. What gives? I can't even mention this is broken internally as it's to personally embarrassing :neutral:

    ps

    Android seems okay.

  • NMackayNMackay GBInsider, University mod

    @BrendanZagaeski

    Panic over, it works if you disable the linker in iOS.

    It is still not detecting changes to PCL libraries like .666. If you change a page and run you don't see the changes. You have to delete obj & bin folders and recompile the PCL's but I can live with that.

    Sense of humor has been restored.

  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    @BrendanZagaeski:

    Unfortunately, I have updated my whole Environment

    I have posted my (sad) findings here:
    http://forums.xamarin.com/discussion/41844/my-findings-after-test-if-the-newest-xamarin-vs-integration-software#latest

    Since the update, I'm not able to build/debug for Android anymore!

    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. The results to date suggest that it is a bug in Visual Studio itself rather than in the Xamarin extensions. For example, it appears to be possible to hit the problem using a Windows Phone project, with no Xamarin involvement at all. The recent changes to the Xamarin "Clean project" process to properly remove stale files might have caused this to become easier to hit with Xamarin projects. In any case, it is still under investigation.

    I have this problem now with changing .dll's (first it was Newtonsoft.Json.dll, later it was MyAppName.Android.dll)
    As I don't had this problem before the update, it is not a VS-problem (at least not only).
    Note: By doing my tests with "Process-Monitor" and all events (> 4 Mio during test), I was able to build one time -> so it may be a timing-problem (as the full blown "Process-Monitor" has slowed down my machine).

    In any case, it is still under investigation.

    What does this means - what is the current standing...?

    As I wrote, I'm not able to build anymore for Android now....
    Is there a fix for that anytime soon, or do I have to downgrade...?

    I had V 3.11.586 before (without this problem) but I have to install Xamarin.iOS 8.10.4.0.
    So... if I have to downgrade, please provide the links to do that.
    Thanks

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    In any case, it is still under investigation.

    What does this means - what is the current standing...?

    It means that the the bug is still under investigation by the Xamarin QA team and the XamarinVS team. So for example, those teams have not yet ruled out the possibility that there might be a way to work around or solve this problem by changing the behavior of the XamarinVS extensions. The available information so far does not rule out the possibility that the root cause is within Visual Studio itself. Some of the recent XamarinVS fixes (for example to correct some debugging issues) now perform a more "correct" build and clean process than ever before. This more thorough process could simply be hitting a problem in Visual Studio itself that the old "partly incorrect" XamarinVS build process never hit. Reverting XamarinVS to use the old "partly incorrect" behavior would reintroduce other old bugs. So fixing the problem will likely require finding a completely new fix for XamarinVS (if it's possible to fix the problem at all).

    In some initial tests that I tried myself, it seemed that the NuGet Package Manager might be involved in the problem, perhaps holding handles to .dll files open after package updates. Unfortunately, I was not able to reproduce the problem with any consistency in those tests. The QA team also has not yet found any particular technique to hit the problem consistently. The tentative plan will be for the QA team to continue searching for a way to reproduce the problem (potentially aided by screen shares with some particular customers who might be seeing the problem frequently). With a consistent way to reproduce the issue in hand, the XamarinVS team will then have a much better chance of being able to find a "new fix" quickly and efficiently.

  • @BrendanZagaeski

    I am finding the Android dev experience with VS 2015 and Xamarin for VS 3.11.836/837 quite choppy, with frequent IDE lock-ups (I'm talking 10-30 seconds at a time while editing a .cs file - does not occur outside of solutions containing Xamarin projects) and debugger hangs as well as "unable to disconnect debugger" issues. I would like to downgrade to 3.11.666 which, combined with VS 2015 RC, was producing a much smoother experience. Are you able to provide the downgrade links for 666?

    Thanks in advance.

  • opiantsopiants NZMember ✭✭

    @Kirill.Shlenskiy It should be in your My Account page

  • @opiants,

    Thanks a lot for your help; the link was there indeed.

This discussion has been closed.