Could not load assembly 'System.Security.Permissions' during startup registration.

[MagicAndre1981]

Steps to Reproduce

1. create Xamarin.Forms app with VS2017 (that uses Asp.Net Core SignalR)
2. try do debug the Android app

Expected Behavior

app starts fine and can be debugged.

Actual Behavior

App crashes at startup and in Output/Debug I see the following:

[08-17 08:09:21.513 D/Mono    (17682): Assembly Loader probing location: 'System.Security.Permissions'.
08-17 08:09:21.513 F/monodroid-assembly(17682): Could not load assembly 'System.Security.Permissions' during startup registration.
08-17 08:09:21.513 F/monodroid-assembly(17682): This might be due to an invalid debug installation.
08-17 08:09:21.513 F/monodroid-assembly(17682): A common cause is to 'adb install' the app directly instead of doing from the IDE.

Version Information

Microsoft Visual Studio Enterprise 2017 
Version 15.8.0
VisualStudio.15.Release/15.8.0+28010.0
Microsoft .NET Framework
Version 4.7.03062

Xamarin   4.11.0.732 (d15-8@33e83e124)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   4.14.218 (79f535bdd)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Live Reload   0.4.0 (remotes/origin/dev@75526a0)
Provides live reload capabilities for Xamarin XAML.

Xamarin Templates   1.1.113 (e1d02a7)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK   9.0.0.18 (HEAD/3d8a28f1a)
Xamarin.Android Reference Assemblies and MSBuild support.

Xamarin.iOS and Xamarin.Mac SDK   11.14.0.13 (373c313)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

I also played with settings for Mono Shared Runtime/Linking/apk per ABi, installed OpenJDK, but nothing helps.

The strange thing is that I was able to build/launch the app in the 15.8 preview 5 without any issues and now in the 15.8 stable I have the issues again like in 15.7.x.

[MagicAndre1981]

here output from 15.8 Preview 5 debug window where it works fine:

09:48:33.847 D/Mono    ( 7224): Assembly Loader probing location: '/storage/emulated/0/Android/data/com.foo.bar/files/.__override__/System.Security.Permissions.dll'.
08-17 09:48:33.848 D/Mono    ( 7224): Image addref System.Security.Permissions[0xa94d6ec0] -> /storage/emulated/0/Android/data/com.foo.bar/files/.__override__/System.Security.Permissions.dll[0xa902e000]: 2
08-17 09:48:33.848 D/Mono    ( 7224): Prepared to set up assembly 'System.Security.Permissions' (/storage/emulated/0/Android/data/com.foo.bar/files/.__override__/System.Security.Permissions.dll)
08-17 09:48:33.848 D/Mono    ( 7224): Assembly System.Security.Permissions[0xa94d6ec0] added to domain RootDomain, ref_count=1

Microsoft Visual Studio Enterprise 2017 Preview
Version 15.8.0 Preview 5.0
VisualStudio.15.Preview/15.8.0-pre.5.0+27924.0
Microsoft .NET Framework
Version 4.7.03062

Installed Version: Enterprise

Xamarin   4.11.0.731 (d15-8@1b61b3b4e)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   4.14.218 (79f535bdd)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates   1.1.104 (12ebed1)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK   9.0.0.17 (HEAD/dfb09269d)
Xamarin.Android Reference Assemblies and MSBuild support.

Xamarin.iOS and Xamarin.Mac SDK   11.14.0.11 (61d20a8)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

[JonDouglas]

@MagicAndre1981

Can you please provide a reproduction project as outlined in the bug report wiki? Having a project that we can run will help reduce the potential back and forth to reproduce this issue. We will want to find an isolated case in which might have a specific version of SignalR that causes this issue. If you can provide that for us, it will help us look into this issue!

Thanks for filing an issue and we look forward to hearing from you soon!

[MagicAndre1981]

I took a look at the build output and see that the Preview5 uses the DLL from lib

Copying file from "C:\Users\Andre\.nuget\packages\system.security.permissions\4.5.0\lib\netstandard2.0\System.Security.Permissions.dll" to "C:\foo\Android\obj\AnyCPU\MonoAndroid81\linksrc\System.Security.Permissions.dll".

while the RTM picks the ref one:

Copying file from "C:\Users\Andre\.nuget\packages\system.security.permissions\4.5.0\ref\netstandard2.0\System.Security.Permissions.dll" to "C:\foo\Android\obj\AnyCPU\MonoAndroid81\linksrc\System.Security.Permissions.dll".

At end of Build in the RTM I see the XA0107 warning

The Xamarin.Android build will emit a XA0107 warning if it is using a "Reference Assembly" during the build, where it shouldn't be.

C:\Users\Andre\.nuget\packages\system.security.permissions\4.5.0\ref\netstandard2.0\System.Security.Permissions.dll : warning XA0107: Ignoring C:\Users\Andre\.nuget\packages\system.security.permissions\4.5.0\ref\netstandard2.0\System.Security.Permissions.dll as it is a Reference Assembly.

Why does Preview5 uses correct dll and RTM the ref one?

[MagicAndre1981]

this looks like a known issue:

Xamarin.Android packaging (and resource extraction) steps appear to be picking up the reference assemblies instead of the implementation assemblies.

An user said that switching back to packages.config works for him. I'll try this now.

[MagicAndre1981]

An user said that switching back to packages.config works for him

this also works for me. Now I can build, deploy and debug the app in 15.8.1 production and can ditch the 15.8 Preview VM.

@JonDouglas

Xamarin.Android tools should notify the users to use old packages.config until this issue is solved.

[pikausp]

Any update to this problem? I believe the same issue is also tracked here dotnet/msbuild#2776

[MagicAndre1981]

@pikausp

After switching to package.config I have no issues and haven't tried it again. I want to wait for VS2019 before trying it again.

[pikausp]

@MagicAndre1981 that's what I been doing for the past year and a half. I'm just surprised 1) so few people seem to run into this issue 2) it's still around

[MagicAndre1981]

@pikausp

This is indeed very confusing why some users have it and others not. I only had this in the release version, but in Preview it worked.

🤔 🤷‍♂️

[bgavrilMS]

Is there an update on this issue? Microsoft.Identity.Client started shipping ref assemblies and customers are beginning to encounter this issue.

[MagicAndre1981]

@bgavrilMS use old packages.config to install nuget packages, this fixes it for me

[bgavrilMS]

Thanks @MagicAndre1981 - this is a good workaround, but not an actual fix.

Visual Studio and NuGet are trying to move away from package.config, so we cannot tell our customers to use packages.config as a permanent solution.

[MagicAndre1981]

as you can see, we haven't heard anything from Microsoft. I'll try it with 2019 Rc again until this I use the old working way and not the NOT working but maybe cool way.

[bugail]

We've started to see this issue using the latest version of Microsoft.Identity.Client (2.7.0) in our Xamarin android app when building remotely, everything seems fine when building locally. Are there updates on this?

[MagicAndre1981]

@bugail use old packages.config to workaround the issue until we have a proper fix

[bugail]

@MagicAndre1981 Thanks for the workaround, unfortunately we're unable to use it as this creates another issue in the project we're working on (see https://github.com/aritchie/userdialogs/issues/550 for example). We're also able to build correctly using Visual Studio 2017, our issue occurs when using a hosted/local build agent or using MSBuild locally.

[bgavrilMS]

@baulig - you could use a non-Hosted VSTS agent until VSTS updates their hosted images. They should do it by end of month, but are having problems with image size.

[MagicAndre1981]

@bugail I also use the Acr.UserDialogs package and the old packages.config and it works fine 🤔 🤷‍♂️

[MagicAndre1981]

@bugail I tested it in VS2019 Preview 2 and here it works for me with PackageReference. But with 15.8 Preview it also worked for me, but not in the stable. So I have no idea if the Xamarin.Android tools in VS2019 have it fixed or not 🤔 🤷‍♂️

[MagicAndre1981]

@pikausp

have you tried the 2019 RC? I only tested it in preview, but with 15.x the previews also worked but not the release versions.

[pikausp]

@MagicAndre1981 No, I haven't. I tried ~Preview 2 with no success. I will try it again once we have the official release in April.

[MagicAndre1981]

@pikausp

this is again wired. Like in 15.8 preview it also works for me in 2019 Preview. I'll also test it with RTM of 2019 again

[MagicAndre1981]

@pikausp

have you tried the 2019 GA version? For me it works, but I'm worried about VS2019 UI, so that I stay at VS2017 but here I now run into this new issue with System.Threading.Tasks.Extensions for the Android app if I use Package Reference. VS complains I need to add this lib as SignalR requires it, but I already have it referenced 😡

So I need to stay at VS2017 and the old packages.config, but here I sometimes get Xamarin.Forms targets have been imported multiple times. But this only happens sometimes, not always 🤔 🤷‍♂️

[pikausp]

@MagicAndre1981 I will try it once the project I'm working on currently is finished (end of April). Will post any updates

[MagicAndre1981]

@pikausp

have you ever tried it with VS2019? Does PackageReference Include now works?

[pikausp]

@MagicAndre1981 I have migrated to PackageReference when I replaced Castle with TinyIoC

[MagicAndre1981]

and everything works now (with VS2019)? @pikausp

[pikausp]

@MagicAndre1981 sorry, thought I have replied to this. It does, but TinyIoC doesn't have the dependencies that Castle has, so I don't think it's related. It worked even back when PackageReference didn't work with Castle installed.

[MagicAndre1981]

ok, so it still doesn't work all time. I gave it up and will stay for always at packages.config.

It worked even back when PackageReference didn't work with Castle installed.

[ghost]

We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

[MagicAndre1981]

I've no longer seen this in VS2019/VS2022, so yes, this can be closed