I have a problem with a dotnet core project of mine. I have a TFS build that does a "dotnet publish" and deploys the application to IIS.
The publish command looks like this:
dotnet publish -o $(build.stagingDirectory) -c Release --self-contained --runtime win81-x64
My code hasn't changed but now I get the following error when I run the build on the TFS:
NETSDK1067: Self-contained applications are required to use the application host. Either set SelfContained to false or set UseAppHost to true.
We updated the build server to the newest .NET Core SDK last week so I guess it probably has something to do with that.
What changed and what can I do to make the build work again?
Related
When using the command
dotnet build /p:DeployOnBuild=true /p:PublishProfile=CustomProfile
my ASP.NET Core project builds and gets published using the FileSystem publishing method.
When I use the
dotnet publish /p:PublishProfile=CustomProfile
command (which should do the publish part only) the build part gets done but no publish actions are done.
Is this a limitation from dotnet?
Is there a workaround?
My system:
dotnet --version
3.1.201
VS2019 16.5.3
On "Hosted VS2017" and self-hosted build agent (Windows Server 2012 R2), running dotnet publish with a publish profile specified fails with:
C:\Program
Files\dotnet\sdk\2.1.502\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198,5):
error NETSDK1047: Assets file
'C:\agent_work\11\s\\obj\project.assets.json' doesn't have a
target for '.NETCoreApp,Version=v2.1/win-x64'. Ensure that restore has
run and that you have included 'netcoreapp2.1' in the TargetFrameworks
for your project. You may also need to include 'win-x64' in your
project's RuntimeIdentifiers.
On local dev server (Win10, VS2017, many different .net sdk versions) when I dotnet publish with the exact same command line, everything works great.
I have tried everything from updating VS2017, installing the exact version of .net core SDK and runtime that we're targeting, updating the build agent, windows updates... Nothing seems to help. I can't understand why it's having different behavior.
The publish profile is a FileSystem profile and has the following two elements specified:
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
The command line looks this: "C:\Program Files\dotnet\dotnet.exe" publish "C:\agent\_work\11\s\Source\TheProject.csproj" --no-build -c Release -f netcoreapp2.1 /p:PublishProfile="Publish Release To Filesystem.pubxml" -o C:\agent\_work\11\a\Website -v d
Does anyone have a clue what I can do to get this working?
This turns out to be all about the Runtime Identifier. The confusion arose because I assumed building and publishing from dotnet-cli was as simple as building and publishing from Visual Studio. Visual Studio's publish was doing a full restore/build with its publish, and the publish profile had the <RuntimeIdentifier> set.
I was doing several things wrong. I wasn't including -r win-x64 to the restore and build tasks, and I was using dotnet publish --no-build. So that's where one mismatch came from. The next was that I was running dotnet test after build and before publish. That was wiping out some things that publish needed, not sure what though.
I changed dotnet test to include -p:RuntimeIdentifier=winx64 since apparently it uses -r for reporting output (apparently they're adding -runtime in 2.2).
Some things I learned in the process, dotnet-cli does NOT work well with .sln files, at least in build agent's. It seems to have a big problem with file locks and shared processes. Trying to optimize build tasks to minimize work with the dotnet-cli is a major pain in the ass.
I think Jay covered this in the other answer, but to clarify what worked for me was running:-
dotnet restore <path/to/.sln> -r linux-x64
just before running the dotnet msbuild command. (Obviously replace linux-x64 with your target).
I try to build and publish my .NET Core applications on the command line using predefined publish profiles.
For a ASP.NET Core application this (taken from here) works:
dotnet build -c Release /p:DeployOnBuild=true /p:PublishProfile=ReleaseFolder
But for a console application (where the publish profile is called FolderProfile, the following does not work:
dotnet build -c Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
It builds the project but does not publish it.
So how can I publish a console application using a predefined publish profile?
Publish profile support is part of the web-SDK which is used by the web targets. ASP.NET Core applications typically use the Microsoft.NET.Sdk.Web wheres console applications use the Microsoft.NET.Sdk project.
Since console applications therefor don't include the web SDK's publishing support, you can only use the Publish target which generates deployable outputs. It is wrapped by the dotnet cli's dotnet publish command and can alternatively be used as msbuild /t:Publish. This publish command has no support for publish profiles since it is only a filesystem based operation.
You can now add the Microsoft.NET.Sdk.Publish sdk to your project file. That will enable you to use dotnet publish for your project.
<Project Sdk="Microsoft.NET.Sdk;Microsoft.NET.Sdk.Publish">
We have a VS 2017 solution with one WCF-service project and one .net-core web-application targeting .net framework 4.5.2 and .net core 1.0 (1.0.0-preview2-003131).
By some reason I cannot get the website published through "dotnet publish"-command in visual studio team services.
The problem shows up in build step "dotnet publish", project is specified to match only the web-projects solution-file (**/InventoryIndexWeb.csproj) since I only want the web to be published in this build.
Gives the following errors:
MSBUILD : error MSB1008: Only one project can be specified.
Dotnet command failed with non-zero exit code on the following projects : d:\a\3\s\WebSites\InventoryIndex\Staging\InventoryIndexWeb\InventoryIndexWeb.csproj
See screenshot for details:
Any suggestions how to solve this or workarounds? The plan is to push this to Octopus deploy as well when we get the publish step working.
You cannot pass multiple projects / arguments to dotnet publish.
In your case you seem to have passed the artifacts folder as second argument. To do this, add -o before that directory:
dotnet publish your.csproj -o $(Build.ArtifactStagingDirectory)
Changing to pass -o as parameter instead of only $(Build.ArtifactStagingDirectory) did the trick as Martin stated above, and final configuration as below.
I'm having some trouble understanding how to publish an ASP.NET Core application to a server using Webdeploy on TeamCity.
I've installed the dotnet core teamcity plugin and have two build steps:
dotnet restore (as a command line step, the built in step timesout on nuget)
dotnet publish src/projectName/projectName.csproj
However I'm confused as to what to do for the third step, which is to publish the result of dotnet publish to our server.
Traditionally we'd use MSBuild and target a publish profile, however I'm unsure whether .NET core utilises MSBuild.
I've got a publish profile as part of my solution which works successfully within VS2017. I've had a look at the TeamCity blog which discusses setting up TeamCity to use .NET Core, and whilst it does mention WebDeploy, it just simply mentions it can be used alongside dotnet publish without really explaining how.
However I'm confused as to what to do for the third step, which is to publish the result of dotnet publish to our server.
Traditionally we'd use MSBuild and target a publish profile, however I'm unsure whether .NET core utilises MSBuild.
I've also found documentation on automated .NET Core deployment lacking. Generally for deploying to IIS you have two options.
You can still use MSBuild with /p:DeployOnBuild=true to deploy a .pubxml publish profile created in Visual Studio as with .NET framework sites. Run MSBuild after dotnet restore and instead of dotnet publish.
Or you can also use dotnet publish to publish to a folder, and msdeploy.exe to sync that folder to an IIS site, possibly on a remote machine. Typically:
msdeploy.exe -verb:sync -source:contentPath="<the folder published to by dotnet publish>" -dest:contentPath=<Your IIS Site>
I've using the next command to create web deploy package:
dotnet publish <Path_and_name_of_project>.csproj --configuration Release /p:PublishProfile=<profile_name>
and after this step, i've deploy package to iis via webdeploy command