Repository navigation
System.Security.Principal.Windows missing runtime assembly on Linux #16215
Description
Or incorrectly referenced? Not sure, not directly referenced
It restores fine
Installing System.Security.Principal.Windows.4.0.0-rc2-23722
Then errors in use
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Security.Principal.Windows, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
---> System.IO.FileNotFoundException: Could not load the specified file.
at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyName(AssemblyName assemblyName)
at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)
--- End of inner exception stack trace ---
at System.Net.ContextAwareResult.Cleanup()
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionCallback(Int32 numBytes, SocketError errorCode)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
bash: line 1: 13883 Aborted (core dumped) dnx test
fail: Exit code 134 from /usr/bin/env
fail: Stack trace:
No issues on Windows
Activity
benaadams commentedon Jan 26, 2016
Related? dotnet/corefx#5576
Might need to be picking up rc3 files?
benaadams commentedon Jan 26, 2016
@stephentoub looks like issue you saw in dotnet/corefx#5596 (comment) ?
stephentoub commentedon Jan 26, 2016
Yes, this should be fixed in newer packages.
ericstj commentedon Jan 26, 2016
That's by design. The contract isn't supported on Linux. Also, if you use either NuGet or the latest dotnet CLI you should see a restore error.
The dependency from System.Net on System.Security.Principal.Windows was fixed with dotnet/corefx#5576. You should see that fix in either rc3-23722, or rc2-23726.
davidfowl commentedon Jan 26, 2016
This is going to wreak havoc on upstream packages. Now everyone has to pivot on runtime when they use this dependency.
ericstj commentedon Jan 26, 2016
This is not different than Microsoft.Win32.Registry, System.Security.Cryptography.Cng, System.Net.Http.WinHttpHandler, System.Runtime.WindowsRuntime.UI.Xaml. All of these are Windows-specific technologies. We have similar Unix only packages today just not as many of them (OpenSSL comes to mind).
Perhaps you are suggesting the scenario for using WindowsIdentity is a common one and there should be a good cross-platform API that hides platform specific types. That could be true, though I'd like to hear that from the folks that own the libraries that are using this contract today.
@brentschmaltz does System.Security.Claims have anything like that?
andyleejordan commentedon Jan 26, 2016
@stephentoub This dependency appears to have regressed in 4.0.0-rc3-23726.
ericstj commentedon Jan 26, 2016
@andschwa shared his project file with me and he's using System.IO.FileSystem.AccessControl, Microsoft.Win32.Registry.AccessControl, and System.Security.AccessControl. All of these are Windows-specific.
andyleejordan commentedon Jan 26, 2016
@ericstj With
dotnet-cli's switch to NuGet, I'm going to have to find another way to provide these types for my project.ericstj commentedon Jan 26, 2016
@andschwa it's not just the types. You need to bring down the implementation as well. One proposal on the table is https://github.com/dotnet/cli/issues/465 which would enable applications to cross-compile by OS. Another thing that's been discussed in the past is "optional" dependencies, though I don't think there is a solid proposal for that one.
andyleejordan commentedon Jan 26, 2016
We guard against the use of actual code itself at runtime (shared codebase), so the implementation should never be hit.
glennc commentedon Jan 26, 2016
@davidfowl Doesn't HttpPlatformHandler middleware depend on this? Doesn't this break our ability to move the template apps in VS to Linux or OS X without changes?
lodejard commentedon Jan 26, 2016
@glennc yes, using "implementation missing" at restore time instead of "platform not supported" at run-time means the templates are OS-specific.
ericstj commentedon Feb 4, 2016
That's only if HttpPlatformHandler doesn't build as a fat package. If you were to build this component as a fat package with separate windows and unix implementations, you wouldn't have OS-specific templates.
This is what we do already for all CoreFx packages that need to use platform specific technology.
ericstj commentedon Mar 24, 2016
This was fixed by adding PlatformNotSupported assemblies.