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
Related
My work PC is a Windows 7 machine with Visual Studio 2017 and .NET Core 2.1 SDK. I do not have local admin rights.
I would like to develop an app in .NET Core 3.1 and installed the SDK into my local AppData folder using the Powershell install script.
I also installed VS Code as that also doesn't need admin rights.
However, I am unable to debug my app because VS Code always uses the global .NET Core 2.1 SDK which fails of course. How can I force it to use the local 3.1 SDK?
I have tried setting the PATH in the integrated terminal as well as the DOTNET_ROOT environment variable as mentioned in https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet#environment-variables but no luck.
Note, I am able to execute dotnet new and dotnet build etc. from the integrated terminal and those commands do use the 3.1 SDK.
Would appreciate any help, thanks.
Update: I have noticed that instead of just suffixing %LocalAppData%\Microsoft\dotnet to the end of the Path, if I completely rewite it, removing C:\Program Files\dotnet, then VS Code stops complaining about unresolved references and the red underlines disappear.
This allows me to restore and build, but I am still unable to debug. Thus it looks like the problem is with the OmniSharp extension as it's always looking in Program Files for SDKs.
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.
I need to build a package, based on my c# code. I have already created build definition which used to work, but since .netcore 2.0 announcement on VSTS there is default sdk used with version 2.0. Unfortunatelly it is not working well with previous .netcore version.
I am using command line task for each step, just like below:
I am now unable to restore packages, build project or publish it.
Is there a way to specify which dotnet.exe version will be executed during restoring or any other step?
I was trying to specify whole path "$(ProgramFiles)\dotnet\shared\Microsoft.NETCore.App\1.1.2\dotnet.exe" where it is installed even on vsts, I get then:
Furthermore I was trying to setup a powershell step, but I am unable to provide a argument for it.
& "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.1.2\dotnet.exe" --version
does not respond with anything. I was trying different way to provide args, but also without any success.
How to run an EXE file in PowerShell with parameters with spaces and quotes
Resolved for now with using dedicated Task component from vsts (nuget resore, visual studio build etc.) instead of command line - dotnet with args like restore/build/etc. Only thing that left for me is run unit tests for this app. Visual Studio test does not find any test in solution even with specified dll name.
I am trying to achieve setting up a vNext build definition on TFS 2015 (the project is actually a .NET 4.6.1 web project, but I want to use the new TFS build setup). I am struggling with finding documentation on only deploying a specific web project in my solution (2 web projects, 3 class libraries and subsequent tests).
In the XAML build approach, I would specify the .sln and the .csproj file relevant to the build in the Process > 2. Build > Projects input. The "Visual Studio Build" step does not allow for multiple project inputs in the same way, and this seems to be where I am getting stuck. If I only specify the .csproj, Nuget packages do not get restored and the build fails.
Is there any known documentation for deploying a C# web project (.csproj) ONLY via these vNext builds?
MSBuild arguments previously used in XAML Build:
/p:AllowUntrustedCertificate=True /p:AuthType=NTLM /p:Configuration=Development /p:DeployOnBuild=True /p:PublishProfile="DEV" /toolsversion:14.0 /p:VisualStudioVersion=14.0 /p:GenerateBuildInfoConfigFile=false
The solution I am searching for would accomplish the following:
Builds at the very least the Web.csproj with project dependencies
Restores Nuget packages
Transforms web configs
Deploys Web project to two separate servers (non-Azure!) via, ideally, web deploy
Thanks in advanced for any help. Hopefully this is possible!
Note: I am not on Azure and Azure is not an option. I know there are tons of documented use case scenarios for Azure users, which is great... but, yeah.
You can add a "NuGet Installer" task at the top of your build definition to restore the nuget packages for your solution and specify the .csproj in Visual Studio Build Step.
If you want to build the entire solution, you can add following arguments in "MSBuild Arguments":
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
This will create the deploy packages for your projects separately in "$(build.artifactstagingdirectory)\" folder like following:
Then you can choose the package for the project you want to deploy. And with the deploy package, you can add two "Command Line" tasks in your build definition and call "Project.deploy.cmd" under "$(build.artifactstagingdirectory)\" folder to deploy the project to your servers. Reference about deploy from command: Executing the Command File. Web.config will be transformed by default if you have configured it correctly.
By the way, I recommend you to deploy your projects by using the release management system instead of deploying them in build.
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.