My project team currently use TFS 2012 as our VCS and TeamCity as our Continuous Integration Server.
In TFS, we have multiple Build Definitions set up for each project and this collection include some bespoke/customised build definitions. Each build definition is driven by a unique build process template. Consequently, within each project, we have two or more customised build process templates, along with the out-of-the-box templates which include the Default and Lab templates.
We use TeamCity as our Continuous Integration system and this connects to TFS as our version control system.
Within TeamCity, I have set up a Build Configuration and Build Step which has MSBuild as the Runner type. What I am desperate now to pass to MSBuild is the name of a specific Build Definition from the collection detailed above. This build defintion will be driven by one of my customised build process templates.......not the Default, Lab or any other proecess template.
In short, what I'm keen to achieve is the ability to set a Build Definition name as an MSBuild property. It doesn't necessarily have to be from within a TeamCity context. If anyone can advise how to even achieve this from the command line, that would be perfect for now.
Related
I am working on creating build from TFS 2012. I am able to generate build from TFS build templates but problem is that my website(ASPX pages), I am using after generating build is not creating separate dll for individual page.
But If I generate build from VS2012 I can generate build with separate assembly for individual pages.I can see this option when I click on publish and configure.
But how to have same option in Tfs Build templates ?? I have searched for MSbuild arguments and didn't find anything related to that
The best thing for us was... change to Jenkins and use make.
But seriously -> you can watch what changes in csproj/sln. Then most of options in this file are switches in MsBuild.
Check:
http://www.kunal-chowdhury.com/2013/05/how-to-auto-deploy-after-build-in-tfs.html
http://www.asp.net/web-forms/overview/deployment/configuring-team-foundation-server-for-web-deployment/configuring-team-foundation-server-for-web-deployment
The settings for "Create a separate assembly for each page and control" is saved in the publish profile with following format:
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<WDPMergeOption>CreateSeparateAssembly</WDPMergeOption>
So you can create a publish profile with this setting and specify the publish profile in TFS Build Definition.
I have a Visual Studio solution housing an Azure Cloud Service with the following projects:
CloudService
CloudServiceRole
Tests
Where the Tests project is a standard MSTest project that contains unit tests for the business logic in the CloudServiceRole project.
The code is stored in Visual Studio Online and I have hooked up the automated CI build deployment that Azure offers. When I check in code, my staging deployment of the cloud service is automatically updated. However, the Tests project is never even built during the CI builds! This, of course, means that no unit tests run during the build as the "run unit tests" part of the build process finds no assemblies with tests.
My goal is to change this so the tests project is built and all the unit tests executed.
Looking at the MSBuild arguments that the CI deployment process uses, it appears that only the CloudService:Publish target is executed. The CloudService project has no dependency on the Tests project so MSBuild never even builds the latter.
What I have tried
I cannot manually add a CloudService->Tests dependency because when I add dependencies on projects that are not Cloud Service Role projects, I get an error during build (The item "C:\a\src\MyProject\Tests\Tests.csproj" in item list "ProjectReferenceWithConfiguration" does not define a value for metadata "Name".) and I cannot add a CloudServiceRole->Tests dependency because that would make a circular dependency.
Instructing MSBuild to build the full solution by manually adding a /t:Build parameter resulted in yet another error: C:\a\bin\ServiceDefinition.csdef: Need to specify the physical directory for the virtual path 'Web/' of role Web.
Adding the Tests project as a separate build target, alongside the solution, results in the tests getting built! However, at the same time, it disables the Continuous Deployment functionality: More than one solution found. Continuous Deployment skipped.
Trying to make a fake Cloud Service Role project that references the Tests project but has zero instances configured results in a build error: WAT100: The following roles 'Tests.FakeRole' have an instance count of 0. Instance count of 0 is not supported in deployments to Microsoft Azure. Attempting to disable this validation results in a build error due to a defect in the Azure SDK.
You need to run a Build and a Publish separately. I ran into the same problem on my VSO (now VSTS) project and this fixed it. This happens because your cloud service doesn't depend on your unit test project.
1) Visual Studio Build (or MSBuild) action with arguments /t:Build (clean here)
2) Visual Studio Build (or MSBuild) action with arguments /t:Publish (do not clean here)
Note: I had to run these actions separately (not /Build;Publish) otherwise I got an error about the cloud service entry point.
Pieced this together from this question and from here and here.
One workaround that appears to bring results is to add a pre-MSBuild script to the build definition and explicitly build the Tests project in that script.
:: This is used as a pre-build script in Continuous Deployment builds because on their own, they do not build the Tests project.
"c:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" %~dp0\..\..\Tests\Tests.csproj /t:Build /p:Configuration=Debug;Platform=AnyCPU;OutDir="%~dp0\..\..\..\..\bin\\"
It appears to do the job, although I am not sure what side-effects I should be aware of. My main concern is that the binaries from this build go into the same directory as the binaries from the Cloud Service build - is there perhaps some possibility of conflict here?
I have created a new release build in TFS 2013 and I want to configure it to perform a web deploy. I am not sure how to specify which project to deploy. Ideally I want to web deploy 2 web projects to IIS on the server (both projects will have a corresponding website in IIS), but if it not possible I can live with having 2 separate builds. I have added the following setings to MSBuild Arguments (in Advanced section of the process) in build definition:
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:Configuration=Release
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath="<IISSIteName>"
/p:MsDeployServiceUrl=https://<my server IP>/MsDeploy.axd
/p:AllowUntrustedCertificate=True
/p:username=Administrator
/p:password=xxxxx
I can see it is conneting fine, but it doesn't publish anything. I also tried to specify my web project in Items to build section, but that didn't help. What am I missing? Must be some setting.
If I have understood correctly, you have 2 web projects in the solution and you want to create build definition to deploy them as two different web sites on IIS server.
There could be better ways of handling this but what I have done in my project is to have two separate build definitions for 2 web projects.
For each build definition, specify the csporj file of the project to build under “items to build” section of the process tab.
Even after doing this TFS may not publish the web site at desired location. It may show success but files won’t be copied to the destination location.
In this case, check the log messages of the build activity. If you find a warning similar to this:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (484, 9): warning: The OutputPath property is not set for project ProjectName.csproj'.
Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Release' Platform='Any CPU'
Then it may be related to build configuration. If you are using “Any CPU” as build configuration then change it to “AnyCPU” (remove space).
Refer following link for the detailed explanation:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/0bb277ec-a08c-4795-88f0-3207654e2560/the-outputpath-property-is-not-set-for-project-xxxxxbtproj-please-check-to-make-sure-that-you?forum=tfsbuild
Amey
I have a Visual Studio 2012 solution containing a Windows service project and a web application project.
I want Team City (version 8.0.3) to create two zip files (one for the service and one for the web app) that I will deploy manually.
Should I create a build step to build the entire solution, followed by a build step to publish the Windows service and a build step to publish the web site (via publish profiles). Then use Artifact paths in General Settings to zip up these two published folders?
Or should I have just one build step to build the solution and then use the Artifact paths to create the two zip files?
Or is there a better way than either of the above?
You have to ask yourself if these two projects are linked and in which manner they should be built together.
My feeling is : if your projects are in the same solution, they are linked in some ways and have to be built together.
Then, you should build your solution (sln) and not projects (*proj).
Application organization
Generally, your build server should not redefine -too much- the way your applications are organized. You should always use your plateform application descriptor to build your applications.
In case of .NET and Visual Studio, the application descriptor is your solution (sln). It defines the needs and how your application have to be built.
If your project have to be built separately, they should be in differents solution unless you prefer to create specific solution configuration (in addition to Release & Debug).
Anyway, the solution is still the build entry point.
TeamCity
Speaking about TeamCity, different and standalone applications should be in separate build configurations.
The pure build (code compilation) should be in one build step and you should not use too much code compilation runners in one build configuration.
Your build configurations should reflect your applications farm logic.
If you need to link them in some ways which are related to packaging for example, you can link your build configurations through snapshot or artifact dependency.
The solution I'm building contains a whole lot of projects. One of them, Web, is the front end web site, and is being built and deployed to the QA server by default when a QA build is run. I have another project, called Service (and an associated Service.TestHarness), which I'd like to deploy to the same server as part of the same build. Where in the build's settings, or in the BuildProcessTemplate, can I configure this?
I've tried creating a deployment package via Visual Studio and importing this manually in IIS on the QA server, but got the error "This access control list is not in canonical form and therefore cannot be modified" which I haven't been able to resolve either.
Current build settings:
DeploymentApplicationPath = QA server's address
DeploymentComputer = QA server's name
DeploymentPackageSource = Web.zip
PerformDeploy = true
PerformDeploymentBackup = true
There's four ways you can do this:
1) pass everything as parameters to msbuild using the Team Build Process settings This is the least flexible and doesn't work well if you have multiple deployment projects as you currently have
2) create a custom target and a set of conditions in the project files and let msbuild handle the deployment, don't configure anything in the Build Definition itself (other than maybe setting a property on the msbuild command line arguments to enable a specific deployment)
3) use the Solution Configuration to create a specific solution configuration for each deployment you want to do and when specifying the solution/configuration to build in the build definition, enter your own custom configuration
4) let Team Build handle the build and use something like TFS Deployer or Powershell to handle the actual deployment of the packages.