While I can use the latest Microsoft.NET.Sdk.Functions package to build against .NET 5, the tools will not let you run it locally. Running a complied set of functions causes this this output in the tools:
System.Private.CoreLib: Could not load type 'System.Diagnostics.DebuggerStepThroughAttribute' from assembly 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Value cannot be null. (Parameter 'provider')
I also got a runtime exception after upgrading to .NET 5:
Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
I tried adding a PackageReference to my .csproj file, but I still get the same error. Any ideas?
TargetFramework: net5.0
.NET SDK: 5.0.100
VS 2019 Enterprise v16.8.0
Windows 10 20H2 (OS Build 19042.572)
Core Tools Version: 3.0.2996
Function Runtime Version: 3.0.14916.0
experiencing same issue upgraded NetCore3.1 Azure functions to 5.0 - cannot debug locally
System.Private.CoreLib: Could not load type 'System.Diagnostics.DebuggerStepThroughAttribute' from assembly 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Value cannot be null. (Parameter 'provider')
Same here Upgrade Azure Function .NET Core 3.1 to .NET 5 and getting this error:
Azure Functions Core Tools
Core Tools Version: 3.0.2996 Commit hash: c54cdc36323e9543ba11fb61dd107616e9022bba
Function Runtime Version: 3.0.14916.0
[2020-11-11T19:41:10.765Z] A host error has occurred during startup operation 'f070cd92-9072-4328-b7e3-9920d81ccbf7'.
[2020-11-11T19:41:10.767Z] System.Private.CoreLib: Could not load type 'System.Diagnostics.DebuggerStepThroughAttribute' from assembly 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Value cannot be null. (Parameter 'provider')
I'm receiving a similar error in Visual Studio after upgrading to VS 16.8.0 and trying to run a C# function, but for a different assembly.
Azure Functions Core Tools
Core Tools Version: 3.0.2996 Commit hash: c54cdc36323e9543ba11fb61dd107616e9022bba
Function Runtime Version: 3.0.14916.0
[2020-11-12T01:02:00.868Z] A host error has occurred during startup operation 'cd853b62-9e72-41ad-be3e-7066b55df568'.
[2020-11-12T01:02:00.870Z] ProjectName: Could not load file or assembly 'Microsoft.Extensions.Configuration.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
Similar problem for me. My entire journey:
_"Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified."_
Some of you could check this comment about the clean up feature and its workaround.
Some of you could check this comment about the clean up feature and its workaround.
Unfortunately adding <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput> to the csproj made no difference for me. I'm still experiencing the same issues as everyone else here.
I've created a new Azure Function Project with a single HTTP Trigger to demonstrate the problem. Simply running the project demonstrates the issue. The repo is here.
The problems here are expected. The functions DLLs are loaded into the functions host, which is running on .NET Core 3.1. We do not support targeting net5.0 in a function app. We probably could do a better job surfacing the problem in Core Tools.
We're hoping to have a .NET 5 worker in preview by end of year.
@anthonychu yikes, that's a pretty serious adoption blocker for .NET 5. I don't have many projects that don't involve functions.
Not clear from comments here if this is only a local issue related to the function emulator or if it is also a problem when you deploy? Can someone confirm either way?
@gustavf I haven't tried it, but I assume that if you deploy as self-contained, it doesn't matter what version you're building against. Keep in mind that I don't know for sure if the Functions SDK works with v5 either (now _that_ is one of the most neglected projects in the ecosystem).
@gustavf I only tried it locally. Once it failed, I didn't try to deploy it.
Yes, same - would have been nice to see some information on this before I attempted to build .Net 5.0 function. Oh well, regressing...
I'm tried today. Same problem.
Could not load type 'System.Environment' from assembly 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
@anthonychu any ETA on when we'll see v5 supported in Functions? It's a pretty big adoption blocker, and Azure is where we run .NET.
We announced an early preview of the .NET 5 worker.
We鈥檒l work on updating the functions host for .NET 6.
We鈥檒l also look into supporting some v5 frameworks such as Entity Framework Core 5 in the v3 worker, however we can鈥檛 make any promises there.
There are two things that I don't understand from that blog post. The first is that v5 has a "short" support cycle. A year seems like a long time, and it seems implied that if people weren't anxious to use the new bits, we wouldn't see support for it at all until v6.
The second thing is that, especially in this release cycle, v5 is so crazy good compatible that most projects allow us to simply update package references and run with it. I don't think it's been so mercifully easy in the history of .NET! The beta process is rich, public and predictable in timing, so my teams are able to get products updated ahead of time, and usually ship new bits running on the new fx within a few days. What's different about Azure Functions? Who do we have to appeal to to make sure you have the right human investment in staying current? I'm happy to make that noise! :)
I can share a bit on the decision making and prioritization process and how we got here. Back in the spring of 2020, we surveyed some folks that included Microsoft MVPs and discussed our options for .NET 5. The main takeaways were that we should build an out of process worker for .NET 5. And 2/3 of folks expressed that they plan to stay on .NET Core 3.1 instead of upgrading to .NET 5, so we did not feel there was overwhelming demand. Looking back, in hindsight, there was not a lot of solid details on .NET 5 and it made sense that folks were less excited about it at that time.
We also looked at runtimes like Node, where it is generally expected that platforms do not support non-LTS versions.
So over the summer, we started working on building an out-of-proc worker from scratch. It has taken us longer than expected to ship it. We had planned for the preview to land when .NET 5 GA'd, and that it would GA by end of 2020. We've slipped by a couple of months.
As for the assertion that 1 year is a long time, perhaps that's true. But we're also looking at what happens after that 1 year. There's a small 3-month window to ship a new version of the host with the .NET 6 GA bits, _and_ migrate all customers off the .NET 5 host. We didn't feel that we should take a chance that we'd still need to run on .NET 5 after its end of life.
We want to provide timely support for LTS versions of .NET. We learned from .NET Core 3.1 that we need to more closely match the .NET release dates. We plan on updating the host to .NET 6 and having it available close to .NET 6 GA.
What we underestimated was the demand for non-LTS versions. We want to do better here. It's too early to tell what this will look like but I think will largely depend on the feedback on the .NET 5 worker.
I don't know if things have changed, but I recall in my MSDN community days that surveying MVP's for any reason was not reflective of what the broader world was after. :) And if 1/3 of customers were planning to move on up, at the scale that .NET operates at, that's a whole lot of people. If the mainline frameworks have revealed anything since going open source, it's that getting feedback early and often leads to better and far more predictable outcomes.
What I hear you saying is that you hear us, but you're non-committal to setting any expectations for v5, and that's discouraging. In my case, I'm trying to update one of my own OSS projects to keep up with the current bits, and I can't because of the Azure dependency, or specifically, the Functions dependency, which is a key part of the Azure ecosystem. Shared libraries are stuck at v3.1 because they have to be.
Facing the below issue after upgrading from .NET 3.1 to .NET 5. Any workaround suggestions ?
Could not load type 'System.Environment' from assembly 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Same here
Could not load type 'System.Environment' from assembly 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
@anthonychu - So why not carry forward what was in 3.1 until you have the next version ready? Support for functions is pretty essential to adoption.
Has anyone figured out a work-around for this?
I tried working with my Function App as a separate "project", and down grading that to netcoreapp3.1 in the .csproj file.
It builds for netcoreapp3.1, and there's no v5 stuff I can see in it, but it still fails with this precise error.
The "dog ate my homework" stuff isn't helping: does anyone know how to get past this problem, precisely?
Has anyone figured out a work-around for this?
I tried working with my Function App as a separate "project", and down grading that to netcoreapp3.1 in the .csproj file.
It builds for netcoreapp3.1, and there's no v5 stuff I can see in it, but it still fails with this precise error.The "dog ate my homework" stuff isn't helping: does anyone know how to get past this problem, precisely?
For me, functions app works with 3.1. Look at the libraries that you loaded and make sure they don't have >3.1 dependencies.
Good guide here for anyone looking for workarounds https://codetraveler.io/2021/02/12/creating-azure-functions-using-net-5/
Yikes, "workaround" is being generous.
Most helpful comment
@anthonychu yikes, that's a pretty serious adoption blocker for .NET 5. I don't have many projects that don't involve functions.