When I use the publish wizard built into VS 2019 all the files I require are created (271 files). There are the files System..dll, api-ms-win-crt-utility-l1-1-0.dll etc.
However, when I use the command below, I only have 60 files and unfortunately the Windows Service application will not work. What do I need to add to the command so that the number of files is the same as that produced by the publishing wizard ?
dotnet publish /p:Configuration=Release /p:self-contained=true /p:framework=net5.0 /p:runtime=win-x64 /p:Platform="Any CPU"
Have you tried the following dotnet publish format:
dotnet publish --configuration Release --self-contained true --framework net5.0 --output "C:\Users\YourUserName\YOUR_RELEASE_FOLDER" --runtime win-x64
Related
I am trying to publish my dotnet project-api from jenkins via powershell. The problem is when I publish it from powershell it's missing around 30 files and I can't reach api. However when I publish it from visual studio manually (or from visual studio package manager console with commands) it works perfectly. What might be causing this issue?
Here are the commands that I am running to publish api ;
dotnet restore
dotnet build --configuration release
dotnet publish -c release --output "path to the publish file"
I have also tried with this to publish command yet it didn'T work;
dotnet publish dotnet publish -c Release --self-contained -r win10-x64
I have been trying to figure this issue for a long time but I couldn't find a way. I would highly appreciate any help. Thanks!!
You should try following 2 Execute Windows batch command
Command
"C:\Program Files\dotnet\dotnet.exe" restore yourProjectSLN file
[E.g:yourProjectSLN = git/FolderName/ProjectName.sln , it should be same as jenkins configuration]
Command
dotnet publish yourProject_csproj_file_location -c:Release
[E.g:yourProject_csproj_file_location = git\FolderName\ProjectName.csproj]
I'm trying to build a dotnet core application via Azure DevOps. I want my assemblies to be versioned with the build number.
In .csproj file:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
<Version>0.0.1</Version>
</PropertyGroup>
The yaml build pipeline contains:
trigger:
branches:
include:
- master
pool:
name: 'Hosted Windows 2019 with VS2019'
#vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
Version.Revision: $[counter(format('{0:yyyyMMdd}', pipeline.startTime), 0)]
VersionMajor: 0
VersionMinor: 1
name: '$(VersionMajor).$(VersionMinor).$(Date:yy)$(DayOfYear).$(Version.Revision)'
steps:
- task: DotNetCoreInstaller#0
inputs:
version: '2.2.300'
- script: dotnet build --configuration Release /p:Version=$(Build.BuildNumber)
displayName: 'dotnet build $(buildConfiguration) $(Build.BuildNumber)'
In the Azure Devops build log the command seems to pick up the correct version:
dotnet build --configuration Release /p:Version=0.1.19185.10
But when I download the artifacts and verify the dlls they still contain version number 0.0.1
Executing this command locally does add the version number in the dll. So, why is the version not added via Azure DevOps?
Unless you tell it otherwise dotnet publish will cause a recompile before publishing files, and thus overwrite anything you've previously tried to acomplish with dotnet build. You use the --no-build flag to supress the compile. Note that --no-build will also set --no-restore so you need to call dotnet restore explicitly. A typical set of commands (with typical variables you might see in Azure DevOps) might be:
dotnet restore
dotnet build --configuration $(BuildConfiguration) --no-restore /p:Version=$(Build.BuildNumber)
dotnet publish --configuration $(BuildConfiguration) --no-build --output $(Build.ArtifactStagingdirectory)
See this blog post for more details.
In visual studio solution I have single .net core 2.0 library project. And to the publish the library i am using dotnet publish -c release command
however its not zipping the publish folder. I have read the issue 6598 and use the suggested approach using dotnet build command as below
dotnet build ApiRouting.sln /nologo /p:PublishProfile=Release /p:PackageLocation="C:\temp\Routing\package" /p:OutDir="C:\temp\Routing\out" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /maxcpucount:1 /p:platform="Any CPU" /p:configuration="Release" /p:DesktopBuildPackageLocation="C:\temp\Routing\package\package.zip"
`
but that did not work either.
My project is aws lambda project which is C# library project not asp.net web project so i tried removing /p:WebPublishMethod=Package option but that did not work either.
Questions
1>What parameters i need to pass to publish command so that it would create zip file of publish folder.
2>In linked issue 6598 why its suggested to use build command instead of publish when build command only builds the project?
(on side note i can use aws tools for visual studio and use Publish to AWS Lambda and it creates zip file and deploys it to AWS directly from visual studio. However, we are using Jenkins for CI so i want use dotnet cli to create zip file so jenkins can execute that command and create zip file.)
i found it. These 2 links helped me
https://docs.aws.amazon.com/lambda/latest/dg/lambda-dotnet-how-to-create-deployment-package.html
https://docs.aws.amazon.com/lambda/latest/dg/lambda-dotnet-coreclr-deployment-package.html
first installed Amazon.Lambda.Tools
dotnet tool install -g Amazon.Lambda.Tools
and then to package and deploy
dotnet lambda deploy-function apirouting –-function-role myrole --profile lambdadep --profile-location C:\test\testawsprofile
I asked here how to create a .exe to run on Windows and learned the command
dotnet publish --configuration Release --runtime win-x64
This created files in the \bin\Release\netcoreapp2.0\win-x64 folder
as well as a subfolder called publish which contains a copy of the same files.
Why are duplicate files created? ( In the Win-x64 folder and in the publish folder)
dotnet publish builds the project before copying binaries to the output directory. The files you see in bin\Release\netcoreapp2.0\win-x64 directory are the result of dotnet build command. You could check it by running following command:
dotnet build --configuration Release --runtime win-x64
You will see exactly the same files as if you run dotnet publish --configuration Release --runtime win-x64.
Output binaries provided by build stage are then copied to publish directory together with required dependencies. You probably could expect that binaries are built right away to publish directory without necessity to duplicate them from build directory to publish. Well, it's a fair assumption. However it will harm separation of different stages - build and publish. Also as far as HDD resource is very cheap now, it shouldn't be a big issue.
I'm attempting to create a script to simplify the process of publishing a .NET Core website. I'm running into an issue when I run dotnet publish against an already running server. The server is IIS with the dotnet bundle installed, so IIS uses its app pool to start dotnet.
Here's my batch file. I'm happy to use another script type:
cd src/app
dotnet build --no-incremental
dotnet publish --framework netcoreapp1.0 --configuration Release --output ../../dist
When I run the script I get this error:
"The process cannot access the file 'C:\inetpub\wwwroot\app\dist\app.dll' because it is being used by another process."
This makes sense, it appears I need to stop, deploy, and restart dotnet. Can I do this from the script? Or is my approach to this problem wrong?
The best way is to drop an app_offline.htm file to your application folder. This will make IIS stop your application and serve the contents of the app_offline.htm file to the user while you are copying the new version. Once you complete copying the new version of your application remove the app_offline.htm file and IIS will start your application.
You can find more details on running ASP.NET Core applications with IIS in my post.
Based on Pawel's answer, I have a deploy folder containing my app_offline.html file and multiple deploy scripts to IIS. Here's a sample script I use to deploy:
copy .\app_offline.htm C:\hosting\my-project\app_offline.htm
dotnet publish ../MyProject.csproj -r win-x64 -f netcoreapp2.1 --self-contained -c Release -o C:\hosting\my-project
del C:\hosting\my-project\app_offline.htm
I think this is a valid solution, but doesn't help when I want to script the build process.
Stop-Website "xxx"
Stop-WebAppPool "xxx"
Start-Sleep -Seconds 5
dotnet publish --output d:\publocation
Stop-WebAppPool "xxx"
Start-Website "xxx"
if you've created a published profile in Visual Studio and you're using IIS, then you can use that profile instead of writing directly to the destination directory:
dotnet publish /p:PublishProfile=Properties\PublishProfiles\IISProfile.pubxml