Bug 51565 - UWP: Startup crash with Native tool chain "FileNotFound_AssemblyNotFound, clrcompression"
Summary: UWP: Startup crash with Native tool chain "FileNotFound_AssemblyNotFound, clr...
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.3.3
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2017-01-17 07:32 UTC by georg.haberl
Modified: 2017-02-28 02:12 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Not a .net dll (9.06 KB, image/png)
2017-01-17 08:08 UTC, georg.haberl

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description georg.haberl 2017-01-17 07:32:29 UTC
System.IO.FileNotFoundException occurred
  Message=FileNotFound_AssemblyNotFound, clrcompression

This happens in WindowsPhonePlatformServices.GetAssemblies().
First it gets the filename of the Assemblies in the local folder, then it uses the filename to load those assemblies.
In my case there is a clrcompression.dll in that folder which then fails to load -> the thing there looks like very fragile code, isn't there a better way to load those files instead of using there name without their file extension?
Would be nice to have a way to workaround this (like an overload where we can specify files to ignore or just a less fragile loading of assemblies)
Other people have this Problem as well and I don't know of any workaround, which is a blocker since the App cannot be uploaded to the store. Also I'm pretty sure clrcompression.dll isn't the only problematic dll.

Comment 1 georg.haberl 2017-01-17 08:07:22 UTC
Interestingly when trying to look at the dll with an assembly information tool, it's saying it is not a .net dll and i think it's actually a c++ dll, is this possibly the problem?
Comment 2 georg.haberl 2017-01-17 08:08:29 UTC
Created attachment 19360 [details]
Not a .net dll
Comment 3 georg.haberl 2017-01-17 08:13:50 UTC
If that is the problem, maybe a check like described here http://stackoverflow.com/a/1366517/2071545 might help?
Comment 4 georg.haberl 2017-01-17 08:49:44 UTC
I've tested my app with Microsoft.NETCore.UniversalWindowsPlatform 5.2.2 as well as 5.3.0-beta2 though it still won't work...
Comment 5 georg.haberl 2017-01-18 08:28:44 UTC
I made it work, though I don't know what the problem is.
The Solution was to check out my Solution from the server, then it worked so something with VS 2017 RC must be wrong.
Weird thing is after a couple of builds it now happens again --> So it seems I have to check out again... Do you know whom I should contact about this issue so it can be resolved (like creating a bug report or something)
Comment 6 Samantha Houts [MSFT] 2017-02-15 23:24:57 UTC
@Georg: Thank you for your report and your persistence in finding a solution! I think you may be right about the root of this issue being something with the IDE.

You may want to report a problem in the Developer Portal: https://developercommunity.visualstudio.com/topics/fixed-in%3A+Visual+Studio+2017+RC.html

Warm regards,
Xamarin.Forms Team
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2017-02-28 02:12:22 UTC
I will mark this bug as related to Bug 52838 where by chance I dug into closely related question in a bit more depth.  (Hopefully that will to help consolidate information for other users who might have similar questions in the future.)

One thing that is a little mysterious on this Bug 51565 compared to Bug 52838 is that the exception as reported in Comment 0 sounds like it is an _unhandled_ exception, but the code for `WindowsPhonePlatformServices.GetAssemblies()` catches and ignores all `IOException` sub-classes [1].  That includes `FileNotFoundException` and explains why the steps to replicate on Bug 52838 require setting the debugger to break on all CLR exceptions.  Perhaps there is (or was) indeed some unusual incorrect exception handling behavior in one of the VS 2017 RC versions.

[1] https://github.com/xamarin/Xamarin.Forms/blob/release-2.3.3/Xamarin.Forms.Platform.WinRT/WindowsBasePlatformServices.cs#L52-L71