-
Notifications
You must be signed in to change notification settings - Fork 455
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support .NET Standard 2.0 class libraries #1792
Comments
The current impact seems to be that you actually cannot have any .NET Standard 2.0 library projects referenced in an Azure Function Project (which are framework v4.6.1) at this time. The act of simply referencing an empty Netstandard2.0 project causes a runtime failure of the functions. I don't know what the scope of scenarios are where this will/won't throw an exception. |
Yes, this is pretty bad and leads to very puzzling situations. We'll need to address it. |
Maybe just start by warning people the exciting new update of Netstandard 2.0 is currently strictly incompatible with azure functions since they won't get Nuget or Compiler warnings and will have to find out via obscure debugging like I did. |
David or Lindy, can you confirm that this would be an effective workaround for the HttpClient issue? |
@solvingj the above will not be effective. There would also be other issues you'd run into. We'll have an update, with hopefully a better ETA on the proper support, after this week's triage process (which is happening tomorrow). |
That's an outstanding update already, thank you so much for the feedback. Will look forward to tomorrow. |
@fabiocav any updates? |
Sorry, due to some conflicts this week, the triage process was pushed to tomorrow. We'll have an update then. |
I'm not sure is this a same problem, but I'm piling up my problem related with .NET Standard 2.0. |
@gongdo I just want to confirm, this happens when loading the |
@fabiocav You can break down the problem to reproduce it like this:
But To reference .NET 461 project works fine. |
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup> |
@dasMulli I'm hoping you've tested and this actually works. If so, i can re-try it. But if you've not tested yet, please read this thread and draw your own conclusions (and share it here). Mine was that I don't believe binding redirects work normally in the managed Azure App Service runtimes of webjobs and functions. |
Didn't work out that well for me 😬 thanks @solvingj for reminding me to keep my mouth shut until I actually confirm it works. Been looking at sort of similar issues at the moment (dotnet/msbuild#2481) |
I hope it didn't come off negatively, I didn't mean it that way, all suggestions should be welcome! I was actually hoping because I wanted something to work. TBH, I'm glad to see you're looking tbh. I feel like you might find a workaround while we wait :) |
FYI i just downloaded and installed an update to azure functions and webjobs tools. i still get the following at runtime when hitting my function (during local debug):
I'm not even positive that this error was one of the many targeted to be addressed in this sprint, but it's the error @davidebbo associated back to this ticket. Perhaps someone can confirm that this error is related to this ticket. |
@solvingj this will be addressed in this sprint, with the same set of changes. |
Addressed by #1863 |
Any ETA on release and availability? |
Hopefully today in one region, and then propagating over the next few days. If you have cycles to help us verify in the initial region by deploying a test site, that would help us validate. |
appany-testapp-01 |
And to be clear, is that the app where you saw the issue, or the indirect app used to give me the other app's name? |
That's just the test app i created for this exercise. It's got the real code from my function app behind it. |
Also, important point... Kudu was able to pull in the latest commit to the original function-app deployed in Central US. |
Ok, I see that's the app where you deployed. Take a look at D:\home\LogFiles\kudu\trace in Kudu console, specifically the file that has Background_POST in its name. Seems something caused it to suddenly die. I'm not sure what happened there, but it is most likely unrelated to this issue. Can you try just pushing again? |
Sure, just did "sync" again on the test app (project uses Github deploy).
|
FYI, the deployment is now looking more like it'll start tomorrow and not today. |
Forgot to follow up yesterday, but the change is now live in West US 2 if you want to give it a try! |
@dieterhowest your issue has nothing todo with netstandard2.0 support. Your issue basically comes from using a higher version of System.Runtime than is available on the host. You cloud try referencing version 4.2.0 in your project.json or change your assembly to use 4.1.2 |
Note that the Azure App Service deploy I mentioned above is now complete. |
All regions or just West US 2? |
@solvingj All regions as of this morning. West US 2 was 4 days ago. |
@davidebbo Great news! Have you guys released a new version of the SDK to address this issue while testing locally, yet? |
The npm core tools are out, but the VS extension is due soon. You can work around using https://stackoverflow.com/questions/46269046/azure-function-structure/46289792#46289792 |
Can you clarify if it's weeks or months? |
@solvingj for the VS extension, days. Should be this week. |
I just tried to add a .netstandard 2.0 package to my function. Seems not to work, or did I miss anything?
here is the log:
|
@fabiocav ok, great is there any workaround? |
No great workarounds at this point, but this shouldn't take long. |
we're running into the same thing on our team - thanks in advance for the fix! |
@fabiocav just to make sure, so loading netstandard2.0 from nuget is a problem, but uploading those to let's say the |
@dersia yes, that should work as expected. |
unfortunately it doesn't:
I'm referencing my own netstandard2.0 package in the script |
This could also be caused by a failed dependency. If you have a simple repro and could open a separate issue with the details so it's tracked, I'll take a look at this. |
ok, repro is in #1972 |
I think this is still not fixed. I have an Azure Functions project referencing a .NET Standard 2.0 project. My .NET Standard project references Microsoft.Extensions.Logging.Abstractions 2.1.1. When I debug the project in Visual Studio I get the error
Notice the version number 2.0.1.0 different from version 2.1.1 I'm referencing in the .NET Standard Nuget package I thought I was again in one of these binding redirects issues. So I changed the target Framework version of my Azure Functions project to 4.7.2 which is supposed to be the version fixing all the binding redirects issue when referencing a .NET Standard project. But this didn't solve the problem. So I also tried to install the Microsoft.Extensions.Logging.Abstractions Nuget package version 2.0.1 in a separate .NET Framework Console Application. I copied the Microsoft.Extensions.Logging.Abstractions.dll (I verified with ildasm.exe it's version 2.0.1) to the bin folder of my Azure Functions project but still the same error. And this is actually not the only DLL causing problems. My Azure Functions project also references another .NET Standard project which has a dependency to System.Data.SqlClient and I get the same issue. So I'm confused on why this issue has been closed and supposed to be fixed. On my side it's clearly not fixed. Thank you |
Now that .NET Standard 2.0 is RTM, we should include the facades that enable support on full framework. This is especially important once we port to .NET Core.
The text was updated successfully, but these errors were encountered: