NOTE: Alpha versions have not yet completed the full suite of tests by the Xamarin QA team. That said, customer reports of any regressions (or bugs that are incorrectly marked "fixed") are still much appreciated, even if the problem would have eventually been caught during the full QA testing process.

Previous versions, downgrading

You can downgrade back to the current Stable version by switching updater channels.

You can downgrade back to the previous Stable versions (from before April 29) by manually reinstalling each old package (see also the article about downgrading). The links to the previous Stable versions are:

Guidelines for this thread

Hopefully this thread will help answer "what regressions have been fixed compared to the current Stable version?" and "what might break if I update to this release?"

If you find a new problem that is specific to this version, please file a bug report (if this link redirects to the top-level https://kb.xamarin.com/ page the first time you click it, try clicking it once more).

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

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

Bug 29220 - [XamarinVS] [iOS] [Android] "ERROR: Value cannot be null. Parameter name: project" when opening and building projects. So far, this problem appears to be related to specifics of the system configuration. If anyone happens to notice one particular difference between a working project and a failing project (or a computer without the problem and a computer with the problem), be sure to let us know right away. Partial workaround: uninstall the Test Cloud integration: https://bugzilla.xamarin.com/show_bug.cgi?id=29680#c2.

Bug 29839 - [XamarinVS] [iOS] "Native linking error: warning: directory not found" when linking a static library into an iOS app using ${ProjectDir} in the "Additional mtouch arguments". Workaround: Replace ${ProjectDir} with ${TargetDir}/../../../. See https://bugzilla.xamarin.com/show_bug.cgi?id=29839#c2 for an example.

Bug 29568 - [Android] "No resource found that matches the given name", for AppCompat resources in the Android Support library.

Non-public bug 29866 - [Android] Windows only: "System.InvalidOperationException: Can't not find the nested type" when building with the linker enabled.

Non-public Bug 29172 - [Android] "'...Resource' does not contain a definition for `Id'" (for example, when using the Scandit component).

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

(This list should get smaller as new Alpha builds are published over the coming week.)

Bug 28961 - [iOS] "error MT3001: Could not AOT the assembly", "error: invalid symbol redefinition". (This can also appear as "System.ArgumentOutOfRangeException: startIndex > this.length" in the "Output -> Xamarin Log" in VS.) One common cause of this error is the use of [MethodImplAttribute(MethodImplOptions.Synchronized)]. Workaround for projects that use [MethodImplAttribute(MethodImplOptions.Synchronized)]: remove [MethodImplAttribute(MethodImplOptions.Synchronized)] and manually synchronize the methods using lock statements instead (https://bugzilla.xamarin.com/show_bug.cgi?id=28961#c6).

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.

Bug 29849 - [XamarinVS] [iOS] The "Visual C# -> Mobile Apps -> Blank App (Xamarin.Forms Portable)" template includes an iOS project that has a non-empty value for the <CodesignEntitlements> property for the iPhoneSimulator configurations, meaning that the iPhoneSimulator configuration will attempt to perform code signing. This is inconsistent with the other templates and also with the corresponding Xamarin Studio template on Mac. Workaround: open the .csproj file in a text editor and delete the <CodesignEntitlements> property from all of the iPhoneSimulator configurations.

New known issues compared to 3.11.445

Bug 28027 - [XamarinVS] [iOS] The debugger sometimes fails to connect properly after the app launches. This means breakpoints will not be hit, and pressing the "stop debugging" button will cause VS to pause for about 2 minutes before showing an error message (you can cancel that 2 minute pause if you manually quit the app on device). This problem has existed since at least XamarinVS 3.9.483, but has apparently gotten worse for several users in this new Alpha version. To make a reasonable guess, the problem might be caused by a race condition. Based on that guess, the new Alpha version might have changed some timings and increased the probability of hitting the issue on a wider range of system configurations. The XamarinVS team is investigating.

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 May 07: Add XamarinVS bug 29822 and XamarinVS bug 29703.EDIT May 07: Remove Xamarin.iOS non-public bug 29764 because it is not really a regression.EDIT May 07: Add XamarinVS bug 29839.EDIT May 08: Update version numbers for new Alpha builds. Move more bugs to the "Fixes" section accordingly. (29628 29680 29220 29568 29172 29730 29703)EDIT May 08: Add Android bug 29538. Adjust Android bug 29170 description accordingly.EDIT May 08: Add iOS bug 29745 with workarounds.EDIT May 09: Add Alpha-only Android bug 29866.EDIT May 11: Add XamarinVS.iOS bug 29849 with workaround.EDIT May 13: Add Xamarin.iOS bug 28961.EDIT May 13: Update version numbers for new Alpha builds. Move more bugs to the "Fixes" section accordingly. (29839 29866 29570)EDIT May 13: Add "Xamarin Log" error message for 28961.EDIT May 14: Update version numbers. iTunesMetadata.plist is now removed automatically from App Store builds.EDIT May 15: Mention that XamarinVS.iOS bug 28027 is more common on Alpha.EDIT May 19: Close this Alpha thread and a link to the new Beta thread.

I see from the lists above that Bug 29568 ([Android] "No resource found that matches the given name") isn't fixed yet, and I've also noticed that the 3.11.445 update is having trouble with overriding resources inherited from libraries in general**, not just from AppCompat. Is this part of the same problem, or is there another bug to do with library resource overriding that needs fixing?

Thanks again,
Philip

** If an app has style resources of the same name as those defined in a library (in order to override them) they seem to be ignored. Previous builds work the same as Android Studio in Java land in this respect; it's only the 3.11.445 update that broke library resources.

I have upated to the alpha and notice that it has stopped compiling the asset catalog for my iOS project in visual studio and any assets that are within doesn't get moved into the App bundle and when starting up it causes the App to crash.

Update

I have been browsing the build host build folder and found within the actool build folder I found the asset-manifest.plist and within it had the following error message:

description - Failed to read file attributes for "/Users/steventsang/Library/Caches/Resources/Images.xcassets"
reason - No such file or directory

The folder should of been "/Users/steventsang/Library/Caches/Xamarin/mtbs/builds/"projectname"/"guid"/Resources/Images.xcassets"

Update2

As a workaround I have placed the asset catalog file that contains the images into the directory the actool is looking to compile the asset catalog and seems to be working for now.

I think I have fix the problem by running clean build on VS and deleting the build host folder on the mac and it seems to be working fine now. I will continue to monitor and update if I have any further issues.

I've been using the alpha version whilst doing a couple of XamU classes and Android seems to be working fine. Not pushed it hard, but for a forms class and a 'droid class I've had no issues at all with Android.

There seems to be a regression with iOS that you have to set the bundle and provisioning profile for a simulator build. @BrendanZagaeski - Is there a bug raised already for this? if not, I'll raise one.

If you manually clear the <CodesignEntitlements> property in the .csproj file for the iPhoneSimulator configuration (assuming that element is present in that configuration), are you able to build without setting the bundle and provisioning profile?

@I_am_a_duck, I the fix for Bug 29568 should indeed help with resource references for many libraries, not just the AppCompat library.

The new build just published today (3.11.546) now includes the fix for Bug 29568, so feel free to test that out and verify that it does indeed solve the problem in your projects. Thanks for the report!

@deckertron9000, as it turns out, there is a second bug that is specific to the graphical Xamarin Profiler. If by chance you are using the graphical Xamarin Profiler, then that second bug is most likely the cause of the problem. I have just added that second bug to the list in the first post in the thread to make the status publicly visible:

There's not really any "serious" reason for either the original bug or this second bug. I think the rough explanation is just that they were filed by the QA team, and the QA team files private bugs by default because most of the time those bugs get fixed before they are released. In these particular cases it could have been helpful to keep the bugs public since they did end up in a release. I will discuss with some of the folks here about how bugs are marked and sorted during releases. So hopefully user-facing regressions will become a bit easier to track in the near future.

@BrendanZagaeski Sorry - had a busy weekend, will try tonight. It was on a brand new project created in XS - so whilst I agree that not letting it be set for the simulator is a good thing the projects defaults should make sure it's blanked out. Is there a bug raised already for this, or shall I raise one?

@BrendanZagaeski Thanks, I was indeed using the graphical profiler. It's nice to have some insight on the way bugs are handled. I agree that in some cases it would be useful to have more transparency on some of these bugs, but I understand the usefulness of not having every bug public facing all the time, especially if it's going to be fixed in the next release.

Thanks as well for your activity in the forums. It's nice to be able to interface with the Xamarin team like this and know that our issues are being addressed.

Bug 29849 indicates that the problem is specific to Xamarin.iOS projects within the Xamarin.Forms templates. If you've noticed it in any of the other templates, that would indeed make an excellent additional bug report.

@BCT, May 20th is the tentative Stable Channel release date for the service release that is currently in Alpha. That date might need to be pushed later to allow more time for fixes if QA determines that the release candidates for the service release contain one or more bugs that are worse than the regressions in the current Stable Channel.

It seems the most common cause of failed breakpoints on the new Alpha versions is a different problem than the issue on the Stable Channel where XamarinVS was failing to copy .mdb files for PCL projects.

The new problem seems to be that Bug 28027 has become more common on the Alpha channel. The issue is under investigation. I have updated the first post in the thread with a few additional details.

For those running into breakpoints not being hit issues, one thing that helped me was to Delete the .vs folder, .sln.ide folder, manually clear out the bin and obj folders for each project and delete all the .user files. Hope this helps someone.

The fix for Bug 29568 did indeed resolve my library resource override issue. However, I have found another apparent regression in all builds of 3.11 I've tried (445/6, 558 and 570). The simplest example code I have is:

The above works in 3.9 as expected: Class.FromType() returns a Java.Lang.Class instance which AddParentStack() happily accepts.

However, in all 3.11 builds, the call to AddParentStack() throws an exception:android.content.pm.PackageManager$NameNotFoundException: ComponentInfo{...

The activity in question is correctly defined in the app manifest (otherwise the above wouldn't work in 3.9 either), so this is definitely a change of behaviour introduced in 3.11.

Interestingly, the Java.Lang.Class returned by Class.FromType() in 3.9 has a clear text namespace prefix in its name property, e.g. Name: "example.app.namespace.ExampleClass" as viewed in the debugger, but in 3.11 it has a mangled namespace prefix, e.g. Name: "md5e6e383b03eea42faa32711371720f95e.ExampleClass".

Is this perhaps a new feature of 3.11 that I've missed? Sorry if this is a known issue but I couldn't find any reference to this error in Bugzilla.

And that sample runs correctly for me on Xamarin.Android 5.1.2 (and XamarinVS 3.11.570).

Next steps

Since the "Notifications" sample behaves correctly, the question becomes "what is unique about your app compared to that sample?"

Perhaps the mActivityType in your app is from a Xamarin.Android library project that was built against an older version of Xamarin.Android? I haven't had a chance to try that scenario specifically, so there's a chance something behaves unexpectedly in that case.

Maybe the mActivityType in your app is a native Java class that is bound to C# using a Xamarin.Android Java binding project? I haven't had a chance to try that either.

Maybe the exact classes and names in your app expose a bug in the new name mangling scheme that is unrelated to #1 or #2.

If you get a chance, the most direct way forward would probably be to zip up and attach a self-contained, minimal test case that demonstrates the problem on a new bug report. See the bug filing KB article for some additional hints and tips about filing a bug report and minimizing the test case. (If the link to the KB article redirects to the top-level kb.xamarin.com/ page the first time you click it, try clicking it once more.) You can paste a link to the bug report back in this thread once it's ready. Thanks!