blocking-issues-in-dotnet.md

In order to write software that targets both .NET 4.6 and .NET Core, we need .NET 4.6 to fix several oversights.

Visual studio, ASP.NET, deploy tooling, test tooling, and even the .NET runtime make some bad assumptions:

• Every .dll is a .NET dll.
• Managed .dlls do not depend on native .dlls
• No project ever needs to target or deploy to more than one architecture/platform.
• Nobody needs to adjust native or managed dll search paths at runtime.

Specifically, what low-level APIs do we need before we can fix dependency loading ourselves?

1. The ability to capture and override the load path of every .NET assembly, not just those which are missing (which AssemblyResolve provides). This will allow us to avoid BadImageFormatExceptions and locate compatible binaries instead to bring into the default load context.

2. The ability to either

• A) Represent all versions of unmanaged and non-Any CPU dependencies within the metadata of a managed assembly, so that tooling and hosts can correctly deploy and shadow-copy them.
• B) Use a standard assembly attribute to define an entry-point which will called for every movement (such as test runners, deployment, or ASP.NET dynamic compilation), which can be responsible for the process.
• C) Expose a comprehensive list of still-accessible locations where we left the original binaries behind. (In many contexts, neither Location or Codebase are sufficient for discovery, such as for shadow-copying or nuget references). This does not handle some scenarios, like deployment.

We need pervasive architecture awareness, or the ability to create it.

3. A (respected) way to tell hosts (like ASP.NET/IIS) that the world will end if they use more than 1 AppDomain per process. Many native interop scenarios can't handle AppDomains, period.

4. A way to do #1 in the context of an ASP.NET app . ASP.NET currently loads everything in the /bin folder, then calls PreAppStart on each one. We can't assume everything in /bin root will load successfully, since we still have tooling that is impeded when it comes to targets and managed/native correlation. Hacking this with isn't well-received; a fully qualified assembly reference to preload would be better.

5. The ability to control the assembly probing path at runtime - so that we can support architecture-specific bin subfolders - within the default load context. We should even be able to exclude ApplicationBase, so that we can cleanly hand control over to an external assembly for dependency resolution. This is somewhat a duplicate of #1, but with better performance for simple scenarios.

Much of the ecosystem (read: nuget packages) around .NET is reliant upon Windows APIs. This may may come in the form of System.Drawing, System.Media, or P/Invoke calls, but it is prevalent. Moving to .NET Core and vNext will entail the creation or porting of dozens of native libraries with corresponding interop layers. The current interop pain is too great for most OSS maintainers to overcome simply for the sake of .NET Core compatibility, so if we're to have to the future we all want (.NET Core), we need to fix it.