From a CI-CD prospective, i am trying to find what are the folder & files (bin, obj, .dll etc) that are published to an IIS server while using the msbuild.exe with the publish option. I am not a .NET developer. What governs which files/folders to be pushed to the nodes while publishing after the build?
My application is a fairly simple one. The publish (or the deployment) is more or less a bunch of file copies from the CI server to the IIS nodes. The command used for the build and publish is
bat '"C:\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=DEV /t:Rebuild /p:DeployOnBuild=true /p:PublishProfile=DEV /m:4 src/myapp.sln'
I am trying to create & place the required output folder & files to an file repository after the msbuild process (before publishing). Then i will use these files to subsequent environments (with their web config files). Thus avoid the rebuilding for each environments.
In this context MSBuild is actually using WebDeploy under the covers to deploy the application. Basically MSBuild compiles any C# OR VB files in the web application project and creates DLLs in the bin directory, then WebDeploy packages up any web server files (HTML/CSS/JS/etc) and the bin folder to the target.
The following post describes how WebDeploy works.
https://dotnetcatch.com/2016/02/25/the-anatomy-of-a-webdeploy-package/
Related
I'm attempting to create a build that will build my solution, apply web.config transforms as necessary and finally copy desired output (a built web api project) to the artifacts area of the build.
I'm using the Deployment...Azure WebApp Template with the Azure App Service Deploy step disabled (as we're in the middle of a move to Azure), with the following build arguments in the build step:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\" /p:AutoParameterizationWebConfigConnectionStrings=False
All works as expected, apart from the structure of the resulting zip file, which has the following structure:
{ZipFileName}{ProjectName\Content\C_C\a\1\s\Api{ProjectName\obj\Release\Package\PackageTmp...{BuildContent}
I'd like the content to be at the root of the published zip file if possible. Is the best way to manipulate the content of $(build.artifactstagingdirectory) using Powershell or a number of the other built in build tasks?
You don’t need to worry about it, because it won’t keep the folder structure (Just the files and folders in PackageTmp folder) after deploy to web server (e.g. IIS, Azure Web App)
If you still need to just include the files in PackageTmp folder, you can add build step to archive file to zip file through Archive Files step.
For Visual Studio Build step, specify /p:DeployOnBuild=true to MSBuild Arguments.
I'm developing an ASP.NET Core 1.0 application which I deploy to a Linux machine using Docker.
In my CI pipeline I'm publishing the project using dnu publish, then I build the docker image with docker build.
I have a static binary file that I need to use in my docker image. (It's a hotfix which I need to copy into the coreclr runtime directory.) I want to be able to access that file with a command from my Dockerfile.
What is the idiomatic, reliable way to make that file get copied into the output directory when I'm doing dnu publish? What I'm currently doing - because I couldn't find a better solution - is adding it to wwwroot, so it gets copied into wwwroot in the output folder.
However, I don't want that file to be publicly accessible, it would be much better to make it end up in approot.
The approaches I found on SO and tried, but are not working:
Including the file in the project.json as "contentFiles": [ "mylib.so" ]. If I do this, I get the following error during the dnx build:
Error: The process cannot access the file 'C:\myapp\src\myapp.web\mylib.so' because it is being used by another process.
I tried to experiment with creating a custom postBuild script (found the suggestion here: New .NET "project.json" project, copying pre-built native .dlls to the output directory), but I can't figure out where to copy the file, since I have different CI pipelines publishing the same project using different publish output directories, so I cannot hardcode the directory path into my project.json.
Or is there a way to copy it into the build directory, which will be picked up by dnu publish regardless of the output directory of publish?
We're pretty new to TeamCity at work. We have a build & deployment pckage setup which is using MSBuild/MSDeploy to ship changes to our web servers. However, we have a few issues (apologies for putting a few questions on the same post). For clarification our solutions looks like so:
Project Folder
WebApp (includes .csproj file. Includes a folder called "media" - this folder is not in SVN)
Libraries (includes referenced assemblies)
Our issues:
There is a specific folder within the Libraries folder that must be copied into the bin directory after build (because of an assembly redirect). We have always used a PostBuild event, however this doesnt work in TeamCity.
The folder "media" within the WebApp folder is not included in SVN. When the TeamCity package is executed it deletes this folder. I would like to prevent TeamCity from deleting just this folder.
When we run the TeamCity task, we get an ERROR_FILE_IN_USE error for one of the files teamcity is trying to delete during the sync task. I have read about using the app_offline.htm file to combat this - but quite how Im not sure.
I'm going to guess that some of these settings can be command line parameters in the msbuild job - I think it would be better to store these in the csproj file rather than just in teamcity if it is possible?
thanks in advance
Al
A few questions on the information provided
Can you clarify what you mean by post-build command doesnt work? Does it fail or does it just not do what you expect?
How have you setup your post-build command? does it reference specific filepaths? TeamCity executes MSBuild in the same was as you could from the command line or from visual studio.
Regarding the MSDeploy folder issue, you can configure MSDeploy with a Skip Action, here's a link to another post describing how to do this
Prevent MSDeploy (selectively) from deleting folders on target IIS server
Because MSDeploy is trying to deploy into a folder being used by IIS you are also seeing the file locking issue. There are two solutions
1. Add a teamcity step to stop IIS (using PowerShell) before deploying. This will cause downtime.
2. Deploy to a different folder and then switch IIS to point to your new folder. This is a much better solution as you also have roll back.
A much easier solution to all of this is to use a Deployment Tool such as Octopus Deploy to deploy your application. You can learn more about Octopus Deploy at http://octopusdeploy.com/
I am trying to use MSDeploy to deploy an MVC project to the server using TeamCity. When I do this on my computer in powershell, using the following command:
msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer /p:VisualStudioVersion=11.0
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true
It builds the project and deploys it to the server (info defined in the DevServer publish profile) perfectly. The output shows an MSDeployPublish section at the end, in which I see text like Starting Web deployment task from source... and then with rows telling me what files are updated, etc.
When I run this on TeamCity, using an MSBuild Build step, on the same file, with the same parameters (from the same working directory) it builds the project but does not publish it. Instead it has the regular output from a build process (CoreCompile, _CopyFilesMarkedCopyLocal, GetCopyToOutputDirectoryItems, CopyFilesToOutputDirectory) but then does not actually go and publish anything.
What changes to I need to make to the setup in TeamCity to get it to publish deploy in the same way that it works using MSBuild from my computer?
(TeamCity 7.1, MSBuild 4.0, WebDeploy 3.0, Visual Studio 12, IIS 7. Related to my previous question)
We do our WebDeploys with a TeamCity MSBuild step configured as follows:
Build File Path: Server.csproj
Command Line Parameters:
/p:Configuration=%configuration%
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://%web.deploy.server%:8172/MsDeploy.axd
/p:DeployIisAppPath=%web.deploy.site%
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM
We use integrated authentication; change as necessary to fit your scheme. The value of this, I think, is that it builds everything from scratch and doesn't rely on a pre-built package. From the gist you posted I noticed that you do some DB publishing, we don't use WebDeploy for that so I can't offer any guidance there. Hope this helps.
I use MSBuild.exe to package to zip, and MSdeploy.exe to deploy in separate steps.
To deploy the package.zip file on the command line:
"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync
-source:package="C:\Build\MyAppName.Debug.zip"
-dest:auto,wmsvc=webservername,username=webdeploy,password=*******
-allowUntrusted=true
This command is also worth explaining in detail:
-verb:sync : makes the web site sync from the source to the destination
-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package
-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).
You can modify parameters based on your configuration. I like it this way because with separate steps, its easier to debug problems.
Use TeamCity build step and the command line runner.
Update:
If you want an example of how to build the ZIP package using MSBuild, try something like this:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyWebApp/MyWebApp/MyWebApp.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyWebApp.Debug.zip"
This should work the same on your local PC as well as on the CI server.
Here are the config settings that finally worked for me:
/p:Configuration=CONFIG-NAME
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=http://SITE-URL/MsDeployAgentService
/p:username="USERNAME"
/p:password=PASSWORD
/p:AllowUntrustedCertificate=True
/P:CreatePackageOnPublish=True
/p:DeployIisAppPath=SITE-URL
/p:MSDeployPublishMethod=RemoteAgent
/p:IgnoreDeployManagedRuntimeVersion=True
I had exactly the same issue! I've posted the solution I used over at: MsBuild not finding publish profile
Basics were:
Install the Azure SDK 1.8 on the build server
Force the /P:PublishProfileRootFolder value to ensure MSBuild can locate the publish profile
Ensure that you have the Microsoft Web Developer Tools feature installed for Visual Studio. This was missing on my build agent but once I added it the TeamCity build worked just fine.
This can happen when the build target paths are missing from your MSBuild directory. Instead of trying to get those to line up on every developer machine, install the targets from the Nuget. That way it will always be the same for everyone, regardless of how their machine is setup.
I have a web application that I am trying to deploy and have the web.config file parametrised.
I can build the package by running
msbuild myproj.csproj /T:package
now when it produces the package, i get a file in the directory.
Archive.SetParameters.Xml
This file has Parameters in it that if I change they would end up in the deployed package. My Question is, how can i define more parameters so that when I build the project it has my extra parameters in the file.
I belive i could do it using MSDeploy -declareParam But how would I do this from MSBuild? or the .csproj file.
My end goal is to have a parametrised Web.config file for deployment into multiple environments.
Ok so turns out this is fairly easy, after some significant googling eventually found this post
http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html
VS 2010 makes your life easier by allowing you to simply drop the
Parameters file in the root of your web project and if a file with the
name Parameters.xml is found in the root of your project it passes it
to Web Deploy which then parameterizes your web…