azure-functions-host: Using ASP.NET Core 2.1.0-rc1-final with Functions 2.0.1-beta.28 -> "Could not load file or assembly 'Microsoft.AspNetCore.Hosting.Server.Abstractions, Version=2.1.0.0 ..."
Hey all.
I have beta 28 installed:
Azure Functions Core Tools (2.0.1-beta.28)
Function Runtime Version: 2.0.11776.0
When executing a function referencing ASP.NET Core 2.1.0-rc1-final, I get this exception:
[5/26/2018 3:00:05 PM] Executing 'Proxy' (Reason='This function was programmatically called via the host APIs.', Id=a2ca9110-8376-4319-8d1a-6991db5253af)
[5/26/2018 3:00:05 PM] Executed 'Proxy' (Failed, Id=a2ca9110-8376-4319-8d1a-6991db5253af)
[5/26/2018 3:00:05 PM] System.Private.CoreLib: Exception while executing function: Proxy. AspNetCoreProxyFunctionApp: The type initializer for 'AspNetCoreProxyFunctionApp.AspNetCoreProxy' threw an exception. AspNetCoreProxyFunctionApp: Could not load file or assembly 'Microsoft.AspNetCore.Hosting.Server.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified. System.Private.CoreLib: Could not load the specified file.
Please see this sample project to reproduce the issue: https://github.com/ChristianWeyer/azure-functions-aspnetcore-proxy
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 21 (8 by maintainers)
This is a bit raw, but you can use the artifacts from this build: https://ci.appveyor.com/project/appsvc/azure-webjobs-sdk-script-y8o14/build/2.0.11886/job/0exdyn0sak341kea/artifacts
We’ll likely have a CLI build today as well.
It is much faster on Windows 😅
You can get the Core tools bits for this release here: https://ci.appveyor.com/project/appsvc/azure-functions-cli/build/2.0.1.372/artifacts
We’re planning on another deployment early next week.
I see the issue. It’s an unfortunate side effect of how the ASP.NET Core builds up some of the dependencies (more specifically, the ApplicationPartManager implementation, that causes it to hit an issue with your scenario. This scenario is somewhat different, as it does run into a few mixed context loads. Good news is that I think there’s an easy fix for this. I’ll validate and keep you updated. We have another incremental release hitting soon, but I can make updated bits available earlier for testing.
This has been addressed with the update we’re rolling out. If you create a function app in West US 2, you should be able to test with those new bits (2.0.11857). CLI will be available soon.
I can provide instructions on how to get the CLI bits working, but they’ll be rolling out early this week
The most confusing part about these errors is that they are appearing in a pre-compiled application where all of the binaries are available in the same folder as the main .dll that contains the function being executed.
I even went so far as to publish the app using dotnet publish with the --self-contained param so even the runtime was included in the folder and that doesn’t seem to work either.
Some information about how the function is being executed in the Azure function environment as well as what it is doing for assembly loading might help developers understand what can and can not be done in Azure functions for dotnet core.
It seems like Azure functions expects a specific version of the dll’s and at this point the 2.1.0 bits are not available yet. Unfortunately requiring specific versions really limits the usefulness of Azure functions from a dotnet core perspective.
Also with other NuGet packages as well.
I can confirm I am experience the same issue, trying to accomplish the same thing as @ChristianWeyer with the same versions of runtimes/packages.