HttpRequestMessageExtensions not being found at run-time in Azure Function - azure

I've got an Azure Function app that creates a precompiled DLL (so it uses normal .cs files, not the older .csx method, pre-VS2017). Previously, it was targeting .Net Framework 4.5.2. I updated it to 4.7 so as to use some of the new C# 7 features. I updated my NuGet packages by doing "Update-Package -Reinstall" and verified that they all have the "net47" target set in my packages.config file.
Everything compiles fine. But when I call a function that uses either of 2 HttpRequestMessageExtensions methods, I get an exception. One example of the exception is this:
Method not found: 'System.Net.Http.HttpResponseMessage
System.Net.Http.HttpRequestMessageExtensions.CreateResponse(
System.Net.Http.HttpRequestMessage, System.Net.HttpStatusCode)'.
Here's an example of a tiny test function that will cause the error:
using System.Net;
using System.Net.Http;
public static HttpResponseMessage Run(HttpRequestMessage req)
{
return req.CreateResponse(HttpStatusCode.Accepted, "");
}
Upon calling this function with say Postman, I'll receive the aforementioned exception. I also get a similar method not found exception when I call GetQueryNameValuePairs() on the HttpRequestMessage.
I've tried updating my NuGet packages to the latest, no difference. I've cleaned and rebuilt and restarted a bunch of times, making sure to nuke my bin and obj directories.
I'm not sure what could be the problem. I guess I could downgrade back to .Net 4.5.2 but I'd rather not. For one, I want to use C# 7, and for two, I want to understand what the problem is rather than avoid it.
Update: interesting. The issue seems to be with System.Net.Http. If I lower it to 4.0.0 everything works fine. If I raise it to any higher version I get the issues listed above. I tried selectively lowering each of my packages, one by one, to their previous version number to find this out. I then updated all but this one to the latest version and it fixed the issue.

I also tested it on my side. The issue is related to the latest version of System.Net.Http assembly(4.3.2). If I don't install this package manually or install the earlier versions(4.3.1/4.3.0), the application could work fine.
The CreateResponse method is a extension method which is written in System.Web.Http assembly(version 5.2.3). It seem that it is not compatible with the latest version of System.Net.Http. Please could just skip the error by using the earlier version of System.Net.Http and you can also submit this issue to Microsoft using follow channel.
https://connect.microsoft.com/VisualStudio/Feedback
Interesting. For me, if I got above version 4.0.0 (including 4.1.1 or 4.3.1) I still get the same problem of not finding those extension methods.
The assembly might not be updated during you change the package version. From the bin\Debug\net47 folder, we could check the current assembly version we used.
If the modified date of assembly is 2/9/2017, the package version is 4.3.1. If the modified date of assembly is 4/19/2017, the package version is 4.3.2. If the assembly is not the latest version, it could work fine on my side.
In addition, Microsoft.Asp.Net.WebApi.Client package is installed by default when creating an Azure function. System.Net.Http is one of its dependencies. So we don't need to install the System.Net.Http package manually. When running our application, NuGet will choose a right version of System.Net.Http for our application.

I had the same issue running my Azure Function locally and eventually tracked it down to conflicting System.Net.Http assemblies. I created my Azure function from a blank ASP.NET Web App and initially pulled down the System.Net.Http NuGet package to use within the project. I also pulled down the Microsoft.AspNet.WebApi.Client for use within the project. It did not matter which version of System.Net.Http I tried my project would compile but fail when the request was made.
Eventually, I removed packages I had downloaded, cleaned the build folder and added just the Microsoft.AspNet.WebApi.Client. I noticed that this automatically referenced the System.Net.Http on my machine for my version of the .NET Framework. (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework). This compiled successfully and I was able to make requests to the function without any exceptions.

Using #Aaron-Newton's insight, I identified that my issue was due to my Azure Functions project referencing a .Net Standard 2.0 class library. I switched it to .Net Framework 4.6 and it started working again. Seems like this is a bug in the Functions tooling.
I've filed a bug with the Functions team here: https://github.com/Azure/Azure-Functions/issues/477

I had the same issue. I spent quite a while to fix this problem.
The cause is that the Azure Functions project is refering to .Net Standard Library with version higher than 1.4.
Bringing down your .Net Standard version to 1.4 or lower would fix the problem.
But this is defintely a bug with Azure Functions SDK. They should fix it.
https://github.com/Azure/azure-webjobs-sdk-script/issues/980
https://github.com/Azure/Azure-Functions/issues/477

Related

Azure Function Version Affecting GET Request

When I try to set Azure Functions to stable versions 1.0.14 or 1.0.13 locally & in the Portal - I tend to receive a 500 error when trying to GET an endpoint. Through some debugging, I managed to correct this by changing the version to beta. No errors.
Has anyone else seen this issue? Is there any way around this without actually having to recreate the function using the desired version?
Thank you!
You probably mistake Azuer Function SDK version for Azure Function Runtime version.
try to set Azure Functions to stable versions 1.0.14 or 1.0.13 locally & in the Portal
1.0.14 or 1.0.13 you mentioned is SDK version(latest is 1.0.19 right now), which is used to build our function project. Of course we can't set SDK version on portal as build is done before we publish pre-compiled code to Azure. If we develop in browser, the build process and SDK version(the latest) is under the control of Azure.
I managed to correct this by changing the version to beta. No errors.
You may have created a v2 function locally, hence function depends on beta runtime. And you specify a wrong version of 1.x like 1.0.14, so 1.0.11959 is used. We can see 500 error is caused by mismatched runtime and you have corrected it. If you have planned to work with v2 function(.net standard), nothing malfunctions so far.
And some more info about function runtime version.
Function Runtime version
There are two major versions: 1.x for .Net Framework and 2.x for .Net Standard.
Syntax
Major version :~1 for 1.x , ~2 for 2.x. With this format, function app on Azure is automatically updated to new minor versions of the runtime when they become available.
Minor version 1.x:1.0.11959; 2.x: 2.0.11961-alpha, 2.0.12050-alpha. (All versions available right now). Function app on Azure is kept on that version until we explicitly change it.
Where to find
Runtime version in Function app settings.
FUNCTIONS_EXTENSION_VERSION in Application settings.
Configuration
Two scenarios we need to change runtime.
Major version change. ~1 to ~2 or reverse.
We may see prompt below if there are functions in the app.
Major version upgrades can introduce breaking changes to languages and bindings. When upgrading major versions of the runtime, consider creating a new function app and migrate your functions to this new app.
In an empty function app(delete existing functions or create new app), change runtime in Function app settings.
We can directly set FUNCTIONS_EXTENSION_VERSION in Application settings if published project depends on another runtime.
Minor version pinned to avoid breaking changes(probably the last time to use as 2.x is planned to be GA by this fall).
See breaking changes in 2.0.12050-alpha(beta), we can pin FUNCTIONS_EXTENSION_VERSION to 2.0.11961-alpha and follow steps to work with changes and move to beta.
Find more breaking changes to fix if our 2.x function runtime is pinned to some older version, which have all been removed on Azure.
Wrong version handler
If we specify a wrong version of 1.x like 1.0.14, Azure will leverage latest minor version instead. It is same with 2.x.
For local dev
Commonly speaking, local dev doesn't need runtime configuration because we choose Cli first(using tools like npm or VS does in background), we are clear about the major version at least.
Some local places to find function runtime version.
VS, New Function project v1 or v2.
VS/VSCode c# function, in functionappname.csproj, see <AzureFunctionsVersion>v2</AzureFunctionsVersion>.
VSCode, functionapp/.vscode/setting.json, see "azureFunctions.projectRuntime": "~2"
Function core tools(Cli), run func, we may see Function Runtime Version:2.0.12050.0
Start a function app in VS/VSCode/Cli, besides 4, we can also see Cli output Starting Host (HostId=xx, InstanceId=xx, Version=2.0.12050.0, ..)
Very useful information, thank you Jerry! I managed to solve my issue by recreating the Azure function without using .NET Standard. Azure lets you know that changing certain settings may lead to the function not working properly. After recreating with the proper runtime set in both portal and project, it worked.

Microsoft.Azure.Mobile.Client package updated, and now System.Net.Http doesn't exist

I just updated the Microsoft.Azure.Mobile.Client package in my Xamarin project and now the System.Net.Http namespace doesn't exist anymore. Here's the error message. I was using the MobileServiceClient object to pass through the URL for my Azure backend. What should I do now? I don't want to go back to the previous version if I don't have to.
The error message is pretty explicit. Do you have a System.Net.Http reference in your app? If not, add one.
What is likely to have happened is that the dependency that the package has is for a version of System.Net.Http that is not compatible with your target .net version and the upgrade has removed the old version and not been able to add the new version.
You will need to find the version of System.Net.Http which is a dependency of Microsoft.Azure.Mobile.Client and find out what version of .Net it targets (the folder is likely to be underneath your packages folder even if the reference is missing).
Then you can decide whether you can target your project at a newer version of .Net or whether you need to downgrade Microsoft.Azure.Mobile.Client.

Cannot add Microsoft.Azure.Devices to ASP.NET 5 project: can't find fx/System.Net.Http.Formatting

When adding the Microsoft.Azure.Devices NuGet package (I've tried 1.0.0, 1.0.2, and 1.0.4) to an ASP.NET 5 (Web API 2) project, the reference to System.Net.Http.Formatting is marked as not resolvable with
NU1001 The dependency fx/System.Net.Http.Formatting could not be resolved
There are several NU1001 issues out there, but none whose causes seem to map to this one. The best reference is this one on Github, but the resolution details were sketchy.
The reference DLL is indeed marked as Copy Local when the package is brought into a 'legacy' assembly package, so I can see why it might not find it, but can't determine the right way to fix it.
In my actual use-case, Microsoft.Azure.Devices is being referenced by a .NET assembly package and THAT is then included as a project reference in the ASP.NET 5 project, and indeed that gives the same error as trying to directly reference the NuGet from the ASP.NET 5 project.
We're using dnx452 as the only framework referenced in the project.json file.
I tried this with version 1.0.5 and it installed successfully for me.

StorageClient does not exist in the namespace using Microsoft.WindowsAzure

This code was working previously but on updating nuget packages something seems to have gone awry. If I add in the Microsoft.WindowsAzure.StorageClient dll that had previously been deployed then it is not recognising the Cloud classes such as CloudBlobClient which I am using WindowsAzure.Storage nuget 4.2
I need this to be able to write to azure file services so cannot simply uncomment
Microsoft.WindowsAzure.StorageClient namespace does not exist in the new Microsoft.WindowsAzure.Storage.dll. I would strongly recommend removing all references to Microsoft.WindowsAzure.StorageClient.dll and changing the code to use the new library.
If you still cannot see Microsoft.WindowsAzure.Storage after these steps, you can try uninstalling the NuGet package and reinstalling it.
Although the Microsoft.WindowsAzure.StorageClient DLL is likely outdated, I succeeded to download it manually from https://nuget.org/packages/AzureSDK2.2DLLs/ and install it to Visual Studio 2013 Community (using the instructions from another answer).

MSBuild now failing to resolve references

We have a few projects within our CI environment which have been building successfully. Over the weekend, our IT team installed Azure SDK udpates, and since then, our project to not build anymore (even though they don't reference Azure).
The way we are building projects is
<MSBuild Condition="'$(BuildProject)' != ''" Projects="#(Projects)"
Properties="Platform=$(Platform);Configuration=$(Configuration);OutDir=$(TempProjectFilesPublish)\bin\;WebProjectOutputDir=$(TempProjectFilesPublish)"
Targets="Build"
ContinueOnError="false">
where #(Projects) is a reference to the Solution folder.
<Projects Include="$(BuildProject)"/>
The issue is around resolving project references. Nothing has changed over the weekend. The project references are correct, the csproj file has the appropriate values, no new projects or code changes have been made which is leading me to think something has been disrupted.
Wondering if anyone might know of any changes to MSBuild that would affect this?
This issue ended up being a bug in Azure SDK 2.3 with a conflict to Newtonsoft.JSON dll.
The SDK installs a 4.5 build version into the GAC, which is overriding any Newtonsoft references in projects to 4.0.
https://connect.microsoft.com/VisualStudio/feedback/details/850425/windows-azure-vs-tools-breaking-msbuild-for-web-projects
Microsoft have stated this will be fixed in 2.4.
I experience the same problem with Azure SDK v2.9. I've fixed the build for the moment by uninstalling "Microsoft Azure Library for .NET v2.9".
P.S.: Unfortunately, the link provided in the answer by mickyjtwin no longer works.
P.P.S.: The following question seems to be related:
Visual Studio keeps overwriting NewtonSoft.Json.DLL with an older version

Resources