I have upgraded some of my Azure Functions to .netstandard 2.0, that is still in beta. Whenever I publish my Functions directly from Visual Studio, I get the following message:
The csproj file containing my Functions is already is targeting .netstandard 2.0.
Here is the setting in the Function App:
How can I "upgrade" the version of my local Functions?
I have done some tests on my side and reproduce the message you got. Just like #Connor has said, for function in beta version, the csproj file should include AzureFunctionsVersion as the illustration shows.
Once the AzureFunctionsVersion parameter is lost, the function will be recognized as using runtime ~1 despite the TargetFramework. So when the project is published to a beta function app in portal, it will remind us of the version change.
I ran into the same problem today during the creation of an Azure Function project in Visual Studio 2019. It needed a lot of sorting out but below turned out to be the solution for me:
In Azure:
Azure > Function App > Create
Then go to the settings and choose the runtime version, which is ~2 by default (meaning a 2.x version with auto updates enabled).
In Visual Studio:
VS Create project type C# > Cloud > 'Azure Functions'. In the second screen don't forget to choose for "Azure Functions v2 (.NET Core)".
Via the nuget package manager update the Microsoft.NET.Sdk.Functions package.
Also install: Microsoft.Azure.WebJobs (v3.0.9)
Also install: Microsoft.Azure.WebJobs.Extensions.Http (3.0.2)
Clean + Rebuild the project. Now you should be able to Publish directly from Visual Studio to the Cloud. Right-click on the project and choose 'Publish'. Then you should see an option to Publish to an Function in Azure cloud.
If not then the most likely reason is because you have a problem with your references / nuget packages / Microsoft SDK. Or the versions of those.
Related
I am facing this issue only for the particular repo as when I debug i found out that the version of the Azure core tool is older, I updated my Core Tools version from 4.0.4544 to 4.0.4915(x64)
Then after restart and deleting all the temp files when I run my application same error is thrown, and what I found the version is not updated , i check but couldn't find the older version core tool, all i can see is i have only one Azure core tool version which is 4.0.4915(x64)
So, is there any way to found out from where the application is getting the older version of Azure core tool in my local mechine.
I have deleted, and updated the version and also clear the temp file and restart my machine.
The running application is somehow showing the older version of core tool still now.
I checked everything launchSetting.json, jobHost.cs, local.setting.json, startup.cs
Every thing i correctly written.
As i checked with my buddies project only thing which is different is the Azure core tool version,
how to remove the default Azure core tool version and from where?
The terms on the Azure Functions Versions are:
Azure Functions Core Tools Version (V4)
Azure Functions Core Tools Versioned Commits Version (Such as 4.0.4544, 4.0.4653)
The Latest Version in Azure Functions Core Tools is v4 in the generic View.
Some patch updates will be done to the V4 version of AFCT regarding the existing feature breaking changes or adding the new features to it.
The earlier version you have is 4.0.4544 released on May 2022 with the following updates:
As you have updated to 4.0.4915 which is the latest patch update version to the v4 Azure Functions core tools, found in the official release GitHub Repos of AFCT.
When I run the Azure Function from the local IDE, I have got the below versions in the console:
From the above practical, we can say that the latest patch version of v4 Azure Functions Core Tools is 4.0.4915 but the AFCT Commit Version in the local is 4.0.4653 because the commit version of 4.0.4915 is not yet came to the Windows X64 OS Machine which is my current Machine Configuration.
Whereas the Core Tools Commit Patch Version 4.0.4653 is compatible with all the OS and bit-Configuration such Win X64, etc. So, this version 4.0.4653 is the current AFCT Commit Patch Version running the Azure Functions Host Runtime locally.
Note: You can check this path for the Commit Patch Versions of AFCT v4 in the C:\Users\<Your_User_Name>\AppData\Local\AzureFunctionsTools.
I can't successfully build basic ASP.NET web app targeting framework 4.7.2.
I built a docker image with a base image for Windows Server Core 2019. On this image I installed VS 2022 Enterprise and took Azure development, .NET desktop development, ASP.NET and web development modules, including recommended ones.
For dotnet core solutions everything works fine, but for dotnet framework I am getting such errors:
packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props(31,5): Error MSB3758: An error has occurred during compilation. error CS0014: Required file 'alink.dll' could not be found
packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props(31,5): Error MSB4175: The task factory "CodeTaskFactory" could not be loaded from the assembly "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Microsoft.Build.Tasks.Core.dll". The task factory must return a value for the "TaskType" property.
I additionally installed .NET Frameworks: 4.5, 4.6, 4.6.1, 4.7.1, 4.8, but it didn't help.
Locally, I am able to build it without any problems. I checked the image if VS 2022 was installed without any issues and it looks fine as well. All environment variables are also in place. I thought the issue was related with some missing .NET Frameworks with SDKs, but it still persists.
Installing Redistributable C++ 2012-2022 didn't help as well. I am using MSBuild 17.
What I still might be missing?
I want to create an agent for Azure DevOps and as a reference I use the Dockerfile from Microsoft documentation. One difference is that before the start script, I run my custom script to silently install the VS 2022 with the modules I specified earlier.
I use Azure DevOps pipelines to build the solution, and the VSBuild#1 task.
I was finally able to solve the problem I had. It turned out that the base windows server core image didn't contain all of the needed prerequisites nor Visual Studio. Solution was to use extended windows server core image with sdk 4.8. This is strange, because Visual Studio already delivers everything for sdk 4.8. I think the extended image must have had something else that didn't come with the VS installation.
I'm setting up some DevOps for my site, and so far I've used the following command for deployment on two ASP.NET Core apps, with success:
dotnet publish ProjectName.csproj /p:PublishProfile="PublishProfileName" /p:Password=password
I've just created an Azure Function, using the V2 runtime and .NET Core 2.1, as suggested for all new projects (see here https://azure.microsoft.com/en-us/blog/introducing-azure-functions-2-0/), but if I use the same command, I find that it only publishes it to a local folder and doesn't seem to deploy the project to Azure.
If I use the MSBuild equivalent, it seems to also miss out the deployment stage.
I'm guessing its to do with the project type in some way not having the appropriate build targets, but I'm not sure how to track this further.
I can download the publish settings from Azure, import them into Visual studio and publish through VS, so it seems like if the VS path works, this might be a regression or bug in the tooling somewhere, rather than something unsupported?
I'm using:
Visual Studio 15.8.8 +28010.2048
Azure Functions and Web Jobs Tools 15.9.02046.0
If I shouldn't be using dotnet publish with Azure functions, what should I be using instead for command line CD? I've seen references to the Azure Function CLI tools, but I'd prefer not to have to install a package manager on our build agents if it can be done through other tooling.
In the end, with the help of the answers and comments (thanks all), I have an MSBuild command line that is working to deploy my .NET Core 2.1 Function project:
msbuild /p:DeployOnBuild=True /p:PublishProfile=somename.pubxml /p:Configuration=Release
It is, however, worth noting the following:
General .NET Core publishing notes
If you miss-spell the publish profile name, it will silently skip deployment (no warning or error).
Differences between ASP.NET Core and .NET Core Functions deployment
If you use 'dotnet publish', it will always skip deployment.
If you don't specify /p:DeployOnBuild=True, it'll skip deployment.
If you do not want to have "a package manager" on your build agents you have to option to make a zip deploy of your function app. Details can be found on the MSDN here:
https://learn.microsoft.com/en-us/azure/azure-functions/deployment-zip-push#rest
Try the Azure CLI instead:
https://learn.microsoft.com/en-us/cli/azure/functionapp/deployment?view=azure-cli-latest
or the function core tools:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local#publish
I have done Azure Media Services (AMS) POC.
but I am facing problem in integration of AMS into main project. Steps are below:
I am installing windowsazure.mediaservices.extensions package from NuGet but in this case
it gives a error, WindowsAzure.Storage already has a dependency defined for 'NETStandard.Library`, because I have already installed WindowsAzure.Storage.8.1.0 package in project solution.
If I removed this WindowsAzure.Storage.8.0.0 then tried to install windowsazure.mediaservices.extensions package. it shows installation successful but version of WindowsAzure.Storage is 4.3.0 instead latest (8.1.0).
If removing WindowsAzure.Storage.4.3.0 forcefully and adding external reference of WindowsAzure.Storage.8.1.0 (Microsoft.WindowsAzure.Storage.dll) then giving runtime error at the time of Creation of Asset on AMS.
Please suggest any solution.
Thanks in advance
I tried the same thing on one of the projects. It seems this is more of a Visual Studio or Nuget package manager update issue. I tried reproducing the same on a Visual Studio 2015 Community Edition and it worked. Check out the image below:
My end goal is to create a cross-platform (non-web) console application, so I'm exploring .NET Core right now.
In my previous .NET projects, I did all the development inside Visual Studio, but I also created a batch/MSBuild file so I could build the whole project (including setups, NuGet packages, zip files with binaries etc.) with one single click. Here's an example from a previous project.
In the end, I want to do something similar with my .NET Core test project.
But right now I'm failing at the first step: I'm unable to build it outside Visual Studio, so that the result works on another Windows machine without .NET Core installed.
(in the first step, I'm ignoring the cross-platform part - I'll be happy to get it to work on Windows)
What I have
I managed to get it to work inside Visual Studio 2015 Community Edition as follows:
create new project in Visual Studio: "New Project" ⇒ "Web" ⇒ "Console Application (Package)"
create new publish profile inside Visual Studio ("Build" ⇒ "Publish" in the menu).
This will create a PowerShell script (and an XML file with settings)
Here's my test project on GitHub.
When I do "Build" ⇒ "Publish" in the menu again, Visual Studio apparently executes the previously created PowerShell script again.
The result is slightly over 90 MB, consists of 825 files in 598 folders, and looks like this:
When I copy it on another machine (Win 7 / .NET 4 installed / .NET Core not installed), it works.
What I tried to get the same result outside Visual Studio
1. dotnet publish
This answer and this answer sound like I can use dnu publish to achieve the same result via the command line.
I understand that parts of .NET Core are still moving targets right now, so apparently dnu is now dotnet instead.
So I tried to execute dotnet publish (and created a batch file) for it:
dotnet publish "%~dp0\src\CoreTestVisualStudio" -c Release -r win7-x64 -o "%~dp0\release\cli"
The result consists of an .exe file and a bunch of DLLs, only 25 files and 1.5 MB, all in one single folder:
Obviously the .NET Core runtime is missing here, and as expected, this app crashes when I try to execute it on a machine without .NET Core installed (the same one as mentioned above).
2. The PowerShell script from the publish profile
I tried to execute the PowerShell script (which was created when I created the publish profile) outside Visual Studio, but it failed because the script expects some parameters and I don't know what to pass:
param($publishProperties, $packOutput, $nugetUrl)
There's also this line in the script:
# to learn more about this file visit http://go.microsoft.com/fwlink/?LinkId=524327
...but the link just points to the landing page of the .NET Web Development and Tools Blog.
TL;DR
What am I doing wrong?
I know that the first release of .NET Core mainly focuses on ASP.NET, but as I understood it, ASP.NET Core apps are just console apps as well, so I thought a basic console app would work now.
On the other hand, most of the console app "getting started" docs are still missing, so maybe it's just too early and dotnet publish for console apps is not finished yet?
Edit after a few days: I'm suspecting that I'm doing nothing wrong and that it's an issue in the.NET Core command line tools, so I posted it to the command line tools' issue tracker.
Problem solved!
I posted it on the issue tracker of the .NET Core command line tools, and it turned out that it was a bug in dotnet publish - it didn't bundle the C++ runtime, which is needed to execute the compiled app on a machine without .NET Core installed.
The temporary solution was to install the C++ runtime.
The "real" solution was made in a pull request three days ago, which is included in the latest installer now.
With this version, dotnet publish does bundle the C++ runtime, so the result will work on a machine without .NET Core.
For dnu:
There's an option for dnu publish called --runtime that specifies the runtime to include when publishing. You would use the full runtime name with the command, e.g.:
dnu publish --runtime dnx-clr-win-x86.1.0.0-rc1
For dotnet:
You don't need to specify the runtime or framework versions -- by default, dotnet publish will use the framework from project.json and the current runtime flavor. However, the documentation states that:
dotnet-publish command also requires certain dependencies in the project.json to work. Namely the Microsoft.NETCore.Runtime package must be referenced as a dependency in order for the command to copy the runtime files as well as the application's files to the published location.