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 for Bug 52838 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Create a blank xamarin forms PCL project. Select UWP as startup, select release and build. Use [CTRL + ALT + E] to enable all CLR exceptions. Start the app with F5 and see 2 "Additional information: FileNotFound_AssemblyNotFound, ClrCompression" exceptions showing up. Tested with NetCore 5.0 and 5.2.2 and Forms version 188.8.131.52.
I assume the app should include assemblies as explained in https://developer.xamarin.com/guides/xamarin-forms/platform-features/windows/installation/universal/#troubleshooting or the Default.rd.xml in Properties folder should contain some more information.
IMHO the pure app should not throw any exceptions. The default template should include everything neccessary to build a blank app. Also when adding more references to the project, there should be a way of finding out which assemblies to include (FileNotFoundException in Reflection). Don't know if this needed tweaking of VS, NetCore, the native tool chain or Xamarin.
I'm going to reassign this to VS for now. I don't seem to get that issue in my output so they might better understand what's going on.
OK, VS 2015 Pro Update 3 btw.
## Bookkeeping note
I will assign this bug to myself for a moment for a preliminary non-engineering team review.
Non-engineering team preliminary quick review
## Focuses on one problem?
Mostly, yes. There is a side comment about "when adding more references" that is not the primary focus of the report.
## Suspected to be a regression or a problem with a new feature?
Uncertain. The reporter did not yet specify their current XamarinVS version information (from "Help > About Microsoft Visual Studio") or mention whether the behavior might have changed after a XamarinVS or Xamarin.Forms update.
Of potential interest, there are at least 2 other reports that appear to be discussing approximately the same issue (Bug 51565 and Bug 52482), and the version there was Cycle 8 SR 2 (XamarinVS 184.108.40.206) or earlier.
The forum thread linked on one of those bugs links to a documentation guide that might or might not also be relevant:
## Specific to one particular project, development computer, or target mobile device?
Uncertain. The issue is described as occurring in a template project, but the issue might be specific to a particular development environment since Paul in Comment 1 did not see the issue as described in Comment 0.
## Includes clear steps to reproduce the problem?
n/a at the moment. The report does include steps to reproduce, but it's not yet clear why they behaved differently in Comment 1.
## Already took up time for many users?
Unclear. There are no other users on CC on this bug yet. The other earlier bugs Bug 51565 and Bug 52482 might or might not be quite the same.
## Makes development (a) difficult, impossible, or potentially hazardous, (b) moderately inconvenient, or (c) mildly inconvenient for users?
(b) or (c). It is possible to continue development, but this issue is inconvenient if you wish to have break on all CLR exceptions enabled in the Release configuration (perhaps a bit unusual).
One more quick review question
## Considers the relevant log files and has them attached?
Not yet. For example the report does not yet include the stack trace of the exception.
(See also https://developer.xamarin.com/guides/cross-platform/troubleshooting/questions/howto-file-bug/)
Created attachment 20026 [details]
UWP test case that shows the issue with no Xamarin NuGet packages
Additional independent analysis
## Locally reproducible
I was able to replicate the behavior as described in Comment 0 with the Xamarin.Forms PCL template project that is included in XamarinVS 220.127.116.114 (73f58d6) when I had Visual Studio 2015 Update 3 set to break on all CLR exceptions.
## Stack trace
The issue seems to arise within the call to `WindowsBasePlatformServices.GetAssemblies()`, in the Xamarin.Forms.Platform.UAP assembly .
> [Managed to Native Transition]
> System.Private.Reflection.Core.dll!System.Reflection.Runtime.Assemblies.RuntimeAssembly.GetRuntimeAssembly(Internal.Reflection.Core.ReflectionDomain reflectionDomain, System.Reflection.Runtime.Assemblies.RuntimeAssemblyName assemblyRefName) Line 47 C#
> System.Private.Reflection.Core.dll!System.Reflection.Runtime.General.ReflectionCoreCallbacksImplementation.Load(System.Reflection.AssemblyName refName) Line 45 C#
> System.Private.Reflection.dll!System.Reflection.Assembly.Load(System.Reflection.AssemblyName assemblyRef) Line 114 C#
> Xamarin.Forms.Platform.UAP.dll!Xamarin.Forms.Platform.UWP.WindowsBasePlatformServices.GetAssemblies() Unknown
> Xamarin.Forms.Core.dll!Xamarin.Forms.Registrar.RegisterAll(System.Type attrTypes) Unknown
> Xamarin.Forms.Platform.UAP.dll!Xamarin.Forms.Forms.Init(Windows.ApplicationModel.Activation.IActivatedEventArgs launchActivatedEventArgs, System.Collections.Generic.IEnumerable<System.Reflection.Assembly> rendererAssemblies) Unknown
> FormsPortable1.UWP.exe!FormsPortable1.UWP.App.OnLaunched(Windows.ApplicationModel.Activation.LaunchActivatedEventArgs e) Line 63 C#
> Xamarin.Forms.Core.dll!Xamarin.Forms.TriggerAction.DoInvoke(object sender) Unknown
> FormsPortable1.UWP.McgInterop.dll!McgInterop.ReverseComSharedStubs.Proc_TArg0__<Windows.ApplicationModel.Activation.LaunchActivatedEventArgs>(object __this, void* unsafe_e, System.IntPtr __methodPtr) Line 6533 C#
> FormsPortable1.UWP.McgInterop.dll!Windows.UI.Xaml.IApplicationOverrides__Impl.Vtbl.OnLaunched__STUB(System.IntPtr pComThis, Windows.ApplicationModel.Activation.ILaunchActivatedEventArgs__Impl.Vtbl** unsafe_args) Line 61045 C#
> [Native to Managed Transition]
## "Compile with .NET Native tool chain" _is_ involved
If I disable "Project Properties > Build > Compile with .NET Native tool chain", the exception is no longer thrown during application launch.
## Suggested next steps
I can replicate the same 2 behaviors (depending on the ".NET Native tool chain" setting) with the attached test case that has _no_ involvement of XamarinVS or Xamarin.Forms. It simply copy-pastes the code from `WindowsBasePlatformServices.GetAssemblies()` into a new template UWP app.
So this is definitely _not_ a bug in the Xamarin for Visual Studio _extensions_. I am unsure if this might be a bug in UWP, or an intentional behavior that Xamarin.Forms will need to account for in its implementation of `WindowsBasePlatformServices.GetAssemblies()`. In fact, perhaps Xamarin.Forms is _already_ trying to account for it by catching the IOException and BadImageFormatException types. This is perhaps an intentional shortcut to avoid other ways to attempt to pre-check the .dll files for being valid CIL assemblies.
I am also able to reproduce this issue with a new Forms UWP project when:
- .Net Native tool chain is enabled
- VS is set to break on all CLR exceptions
Since the exception appears to be thrown due to Forms UWP code (based on the info in comment 6), I am confirming this as a Forms issue for now so the engineering team can look into this and provide more information.
Created attachment 20234 [details]
UWP test case showing that .NET Native causes "Just My Code" not to work
Another thought occurred to me. The Xamarin.Forms.Platform.UAP assembly should not be considered "my code"  by the Visual Studio debugger. So that assembly _should_ be allowed to throw and handle exceptions internally _without_ causing the debugger to break, as long as the user has "Tools > Options > General > Enable Just My Code" enabled.
But it turns out that in the Release configuration with "Compile with .NET Native tool chain" enabled, the Just My Code feature does not behave as expected for _any_ UWP app.
In short, I believe this bug can likely be marked as "resolved upstream".
## Steps to demonstrate with the attached test case.
1. Load the BlankUwpApp1 project.
2. Ensure "Debug > Exceptions > Break When Thrown" shows a checkmark (not a filled square) for "Common Language Runtime Exceptions".
3. Ensure "Tools > Options > General > Enable Just My Code" is enabled.
4. Build and debug the project via "Debug > Start Debugging" in the "Release | x86" configuration.
- The debugger breaks on the handled exception in `UwpLibrary1.Class1.Class1()`.
- If you disable "Compile with .NET Native tool chain", the debugger no longer breaks on that exception (in either the Release or the Debug configuration).
I experience the same issue.
Visual Studio Community 2017
Version 15.2 (26430.12)
Xamarin 18.104.22.1686 (1be4f0c)
Let me know if you need further information and/or sample project.