PlatformNotSupportedException while using ProtectedData.Protect from a library loaded through reflection, on Windows

[sankalan]

Description

We have a library that uses ProtectedData.Protect. If we load this library through reflection, we get PlatformNotSupportedException, on Windows. If we add the reference of ProtectedData directly in the app, that loads the library, things work fine.

Configuration

• Using it in net core 3.1
• Tried in Windows 10, x64

Regression?

• Here is the sample application to reproduce the issue-
  SampleApp.zip

Let me know if you need any other information.

#System.Security.Cryptography.ProtectedData

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

I can reproduce it but I'm not sure what the right solution is. Gist of what I see:

1. ServiceApp has a dependency on S.S.C.ProtectedData via PackageReference.
2. Do a dotnet publish on serviceApp. This publishes the library, and among other things, puts a copy of S.S.C.ProtectedData.dll in the publish directory. This assembly is the lib copy of ProtectedData. This is the one that throws PNSE. The "real" windows one is copied in runtimes\win\lib
3. ConsoleApp loads ServiceApp via reflection.
4. ConsoleApp invokes a method in ServiceApp, that method uses S.S.C.ProtectedData.
5. This causes the non-runtime-specific ProtectedData assembly to get loaded from the publish directory, not the one from runtimes\win.

It seems there are two fixes

1. Add an explicit dependency to System.Security.Cryptography.ProtectedData so the right dependency is loaded.
2. When using dotnet publish on ServiceApp, specify the runtime using dotnet publish --runtime win and adjust the reflection loaded path from serviceApp\bin\Debug\netcoreapp3.1\publish\ServiceApp.dll to serviceApp\bin\Debug\netcoreapp3.1\win\publish\ServiceApp.dll. Note the win in the path. Specifying the RID will cause the published app to include the specific runtime assets for that platform.

[sankalan]

It worked, thanks!
Just curious, why couldn't it refer to the correct dll as per runtime in reflection while it could without reflection?

[vcsjones]

Someone more familiar with how reflection works could probably say, but it's likely because reflection hasn't been taught about runtime paths when probing for assemblies to load. It just finds the first assembly that matches, and in this case it picks the wrong one, the one that is not runtime-specific.

[sankalan]

Oh I get that. Do you think this scenario can be a bug on reflection?

[vcsjones]

Do you think this scenario can be a bug on reflection?

I don't think it is a bug, but perhaps a limitation of how assembly probing works. If you think this behavior could be improved, perhaps a new feature request issue would be useful. I think this behavior can occur with just about any package that has RID-specific assets, not just ProtectedData.

[sankalan]

I get that, it doesn't seem like an issue with ProtectedData. Can you tag someone from the reflection group to have a look into this?

[vcsjones]

/cc @GrabYourPitchforks

[GrabYourPitchforks]

I repathed the area to the VM instead of System.Security because I'm not quite sure where else to bucket this.