Hello I need to upload to Artifact the results of the VSBuild of the Solution but I can not use OutPutpath I get an error that the solution can not copy to certain files.
If I do not put an outputpath in the argument everything works fine, but I do not know what is the place of the VSBuild results to upload them to Artifact.
When using the VSBuild task to build a solution, normally the build artifact should be output into the directory of each project in the solution. So, the output path you set on the VSBuild task should be a relative path to each project directory.
You can follow the steps below to set up your pipeline:
On the VSBuild task, set the output path like as this.
-p:OutputPath={the relative path}
After the build, use the Copy files task to copy the artifact files form the output path to the directory $(build.artifactstagingdirectory).
Then use the Publish Pipeline Artifacts task to publish the artifact files from the directory $(build.artifactstagingdirectory).
The above are the most common steps to build projects and publish build artifacts in the build pipelines.
Related
I need to create a self-contained .net core (3.1 in my case) app and to pack & publish using chocolatey so it can be installed and used.
I'm using Azure DevOps and have a feed on my own where I'm supposed to publish the chocolatey package.
The objective is to do this in the build pipeline, so, among other tasks I have:
dotnet publish task: creates the self-contained executable
chocolatey pack task: creates the .nupkg from a very simplistic .nuspec (only mandatory fields) I created.
My current problem is that the .nupkg file created contains always the project files and not the executable generated.
To try and work around it I even made the chocolatey pack's task work directory the same as the dotnet publish's task output one.
What am I missing? Is there another approach?
Azure DevOps: publish self-contained .net Core app with Chocolatey
It depends on whether you include the contained executable file in your .nuspec file.
If we include the contained executable file in the .nuspec file, chocolatey will create the .nupkg include the contained executable file, like:
<files>
<file src="IngestCanonicLtesConsole\ContainedExecutable.exe" target="Tools\ContainedExecutable.exe" />
</files>
We could add this contained executable file in the package:
So, if we are only include the mandatory fields without the <files>contained executable </files>, it will not include the contained executable file.
Besides, we need to include the contained executable file in the .nuspec file, we could change the output of the dotnet build to $(System.DefaultWorkingDirectory)\IngestCanonicLtesConsole, so that we could use the relative path in the .nuspec file.
Please check the document .nuspec reference for some more details.
After a few tests I realized that the chocolatey pack will "pack" all files that in exist in the same folder as the ".nuspec". Not sure this is because I don't set anything on tool.
Basically, my solution was to copy my ".nuspec" file to the folder where my executable was.
I have an incredibly simple .NET core console application that I'd like to publish into a self contained executable. My application uses an the Microsoft.Extensions.Configuration.Json package so I can use an appsettings.json file.
From the command line, in the .csproj folder, I run
dotnet publish --self-contained true -r win-x64
. Inside my Debug folder, I see a netcoreapp2.1 folder and then the win-x64 folder. Inside that folder, I see the following:
publish -> folder
myapp.deps.json
myapp.dll
myapp.exe
myapp.pdb
myapp.runtimeconfig.dev.json
myapp.runtimeconfig.json
appsettings.json
hostfxr.dll
hostpolicy.dll
Am I supposed to copy just the files from this directory or do i have to copy the entire publish folder along with the files to my destination on a Windows Server? Or did I miss a switch to condense these items down further so movement from server to server is even simpler?
Copying just the files from the win-x64 directory was not enough. I needed to copy up the entire publish folder and run the application from that directory, otherwise error messages such as not being able to find a dependency would occur.
The dotnet publish command published into the projects bin/netcoreapp2.2/Debug/publish folder. Where netcoreapp2.2 presumably changes with the dotnet version and Debug changes with whatever configuration the -c parameter specifies.
For CI/CD purposes this is clearly undesirable. Alternatively one can pass -o to pass an explicit output path, but again, in a CI/CI environment this path should be inside the project folder structure, e.g. something like:
dotnet publish -o publish
But, because the publish command globs up all files, it picks up previous publish attempts and recursively stores them. This can be mitigated by either cleaning the publish folder explicitly, and/or adding a to the csproj for the project but now there is a dependency between the build script and the csproj: if the publish path is changed in the build scripts for any reason without a corresponding csproj update things break.
So, the least fragile option seems to be to use the default output path as thats automatically excluded from globbing, but how to remove the version & configuration sensitivity? Is there a particularly safe way to get dotnet to tell my CI/CD environment what its output path for build / publish is?
IMP: I do not have enough so reputation to add comment
refer : dotnet publish
you could use relative path with -o option and you may end up avoiding folder name with run-time, platform identification explicitly.
or why do not you consider using build command with publish profile where you can specify explicit path. but generally relative path is less error prone.
Hope this may help you !
My build completes with no errors, but it creates a randomly named zip file (s.zip) for the release step.
After the release step, I end up with that s.zip in inetpub/wwwroot/admin-tool/ folder. I'm almost there, but I want it to unzip and dump all the contents in here. This should be automatic, shouldn't it?
My dotnet publish looks like this:
and cause this to run, which is how I get the s.zip:
C:\Program Files\dotnet\dotnet.exe publish C:\agent\_work\3\s\Angular.AdminTool.csproj -c release --output C:\agent\_work\3\a\s
If I try to edit the -o argument and make it -o $(Build.ArtifactStagingDirectory)/admin-tool I will just end up with C:\agent\_work\3\a\admin-tool\s.zip
Is getting the name of my zip to be the same as the name of my web-site (admin-tool) the key to getting the zip to automatically extract in the release step?
In case it help others, I used the simple command line tools rather than the pre-canned "dotnet core" ones:
and for the Archive files task, be sure to include a hard-coded name for the zip to be used in the build process:
And for the release, in the "Deploy IIS App" task, be sure to include the full path for the zip file:
I also ran into this issue but solved it another way.
In my case I have a single project to build and deploy.
The $(Parameters.RestoreBuildProjects) value is set to a single project
MyProjectFolder/MyProject.csproj.
In the .Net Core Publish task, this value is used in the Path to Project(s) field.
Then I tick both the boxes for
I saved and queued this pipeline.
The zip file created seems to be derived from the name of the folder
so I ended up with a zip file in the artifact staging directory with the name of the project. Then the Publish Artifact task placed this zip file into the Artifact that is named in that task.
I'm using TeamCity for deployment process. For deploy i'm running MSbuild with this command line parameters:
/P:Configuration=Release
/P:DeployOnBuild=True
/P:DeployTarget=MSDeployPublish
/P:MsDeployServiceUrl=serviceUrl
/P:DeployIisAppPath=website
/P:AllowUntrustedCertificate=True
/P:MSDeployPublishMethod=WMSvc
/P:username=username
/P:Password=password
/P:SkipExtraFilesOnServer=True
/P:VisualStudioVersion=10.0
I have this parameter P:SkipExtraFilesOnServer set to true beacause i don't want MSbuild to delete some files which i have only on service enviroment, but don't have on my local project. But the problem is when i actually want to remove something from project (i have web application), i usually delete file from project, then i rebuild my app, and commit the changes in project file to source control, MSbuild leave this file on service because of this parameter.
MSbuild is using Release configuration, which i specified to use "all files in this project" to deploy. So the behaviour i want to implement:
TeamCity will leave all files which are not in my project reference list. (.csproj file).
TeamCity will delete files which were in .csproj but was deleted from it.
Please help me with that task.