ArgumentException on UWP component in ASP.NET, but not in console .NET - asp.net

Question

I'm trying to consume an UWP component in an ASP.NET page. The minimal code goes:
public partial class _default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
Try();
}
private void Try()
{
Debug.WriteLine("Before");
Windows.Foundation.Collections.StringMap sm = new Windows.Foundation.Collections.StringMap();
Debug.WriteLine("After");
}
}
In order to make this compile, you need to add the following line to the project file:
<TargetPlatformVersion>10.0</TargetPlatformVersion>
and add a reference to Windows.Foundation from the "Universal Windows" category. The yellow error screen goes:
The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))
and it shows the last line of Try() as the error location, but that's misleading; the error is thrown in the JIT compiler when the framework tries to compile the method Try(). Same error with any other UWP class, I've tried several.
This fails both under IIS Express and IIS proper. The same code works as expected in a console .NET application.
What is the difference of execution environment under desktop/console and under ASP.NET? Not the current user; in IIS Express scenario, the current user is me. Not the apartment's threading model; I've tried it on an STA thread and on an MTA thread.
EDIT: it's a bug at VS Connect now. If you're affected, go over there and click "I can too".

Answer 1

The error has to do with ASP.NET's AppDomain assembly share policy, which roughly corresponds to the LoaderOptimization parameter of AppDomainSetup. If the UWP consuming code is executed in an AppDomain where LoaderOptimization is set to SingleDomain (default for desktop apps), it works. ASP.NET hard-codes this setting to MultiDomainHost. It's probably a CLR bug on some level.
I've found no good, legal way to change the setting for the ASP.NET's sandbox appdomains, but you can create a new appdomain, with all the same parameters as the sandbox except for the LoaderOptimization:
AppDomain CreateUnsharingDomain()
{
AppDomain cad = AppDomain.CurrentDomain;
AppDomainSetup cads = cad.SetupInformation;
return AppDomain.CreateDomain("Dummy", cad.Evidence,
new AppDomainSetup
{
ApplicationName = cads.ApplicationName,
ApplicationBase = cads.ApplicationBase,
DynamicBase = cads.DynamicBase,
CachePath = cads.CachePath,
PrivateBinPath = cads.PrivateBinPath,
ShadowCopyDirectories = cads.ShadowCopyDirectories,
ShadowCopyFiles = cads.ShadowCopyFiles,
ApplicationTrust = cads.ApplicationTrust,
LoaderOptimization = LoaderOptimization.SingleDomain
});
//Not sure which other properties to copy...
}
CreateUnsharingDomain().DoCallBack(() =>
{
Debug.WriteLine("Before");
Windows.Foundation.Collections.StringMap sm = new Windows.Foundation.Collections.StringMap();
Debug.WriteLine("After");
});
This works. I'm still not entirely satisfied with the answer. It's rather verbose, and passing calls and objects across AppDomain boundaries is a chore. I'm investigating whether you can set this in a config file.
EDIT: probably impossible. ASP.NET doesn't explicitly specify the LoaderOptimization on its AppDomains. Instead, when the domain level assembly sharing policy is queried, the framework falls back to the the per-process sharing policy, which is initialized on CLR process startup, based on the value of the LoaderOptimization attribute on the process' Main function. Since that one's deep within ASP.NET's code, there's no way to alter the global policy.
Sharing can be, in theory, disabled on per-assembly basis, but for WinRT ones, the assemblies in Windows.* namespace are all considered shareable, with no hook in sight to override that.
Speaking of illegal ways to change the LoaderOptimization on an AppDomain, there's private method SetupLoaderOptimization(LoaderOptimization policy) in the AppDomain class. You can call it via reflection, with all the usual caveats:
AppDomain ad = AppDomain.CurrentDomain;
MethodInfo mi = ad.GetType().GetMethod("SetupLoaderOptimization", BindingFlags.Instance | BindingFlags.NonPublic);
mi.Invoke(ad, new object[] { LoaderOptimization.SingleDomain });
//And for the win:
Windows.Foundation.Collections.StringMap sm = new Windows.Foundation.Collections.StringMap();
This worked for me, too. You decide which approach is less problematic. The latter has less lines, the former doesn't rely on undocumented private methods.
Hairy details below, proceed at your own risk.
Debugging IISExpress with the native debugger shows a C++ exception being thrown at the following stack:
KernelBase.dll!_RaiseException#16() Unknown
msvcr120_clr0400.dll!__CxxThrowException#8() Unknown
clr.dll!DomainFile::ExInfo::Throw(void) Unknown
clr.dll!DomainFile::EnsureLoadLevel(enum FileLoadLevel) Unknown
clr.dll!AppDomain::LoadDomainAssemblyInternal(class AssemblySpec *,class PEAssembly *,enum FileLoadLevel,struct AssemblyLoadSecurity *) Unknown
clr.dll!AppDomain::LoadDomainAssembly(class AssemblySpec *,class PEAssembly *,enum FileLoadLevel,struct AssemblyLoadSecurity *) Unknown
clr.dll!CLRPrivTypeCacheWinRT::ContainsType(struct ICLRPrivAssembly *,unsigned short const *) Unknown
clr.dll!CLRPrivBinderWinRT::BindWinRTAssemblyByName(struct IAssemblyName *,class CLRPrivAssemblyWinRT * *,int) Unknown
clr.dll!CLRPrivBinderWinRT::BindWinRTAssemblyByName(struct IAssemblyName *,struct ICLRPrivAssembly * *,int) Unknown
clr.dll!CLRPrivBinderWinRT::BindAssemblyByName(struct IAssemblyName *,struct ICLRPrivAssembly * *) Unknown
clr.dll!AppDomain::BindAssemblySpecForHostedBinder(class AssemblySpec *,struct IAssemblyName *,struct ICLRPrivBinder *,class PEAssembly * *) Unknown
clr.dll!AppDomain::BindAssemblySpec(class AssemblySpec *,int,int,enum StackCrawlMark *,struct AssemblyLoadSecurity *,int) Unknown
clr.dll!PEFile::LoadAssembly(unsigned int,struct IMDInternalImport *,char const *,char const *) Unknown
clr.dll!Module::LoadAssembly(class AppDomain *,unsigned int,char const *,char const *) Unknown
clr.dll!Assembly::FindModuleByTypeRef(class Module *,unsigned int,enum Loader::LoadFlag,int *) Unknown
clr.dll!ClassLoader::LoadTypeDefOrRefThrowing(class Module *,unsigned int,enum ClassLoader::NotFoundAction,enum ClassLoader::PermitUninstantiatedFlag,unsigned int,enum ClassLoadLevel) Unknown
clr.dll!MemberLoader::GetDescFromMemberRef(class Module *,unsigned int,class MethodDesc * *,class FieldDesc * *,class SigTypeContext const *,int,class TypeHandle *,int,unsigned char const * *,unsigned long *) Unknown
clr.dll!CEEInfo::resolveToken(struct CORINFO_RESOLVED_TOKEN *) Unknown
clrjit.dll!Compiler::impResolveToken(unsigned char const *,struct CORINFO_RESOLVED_TOKEN *,enum CorInfoTokenKind) Unknown
clrjit.dll!Compiler::impImportBlockCode(struct BasicBlock *) Unknown
clrjit.dll!Compiler::impImportBlock(struct BasicBlock *) Unknown
clrjit.dll!Compiler::impImport(struct BasicBlock *) Unknown
clrjit.dll!Compiler::compCompile(void * *,unsigned long *,unsigned int) Unknown
So there's a problem with loading the UWP library into the app domain as an assembly... Some difference in AppDomain settings? I've tried in a freshly created AppDomain, same result.
EDIT: I did enable logging, the message was rather inconclusive:
The operation was successful.
Bind result: hr = 0x1. Incorrect function.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\Program Files (x86)\IIS Express\iisexpress.exe
--- A detailed error log follows.
BEGIN : Native image bind.
END : Incorrect function. (Exception from HRESULT: 0x00000001 (S_FALSE))
Probably related: Why am I unable to do an Assembly.Load of WinMD files?
EDIT2: the call stack above comes on second attempt to use the UWP class. The first attempt shows a different call stack; it could be that CLR caches the "can't load" status and reuses it. Here goes:
KernelBase.dll!_RaiseException#16() Unknown
msvcr120_clr0400.dll!__CxxThrowException#8() Unknown
clr.dll!ThrowHR(long) Unknown
clr.dll!DomainCanShareAptcaAssembly(class DomainAssembly *) Unknown
clr.dll!DomainAssembly::ShouldLoadDomainNeutralHelper(void) Unknown
clr.dll!DomainAssembly::ShouldLoadDomainNeutral(void) Unknown
clr.dll!DomainAssembly::Allocate(void) Unknown
clr.dll!DomainFile::DoIncrementalLoad(enum FileLoadLevel) Unknown
clr.dll!AppDomain::TryIncrementalLoad(class DomainFile *,enum FileLoadLevel,class Wrapper<class FileLoadLock *,&DoNothing<class FileLoadLock *>(class FileLoadLock *),&FileLoadLock::HolderLeave(class FileLoadLock *),0,&CompareDefault<class FileLoadLock *>(class FileLoadLock *,class FileLoadLock *),2,1> &) Unknown
clr.dll!AppDomain::LoadDomainFile(class FileLoadLock *,enum FileLoadLevel) Unknown
clr.dll!AppDomain::LoadDomainAssemblyInternal(class AssemblySpec *,class PEAssembly *,enum FileLoadLevel,struct AssemblyLoadSecurity *) Unknown
clr.dll!AppDomain::LoadDomainAssembly(class AssemblySpec *,class PEAssembly *,enum FileLoadLevel,struct AssemblyLoadSecurity *) Unknown
clr.dll!CLRPrivTypeCacheWinRT::ContainsType(struct ICLRPrivAssembly *,unsigned short const *) Unknown
clr.dll!CLRPrivBinderWinRT::BindWinRTAssemblyByName(struct IAssemblyName *,class CLRPrivAssemblyWinRT * *,int) Unknown
clr.dll!CLRPrivBinderWinRT::BindWinRTAssemblyByName(struct IAssemblyName *,struct ICLRPrivAssembly * *,int) Unknown
clr.dll!CLRPrivBinderWinRT::BindAssemblyByName(struct IAssemblyName *,struct ICLRPrivAssembly * *) Unknown
clr.dll!AppDomain::BindAssemblySpecForHostedBinder(class AssemblySpec *,struct IAssemblyName *,struct ICLRPrivBinder *,class PEAssembly * *) Unknown
clr.dll!AppDomain::BindAssemblySpec(class AssemblySpec *,int,int,enum StackCrawlMark *,struct AssemblyLoadSecurity *,int) Unknown
clr.dll!PEFile::LoadAssembly(unsigned int,struct IMDInternalImport *,char const *,char const *) Unknown
clr.dll!Module::LoadAssembly(class AppDomain *,unsigned int,char const *,char const *) Unknown
clr.dll!Assembly::FindModuleByTypeRef(class Module *,unsigned int,enum Loader::LoadFlag,int *) Unknown
clr.dll!ClassLoader::LoadTypeDefOrRefThrowing(class Module *,unsigned int,enum ClassLoader::NotFoundAction,enum ClassLoader::PermitUninstantiatedFlag,unsigned int,enum ClassLoadLevel) Unknown
clr.dll!MemberLoader::GetDescFromMemberRef(class Module *,unsigned int,class MethodDesc * *,class FieldDesc * *,class SigTypeContext const *,int,class TypeHandle *,int,unsigned char const * *,unsigned long *) Unknown
clr.dll!CEEInfo::resolveToken(struct CORINFO_RESOLVED_TOKEN *) Unknown
clrjit.dll!Compiler::impResolveToken(unsigned char const *,struct CORINFO_RESOLVED_TOKEN *,enum CorInfoTokenKind) Unknown
clrjit.dll!Compiler::impImportBlockCode(struct BasicBlock *) Unknown
clrjit.dll!Compiler::impImportBlock(struct BasicBlock *) Unknown
clrjit.dll!Compiler::impImport(struct BasicBlock *) Unknown
clrjit.dll!Compiler::compCompile(void * *,unsigned long *,unsigned int) Unknown
APTCA stands for "AllowPartiallyTrustedCallersAttribute". However, running under full trust (via system.web/fullTrustAssemblies) doesn't help at all.
At the time of the exception, the Modules window in the native debugger shows Windows.Foundation.winmd as loaded. So it's not an artifact of file not being found somehow.
EDIT: this definitely has to do with the fact that under ASP.NET, code is run as partially trusted, in a sandboxed AppDomain. In a non-sandbox AppDomain, this logic won't be even called. The error is not a security violation though, or the message would've probably been different.
EDIT: tracked it down to a source location. In aptca.cpp, in DomainCanShareAptcaAssembly(), there's a line:
IfFailThrow(pDomainAssembly->GetAppDomain()->GetFusionContext()->GetAssemblyBindingClosure(pFusionAssembly, pNIPath, &pClosure));
which fails and throws, because the pFusionAssembly argument is null. The argument is null, because the local variable pFusionAssembly is null. The local variable is initialized in the line
pFusionAssembly = pDomainAssembly->GetFile()->GetIHostAssembly();
which is null, because the pDomainAssembly object is created in the AppDomain::BindHostedPrivAssembly() (in appdomain.cpp) via the PEAssembly:Open() call with 5 args, which passes a hard-coded nullptr in the pHostAssembly parameter. That's probably a subtle bug in CLR, but a workaround is entirely possible - the very call to DomainCanShareAptcaAssembly() can be shorted out.
The code path that leads to DomainCanShareAptcaAssembly() is taken only if the assembly loading logic tries to share an assembly between app domains. In ASP.NET, that's case. The difference in codepaths begins with the AppDomain::ApplySharePolicyFlag() function which calls GetSharePolicy(); in the ASP.NET environment, the latter returns 3 (SHARE_POLICY_GAC), while in the console project it returns 1 (SHARE_POLICY_NEVER). The share policy is driven by the LoaderOptimization parameter of AppDomainSetup. As long as the domain runs at SingleDomain, the sharing logic is shorted out and UWP works.