We have a build configuration runner type of Visual Studio.sln setup to read from a csproj with a Publish Profile (/P:PublishProfile=%env.Configuration%.pubxml) to create a Web Deploy Package that we then use in another build step to deploy using MSDeploy.
On TeamCity the Targets options states that
Enter targets separated by space or semicolon. Build, Rebuild, Clean, Publish targets are supported by default
Looking at some other StackOverflow threads, it mentions that using WebPublish as a target works but doesn't say why it works.
TeamCity: How tell MSBuild to take into account publish profile parameters?
I am not sure what the difference between a "Publish" and a "WebPublish" is.
The "Publish" Visual Studio target uses WebDeploy/WebPublish under the hood to do its publishing.
Related
I am using TFS2010 and MSBuild to integrate a windows azure cloud solution to the CI.
To create the required 2 files for deployment I added in the "MSBuild Arguments" the /t:Publish
Here is the configuration I use in TFS to build the packages:
Problem is : if I remove all arguments the tests are built correctly but no azure package is built as seen on the build results:
Tho if I put the parameters the package is there but the test are not run :
Is there a way to have both ?
I have managed to resolve this issue in my tfs build (TFS 2013). I am setting my MSBuild Argument target as /t:Publish;Build
Basically, during Publish target the unit test project is not being built. The 'Build' target builds the unit test project and my tests are executed. I also noted that the sequence of 'Publish' and then 'Build' was important. Setting 'Build' target before 'Publish' raised a few errors for my build.
I had discussion about your problem with TFS Team and I was told that as of now with TFS2010 this functionality is not yet fully supported however such functionality is in they radar and could be part of future TFS releases.
Because you are using TFS 2010, here are a few pointers that could help:
Building and Deploying Windows Azure Projects using MSBuild and TFS 2010
How-To: Deploy to Windows Azure from TFS Build using DeployToAzure
This problem still exists in TFS 2013.
I work around it by creating a Makefile project in the solution, and add a new 'Makefile' file with content as
all:
msbuild $(SolutionDir)AzureProject\AzureProject.ccproj /p:TargetProfile=Cloud /t:Publish /p:Configuration=$(Configuration) /p:PublishDir=$(OutDir)
And set build command line in project property page
nmake /E SolutionDir=$(SolutionDir) /E Configuration=$(Configuration) /E OutDir=$(OutDir)
I have an WCF project that if i use the Visual Studio option "Publish" gets published fine.
But if I use the MSBuild parameter DeployOnBuild it does not get published correctly. I'm getting an "Could not load type" error, and all of de dlls are there.
I using the MSBuild in a Build Definition in order to have a Continuous Integration Build.
The build parameters I'm using are:
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://host/msdeployagentservice
/p:username=#####
/p:password=****
My main problem with this scenario is that the build targets are the same, and the build definition actualy publishes the files, but somehow they are not the same.
Any insights ???
I dont like to answer my on question, but since it may help someone else is the cause of the problem.
One of the projects had a post-build command to copy the resulting
dll to another project specific directory (its not a reference
because it using dependency injection in runtime).
The dlls did not get checked in to TFS because they are not checkout automaticaly
The
Continuous Integration Build fetches the sources from TFS and the dlls are out of sync
The solution was to checkout the dlls before the build so that the checkin updates them
I have been trying to achieve ClickOnce deployment using MSBuild scripts, but I could not find any resource on how to copy the files after generating the manifests.
Since we need to script baby steps in case of mannual deployment, which Visual Studio does for us if we use the wizard, I'm not able to do it, since I'm new to both MSBuild and ClickOnce.
Is there a resource where I can find detailed information on how to script the entire ClickOnce deployment for multiple environments, increment version number using TeamCity's BUILD_NUMBER and sign the assemblies?
All that you see Visual Studio doing is done by MSBuild (except creating/updating the "publish.html"). This is true for any environment, if you meant configuration. To publish using MSBuild, all I do is execute the following at Command Line:
%SystemRoot%\Microsoft.Net\Framework\v3.5\msbuild <myProjectName> /p:Configuration=Debug; /t:publish
This gives me a Development environment Build (we use the default Debug configuration for Dev). For QA I just replace the "Debug" part in the above command to "Release".
Here's what I want to do:
Build an existing .csproj that targets "Package"
Publish the package with MSDeploy to an IIS 6 server
This is for a TeamCity build and release that I'm trying to configure in a single step. I could create a custom build file but I'm trying to tackle this without adding any additional configurations to the app.
There are a lot of examples around of MSBuild parameters which can do this publishing via WMSVC - here's a great one - but that's not going to play ball with IIS 6. Are there equivalent params which can be used when there is a dependency on MsDepSvc? Is this even possible or am I left with either a custom build script or a package build followed by a publish build?
You can modify an existing .csproj file to add any additional target needed (it's just an MSBuild file) and publishing to an IIS6 server can be done via different MSDeploy providers (webServer60, metaKey, or contentPath via a share).
While this would be possible to do by adding a Target in the MSBuild of your project, I'd recommend that you split these two activities out into two separate targets. By splitting them into two separate targets you can still call them together msbuild /t:Package;Deploy but you can also call them independently.
This would allow you to create a deployment package and have TeamCity include it as an artifact of the build. You could then download this package from TeamCity and deploy it to any server independently, even if you deployed it automatically. If TeamCity also creates your release builds, you know have your production deployment
Can someone point out any tutorials that help build windows services using msbuild.
Requirements :
- Should not use the csproj file
- Output should be the same as the publish option in Visual Studio
Updated question:
We have a project of type windows service in our solution. In this windows service, we are referencing a couple of libraries that reside on a different system (one of them is not strongly named). This solution also contains other class libraries and websites/web-apps.
I am trying to write a custom build that outputs a xcopy deployable version of the website, and a deployable version of the windows service. When I say windows service, it shows up on the Control Panel -> Services MMC.
The website build was easy via msbuild...however I am struggling with the windows service build. Until now, my fellow developers were using the right-click on the project file ,and click publish to publish the windows service. This generates a setup.exe file that helps the admins to deploy the service.
So, now here is my question:
I want to use msbuild to build my windows service.
I do not want to directly use the .csproj file in conjunction with msbuild to build the service.
The output my build file generates should match the output from the "publish" option (*the publish option generates a setup.exe file*)
In general, "the publish option" under the covers just runs a build with /t:Publish, i.e., it triggers a different target to the normal default 'Build' one.
Can you tell us more of what you are looking for, as opposed to not looking for?
Are you looking to generate an MSI? (If so, you definitely won't be using MSBuild if you're using the built-in .vdproj system - but be careful - this means having to put VS on a build server)