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.
Related
When you publish a .NET Core self-contained app right now, your exe is in the middle of a few dozen .NET Core runtime libraries, along with all the Nuget packages.
MyApp/
--ct/
--de/
--es/
...
--zh-Hant/
--Accessibility.dll
--api-ms-win-core-console.dll
... A dozen other .dlls
--MyApp.dll
--MyApp.exe
... Even more .dlls
I would like to set up publish so that these files are organized, like such
MyApp/
--netcoreapp3.0/
--nuget/
--MyApp.dll
--MyApp.exe
or even
MyApp.exe
MyApp/
--netcoreapp3.0/
--nuget/
--MyApp.dll
Alternatively, maybe there could be a way to change the directory of framework libraries in the .csproj <TargetFramework> tag? That way, I could use the framework-dependent publishing option and remove all the duplicate files.
If there is no constraint to use the framework-dependent publishing option you can publish with the PublishSingleFile option being true.
Your publish command would be
dotnet publish -c Release -r win-x64 /p:PublishSingleFile=true
Then in your publish folder you will find a "cleaner" result of an executable file, and some configuration files only (like appsettings.json or web.config). No nuget or runtime dlls.
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.
Why is my ApplicationInsights.config file not being included in the build package when I build on the server. I am using Azure DevOps as the build server and I am using a standard Visual Studio build task. This is the MSBuild arguments
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\" /p:SkipPostSharp=True /p:AutoParameterizationWebConfigConnectionStrings=False
This could be happening due to an incorrect App Publish profile. Your application's local Publish profile in VS should ideally look like this:
CustomProfile.pubcxml.user file
This should include:
<File Include="ApplicationInsights.config">
<publishTime>11/06/2018 12:27:58</publishTime>
</File>
ProjectName.csproj file
Unload your project (Right click on Project Name -> Unload Project) and edit the project's .csproj file (Right click on Project Name -> Edit .csproj)
<Content Include="ApplicationInsights.config">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
Publish Output
The above mentioned settings would ensure that the ApplicationInsights.config file is included as part of your Publish artifacts, which would look as shown in the attached screenshot.
If this is not what you see, please try creating a new Publish profile afresh and tweak it to get the expected configuration. Post verifying this, I did try to publish the same using the MSBuild task in Azure DevOps and was able to see ApplicationInsights.config as part of the output build artifacts, supplying the same parameters that you mentioned in the question above:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\" /p:SkipPostSharp=True /p:AutoParameterizationWebConfigConnectionStrings=False
Hope this helps!
Most likely, ApplicationInsights.config file is set to "Copy Never" in the properties / project file. Changing this to "Copy if Newer" or "Copy Always" should do the trick.
This code base has been inherited from another team. It turns out that they modified the project file to add a new MSBuild Targets file. These additional tasks were responsible for ensuring the config file was not added in to the output.
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 use the following command to deploy an ASP.Net core 1.0 MVC application.
dnu publish --runtime active --no-source -o e:\website\zigs
Issue: Some image files and JavaScript files in the VS2015 project
wwwroot 'images' and 'js' folders are not deployed to the
'e:\website\zigs\wwwroot\' images and ..js sub-folders.
The missing files are present in the VS2015 project and all works correctly in the development environment.
I currently use dnvm version 1.0.0-rct1-15540 and dnx-clr-win-x86.1.0.0-rc1-update2
Is there something I need to do to flag the files to be included in the deployment?
(I can get around it by just manually deploying the missing files, but I would need to have the files deployed automatically by the build/deployment server in the future.)
Thank you.
Solved! Make sure the target root folder does not contain any folders/files to do with the deployment before running the dnu publish command!