Need way to exclude specified assemblies from automatic loading via the dependency file and not bypass AssemblyResolve

[rkeithhill]

We have a library we provide to internal partners that contains sensitive code that we don't want to be hijacked at runtime. So we require our partners to embed this assembly as a manifest resource and use AssemblyResolve at runtime to extract the assembly from the embedded resource and load it as a byte stream like below. Note: AssemblyResolve works in both new .NET and old .NET Framework.

private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
    string assemblyName = "Acme.Foo.Bar";

    // Do not resolve any other assemblies
    if (!args.Name.StartsWith($"{assemblyName},"))
    {
        return null;
    }

    // Look through the manifest resource names for the assembly name
    string apiAssemblyResourceName = null;
    Assembly manifestHostAssembly = Assembly.GetExecutingAssembly();
    foreach (string resourceName in manifestHostAssembly.GetManifestResourceNames())
    {
        if (resourceName.EndsWith($"{assemblyName}.dll"))
        {
            apiAssemblyResourceName = resourceName;
            break;
        }
    }

    if (apiAssemblyResourceName == null) throw new DllNotFoundException(assemblyName);

    Assembly loadedAssembly = null;
    using (Stream streamApiAssembly = manifestHostAssembly.GetManifestResourceStream(apiAssemblyResourceName))
    {
        // Given that the resource name was returned by reflection, the streamApiAssembly should rarely be null
        if (streamApiAssembly == null) throw new DllNotFoundException(assemblyName);

#if NETCOREAPP
        loadedAssembly = AssemblyLoadContext.Default.LoadFromStream(streamApiAssembly);
#else
        byte[] assemblyBytes = new byte[streamApiAssembly.Length];
        streamApiAssembly.Read(assemblyBytes, 0, assemblyBytes.Length);
        loadedAssembly = Assembly.Load(assemblyBytes);
#endif
    }

    return loadedAssembly;
}

This works great if you remove the generated .deps.json file which isn't a problem for our sample console apps. However, as partners are building more complicated WPF apps, they need to leave the .deps.json file in-place. This causes the app to fail because something is trying to load the assembly, which is embedded in the app dll and NOT on the filesystem. That load attempt fails before the app ever hits the AssemblyResolve event, preventing the app from starting.

Our current hack is to use a bit of PowerShell to remove the assembly from the libraries section of the .deps.json file:

function Remove-LibFromDependencyFile([string]$Path) {
    $jsonDepth = 10
    $depsJson = Get-Content $Path | ConvertFrom-Json -Depth $jsonDepth
    $updatedDepsJson = $depsJson | ForEach-Object {
        $jsonObj = $_
        $name = $_.libraries.psobject.Members | Where-Object Name -match "^Acme\.Foo\.Bar\/" | ForEach-Object Name
        $jsonObj.Libraries.psobject.Members.Remove($name)
        $jsonObj
    }
    $updatedDepsJson | ConvertTo-Json -Depth $jsonDepth | Out-File $Path -Encoding ascii
}

Is there a better way to accomplish this goal of having the .NET runtime NOT try to preload a specified assembly and let my app do the assembly resolution? Or maybe there's a way to keep the assembly out of the .deps.json file which would prevent said mechanism from trying to "pre-load" the assembly?

Somewhat related: Fody/Costura#282

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We have a library we provide to internal partners that contains sensitive code and code we don't want to be hijacked at runtime. So we require our partners to embed this assembly as a manifest resource and use AssemblyResolve at runtime to extract the assembly from the embedded resource and load it as a byte stream like below. Note: AssemblyResolve works in both new .NET and old .NET Framework.

private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
    string assemblyName = "Acme.Foo.Bar";

    // Do not resolve any other assemblies
    if (!args.Name.StartsWith($"{assemblyName},"))
    {
        return null;
    }

    // Look through the manifest resource names for the assembly name
    string apiAssemblyResourceName = null;
    Assembly manifestHostAssembly = Assembly.GetExecutingAssembly();
    foreach (string resourceName in manifestHostAssembly.GetManifestResourceNames())
    {
        if (resourceName.EndsWith($"{assemblyName}.dll"))
        {
            apiAssemblyResourceName = resourceName;
            break;
        }
    }

    if (apiAssemblyResourceName == null) throw new DllNotFoundException(assemblyName);

    Assembly loadedAssembly = null;
    using (Stream streamApiAssembly = manifestHostAssembly.GetManifestResourceStream(apiAssemblyResourceName))
    {
        // Given that the resource name was returned by reflection, the streamApiAssembly should rarely be null
        if (streamApiAssembly == null) throw new DllNotFoundException(assemblyName);

#if NETCOREAPP
        loadedAssembly = AssemblyLoadContext.Default.LoadFromStream(streamApiAssembly);
#else
        byte[] assemblyBytes = new byte[streamApiAssembly.Length];
        streamApiAssembly.Read(assemblyBytes, 0, assemblyBytes.Length);
        loadedAssembly = Assembly.Load(assemblyBytes);
#endif
    }

    return loadedAssembly;
}

This works great if you remove the generated .deps.json file which isn't a problem for our sample console apps. However, as partners are building more complicated WPF apps, they need to leave the .deps.json file in-place. This causes the app to fail because something is trying to load the assembly, which is embedded in the app dll and NOT on the filesystem. That load attempt fails before the app ever hits the AssemblyResolve event, preventing the app from starting.

Our current hack is to use a bit of PowerShell to remove the assembly from the libraries section of the .deps.json file:

function Remove-LibFromDependencyFile([string]$Path) {
    $jsonDepth = 10
    $depsJson = Get-Content $Path | ConvertFrom-Json -Depth $jsonDepth
    $updatedDepsJson = $depsJson | ForEach-Object {
        $jsonObj = $_
        $name = $_.libraries.psobject.Members | Where-Object Name -match "^Acme\.Foo\.Bar\/" | ForEach-Object Name
        $jsonObj.Libraries.psobject.Members.Remove($name)
        $jsonObj
    }
    $updatedDepsJson | ConvertTo-Json -Depth $jsonDepth | Out-File $Path -Encoding ascii
}

Is there a better way to accomplish this goal of having the .NET runtime NOT try to preload a specified assembly and let my app do the assembly resolution? Or maybe there's a way to keep the assembly out of the .deps.json file which would prevent said mechanism from trying to "pre-load" the assembly?

Somewhat related: Fody/Costura#282

Author:	rkeithhill
Assignees:	-
Labels:	area-AssemblyLoader-coreclr
Milestone:	-

[teo-tsirpanis]

We have a library […] that contains sensitive code that we don't want to be hijacked at runtime. So we require our partners to embed this assembly as a manifest resource.

Taking a step back, it seems to me that the assumption that this scheme would provide any more sense of security is wrong. And I didnt't understand what "hijacked at runtime" exactly means. An embedded resource is as easily modifiable as an ordinary file.

[agocke]

The managed assembly loading algorithm is documented here: https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/loading-managed#algorithm

If you want to provide a mechanism for loading at any given point, that document should help you find where.

[rkeithhill]

@teo-tsirpanis

I didn't understand what "hijacked at runtime" exactly means.

It means that we don't want someone to round-trip one of our assemblies via ildasm/ilasm to change the line that returns true or false for "enable this $10K feature" if the user has purchased the corresponding license, to always return true. And then replace the original assembly with the modified one. Putting the assembly in as an embedded resource is admittedly just a "speed bump".

This is one of the main reasons our company has been dumping C# development and moving to C++. The decision-makers believe it is harder for compiled C++ software to be hacked in this manner and that C++ is more portable. On the latter point, I disagree. C may be more portable but C++ - not as much

[agocke]

@rkeithhill If you are interested in deploying assets compiled to native binaries, Native AOT might interest you.

One thing I don't understand from your description -- it sounds like the problem is that the Load of your assembly is being completed successfully from disk, which is why the resolve event never fires. If you're bundling the assembly as an embedded resource, how is the disk-load event being resolved successfully?

[rkeithhill]

@agocke The NuGet package we provide for our library supplies a .targets file that does the assembly embedding AND it removes the assembly from the OutputPath and PublishDir. So, the assembly is never on the filesystem. What we observe iff we leave the .deps.json file in place (and unmodified) in the publish dir, is that something attempts to load our assembly and fails e.g.:

Error:
  An assembly specified in the application dependencies manifest (CSharpSimpleDesktopClient.deps.json) was not found:
    package: 'Acme.Foo.Bar', version: '4.5.0'
    path: 'lib/netstandard2.0/Acme.Foo.Bar.dll'

This happens before the AssemblyResolve event ever happens. Our solution, as I mentioned before is to remove this bit from the libraries section of the .deps.json file:

  "libraries": {
    ...
    "Acme.Foo.Bar/4.5.0": {
      "type": "package",
      "serviceable": true,
      "sha512": "sha512-xfLPvmt9lmLrwekOQgmwjiPi68zrQ6h88vu1DXA5/gnhObJgNd5Zn6eY1f87qfDwWmJkvCZOe5g15vP7AuYmTA==",
      "path": "acme.foo.bar/4.5.0",
      "hashPath": "acme.foo.bar.4.5.0.nupkg.sha512"
    },
    ...
}

RE AOT, yes we are very interested in this. But the acid test will be to see if we can use AOT on non-trivial apps such as WPF apps. Also, IIRC, PublishSingleFile in .NET 7 (or maybe 6) no longer extracts to the filesystem but extracts in memory.? Or maybe that is just wishful thinking. :-)

[jkotas]

Our current hack is to use a bit of PowerShell to remove the assembly from the libraries section of the .deps.json file

This hack is probably the best way to achieve what you are trying to do.

[rkeithhill]

@jkotas Thanks. That's good to know. Still, I wish there was an MSBuild property we could set to prevent the auto-loading of specified assemblies from the deps.json file. :-(

[jkotas]

Runtime assumes that assemblies specified in deps.json exist on disk and that they can be loaded any time. It is the design point of .deps.json file.

I do not think it makes sense to build first class SDK support for the transformation on build output that you are trying to do. It is very niche scenario.

[agocke]

PublishSingleFile in .NET 7 (or maybe 6) no longer extracts to the filesystem but extracts in memory.? Or maybe that is just wishful thinking. :-)

Correct, single file extracts in memory for managed DLLs (not native) in .NET 6 and .NET 7.

Native AOT won't work for WPF, but single-file likely will.

[vitek-karas]

If it were a package/project reference, you can specify these:

    <ProjectReference Include="..\PluginBase\PluginBase.csproj">
      <Private>false</Private>
      <ExcludeAssets>runtime</ExcludeAssets>
    </ProjectReference>

This will make it so that the code can compile against that reference, but the output will omit those files. It will also not list that assembly in the .deps.json.

[vitek-karas]

Regarding single-file: It's just a very minor bump in terms of hiding your code. There are already tools (like ILSpy) which can open it and inspect anything in it. It wouldn't take much to write a tool which can update a file in there. It's basically just an archive, so provides similar level of "protection" as .zip.