I have a solution that currently builds nicely in TFS. I have just added a Sandcastle help File Builder project to it so that the help files can be generated. Now the solutions takes ages to build locally (it has also doubled the build time on the TFS Server).
In practice I'd be happy generating the help files once per day, or only when specifically requested as part of a build.
I tried creating a separate solution (for a new build) which included the Sandcastle project but I got a warning saying that the projects were already under source control.
What is the best way to configure TFS/the solution for this sort of situation? Can I have two builds that run on separate schedules and include/exclude certain projects in the solution?
You can create a new solution configuration that excludes building your help project. Then in your TFS build you can specify which configuration to build. You could have a CI build that doesn't include your help project, and then a nightly build that includes everything.
Related
I have an Azure Web application that I checked into TFS yesterday with no issues. Upon checking in, the resource manager will inject our nuget packages and deploy if it builds successfully.
I made a few changes (added a class) and checked in today. I received this error on the build:
Here's the quote to help the future search bots:
Exit code 1 returned from process: file name 'tf', arguments 'vc unshelve Gated_xxxxxx;****** /loginType:OAuth /login:.,******** /noprompt'.
I looked into the log response, to see if I get more detail, but it says the exact same thing. I have not changed my password or username.
How can I debug this to figure out the issue?
UPDATE
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
You can receive that error as well if you try to check in a file that is in a project that is not mapped in your build definition.
Let's say that you have a file named FileA.cs that is in a project named ProjectA.csproj. If you do changes in FileA.cs and this file is included in your changes, you need to map ProjectA.csproj in the Get source step of the build definition.
How do you exclude a project from the solution that is built by TFS?
I have:
Created a configuration and unticked build for the project I want to exclude.
Checked in the changes to the sln from above file to TFS.
Triggered a build under TFS with the build configuration I have added.
This doesn't work. When I build locally I can see that the build skips the project (I get "Project not selected to build for this solution configuration"). When I look at the TFS build log, I can confirm that the same configuration is used, and that the project gets built.
Looks like some sort of bug. Had the same issue.
I resolved it by manually removing the offending project from the solution file.
Find the project's GUID in the solution file - note it is the last GUID on the line, the first one seems to be the solution GUID.
Then find this project GUID and the various configurations for it in the GlobalSection(ProjectConfigurationPlatforms) section of the solution file and remove the ones you want.
Not ideal, but it works.
I am trying to build and Deploy our solution to Azure using TeamCity.
When I Build the azure solution (Web.Azure.ccproj) using TC, it always generates wrong file like Web.Azure.ccproj.cspkg in Release\app.publish folder. I am not understaing why it is generating a file like ccproj.cspkg. Rather it should have just generated Web.Azure.cspkg.
Note: when I try directly in command prompt (msbuild Web.Azure.ccproj /t:Publish) am able to see proper files generated.
Any reason why this is happening?
Thanks in Advance
I don't know why the generated files are different. However, if you are looking to deploy to Azure Cloud Services from TeamCity, maybe this link will help.
The linked post has a powershell script that will deploy the solution and you can include that as a build step in TeamCity. The script deals with having different Live and UAT environments etc, which you may not need.
For what it's worth, we're building the entire solution with a Visual Studio (.sln) runner and it builds the Azure projects fine.
Some of our parameters:
Targets: Rebuild
Configuration: Dev (Could be Stage or Release per our environments)
Command line parameters: /p:TargetProfile=Dev /P:Configuration=Dev
The last set of parameters are where I originally got stuck. We have profiles for Azure projects and configurations for the entire solution. We need both to get the right packages created.
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.
I have set up an automated build server - so far so good. Now I want to sort out dependencies. We have several DLL files that are included in many (unrelated) projects, and I want to set up CruiseControl.NET to first build our DLL files and then "check them in" other projects in SVN, so when they get built, they will always use the last version of DLL files.
Is something like that even possible? Is there a better way to keep dependencies sorted over several projects on many computers?
The way I do this is to have a project in cruise control for the common dll, it uses a source control trigger and builds whenever changes are checked in.
On the dependant project, I have the source control trigger, but also a project trigger so any checkin on the common.dll causes the common.dll to be rebuilt, which in turn triggers a build of the dependant project.