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 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?
https://codopia.wordpress.com/2017/07/21/how-to-fix-the-assembly-binding-redirect-problem-in-azure-functions/
@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.
It seems that some .NET Standard 2.0 libraries break Web Jobs process somehow.
https://github.com/gongdo/ReproduceFunctionAppFailure
@gongdo I just want to confirm, this happens when loading the LoggingLibraryDummyCore project/assemblies, correct? When referencing .NET Standard 2.0 assemblies, you'll run into those kinds of problems (they manifest differently depending on the scenario). We'll have that addressed this sprint and will update this issue when that is done.
@fabiocav You can break down the problem to reproduce it like this:
Microsoft.Extensions.Logging.AbstractionLoggingLibraryDummyCore which have package reference to Microsoft.Extensions.Logging.AbstractionBut To reference .NET 461 project works fine.
~Ad binding redirects: When a project targets .net framework and does not have <OutputType>Library</…>, automatic binding redirects generation is disabled in msbuild and needs to be enabled manually in the project file (the second property is important):~
<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 (https://github.com/Microsoft/msbuild/issues/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):
mscorlib: Exception while executing function: AgentsPost. API.Routing: Method not found: 'System.Net.Http.HttpResponseMessage System.Net.Http.HttpRequestMessageExtensions.CreateErrorResponse(System.Net.Http.HttpRequestMessage, System.Net.HttpStatusCode, System.String)'.
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.
Sure, what's the region. FYI, I still have the bug where my local debug session crashes. I thought that would be fixed before it was live on Azure.
I will likely be 'West US 2' (different from 'West US'), but it's not there yet. We'll let you know.
We'll need to release a new version of the client tools as well.
Setting up to deploy there now to validate the original failure condition beforehand.
Awesome, thanks!
Upon deployment...
Wed 09/13 An unknown error has occurred. Check the diagnostic log for details.
Can't seem to find the deployment diagnostic log in kudu console.
Odd, can you share the test app name?
Invited you to the project on github. Did you want the app name in azure?
Yes, the app name in Azure. There is a way to give it indirectly, though in this case since you created a temporary test app, I'm guessing the name has no real value.
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).
As for the deployment in central region, looks like we're currently in good shape, reproducing the expected error:
"message": "Exception while executing function: ReposGet -> Method not found: 'System.Net.Http.HttpResponseMessage System.Net.Http.HttpRequestMessageExtensions.CreateErrorResponse(System.Net.Http.HttpRequestMessage, System.Net.HttpStatusCode, System.String)'."
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!
Is there a SDK update because i have a Azure Function project that references a .NET Standard 2.0 library but i get the following message (see screenshot attached)
@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?
{
"frameworks": {
"net46":{
"dependencies": {
"My.NetStandard20.Shared": "1.0.0-alpha-128",
"Microsoft.Extensions.DependencyInjection": "2.0.0",
"Microsoft.Extensions.Configuration": "2.0.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "2.0.0",
"System.Diagnostics.TraceSource": "4.0.0.0",
"System.Reflection.TypeExtensions": "4.0.0.0",
"Microsoft.Extensions.Logging": "2.0.0",
"Microsoft.Extensions.Logging.Console": "2.0.0"
}
}
}
}
here is the log:
2017-09-25T17:38:30.061 Errors in D:\home\site\wwwroot\myfunction\project.json
2017-09-25T17:38:30.061 Package My.NetStandard20.Shared 1.0.0-alpha-128 is not compatible with net46 (.NETFramework,Version=v4.6). Package My.NetStandard20.Shared 1.0.0-alpha-128 supports: netstandard2.0 (.NETStandard,Version=v2.0)
2017-09-25T17:38:30.061 Package Microsoft.Extensions.DependencyInjection 2.0.0 is not compatible with net46 (.NETFramework,Version=v4.6). Package Microsoft.Extensions.DependencyInjection 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
2017-09-25T17:38:30.061 Package Microsoft.Extensions.Configuration 2.0.0 is not compatible with net46 (.NETFramework,Version=v4.6). Package Microsoft.Extensions.Configuration 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
2017-09-25T17:38:30.061 Package Microsoft.Extensions.Configuration.EnvironmentVariables 2.0.0 is not compatible with net46 (.NETFramework,Version=v4.6). Package Microsoft.Extensions.Configuration.EnvironmentVariables 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
2017-09-25T17:38:30.061 Package Microsoft.Extensions.Logging 2.0.0 is not compatible with net46 (.NETFramework,Version=v4.6). Package Microsoft.Extensions.Logging 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
2017-09-25T17:38:30.061 Package Microsoft.Extensions.Logging.Console 2.0.0 is not compatible with net46 (.NETFramework,Version=v4.6). Package Microsoft.Extensions.Logging.Console 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
2017-09-25T17:38:30.061 One or more packages are incompatible with .NETFramework,Version=v4.6.
@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 bin and then referencing with #r "../bin/mypackage.dll" should work?
@dersia yes, that should work as expected.
unfortunately it doesn't:
Function ($readmodeljob-service) Error: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

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 https://github.com/Azure/azure-webjobs-sdk-script/issues/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
Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=2.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.
Notice the version number 2.0.1.0 different from version 2.1.1 I'm referencing in the .NET Standard Nuget package
I have no idea why it is looking for this version, I've zero result for the string 2.0.1 in my entire solution
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.
Anyone has a workaround?
Thank you
Most helpful comment
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 have no idea why it is looking for this version, I've zero result for the string
2.0.1in my entire solutionI 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.
Anyone has a workaround?
Thank you