I know you can have post build command line events... executing a batch file, etc. What I can't find is any information about whether or not there is a post DEPLOY version of this.
I build my solution all the time, but I only deploy once in a while. There are certain things I do manually, which I would prefer to do automatically via a batch file after a successful deploy.
Can this be done?
Found my answer here:
http://msdn.microsoft.com/en-us/library/t9883dzc.aspx#1
Sadly, there are issues with this solution which I posted in a separate thread which I can not seem to locate at the moment... facepalm
Tasks provide the code that runs during the build process. Tasks are contained in targets. A library of typical tasks is included with MSBuild, and you can also create your own tasks. For more information about the library of tasks that are included with MSBuild, see Task reference.
Tasks
Examples of tasks include Copy, which copies one or more files, MakeDir, which creates a directory, and Csc, which compiles Visual C# source code files. Each task is implemented as a .NET class that implements the ITask interface, which is defined in the Microsoft.Build.Framework.dll assembly.
There are two approaches you can use when implementing a task:
Implement the ITask interface directly.
Derive your class from the helper class, Task, which is defined in the Microsoft.Build.Utilities.dll assembly. Task implements ITask and provides default implementations of some ITask members. Additionally, logging is easier.
In both cases, you must add to your class a method named Execute, which is the method that is called when the task runs. This method takes no parameters and returns a Boolean value: true if the task succeeded or false if it failed. The following example shows a task that performs no action and returns true.
There may be a better way to do this, and I know the following method is less than ideal
For the rare cases you deploy, you could just write an external msbuild script that builds your project, deploys the code, and then run yours batch script.
Using the MSBuild Task to build another MSBuild project:
http://msdn.microsoft.com/en-us/library/z7f65y0d.aspx
Using MSDeploy as Build Task:
http://www.compsoft.co.uk/Blog/2009/12/using-msdeploy-as-build-task-in-tfs.html
Invoking batch files from MSBuild:
http://www.danielfortunov.com/software/$daniel_fortunovs_adventures_in_software_development/2009/05/21/invoking_batch_files_from_msbuild
Related
I was wondering if someone would be able to explain what Build runners do and also what i would need to use for just a static HTML / CSS / JS site, or even an already compiled .NET site.
I will be hooking up each project to its equiv SVN and grabbing updates from there, but not 100% sure what the build runners do or which i should use as technically i dont need to build the site.
Sorry it may be too much to answer but i am just struggling to get my head round Team City
Thank you
Build runners are just a process for a specific task, for example the MSBuild runner is set up by putting information into specific fields which it then uses to call MSBuild on the target build agent. You could just as easily use the Command Line runner and build up the MSBuild run command manually.
Build runner is a part of TeamCity that allows integration with a
specific build tool (Ant, MSBuild, Command line, etc.). In a build
configuration, the build runner defines how to run a build and report
its results. Each build runner has two parts:
server-side settings that are configured through the web UI
agent-side part that executes a build on agent
You need to choose your runner depending on the task that you want to do and the technology that you have wrapped your project in. If there is no runner for your specific task then you can use the lowest common denominator which would be the Command Line runner.
The way I approach this would be to see how I can achieve what I want to from my own environment be that calling a rake, MSBuild or batch file. I then see how I can then apply that to a tool. Do not create a process around a tool but choose a tool that fits to your process.
I wonder if I could get some feedback from people on how to best approach building of Visual Studio solutions.
My core requirements would be to ensure that any code/tests run against the correct resources, in particular, database schema and sample data.
I've tried various ways to do this with mixed degrees of success. Currently, I …
Create a class library *.Installation.dll, which creates, configures
and populates the database, etc.
Have a class library *.Build.dll
which has an MSBuild task that takes parameters from the csproj file
and passes to the Installation.dll.
These sit within their own solution. Say MyApp.Build.sln. I maintain this separately from my main solution, to prevent file locking issues.
In my main solution, say MyApp.sln …
Then, my test projects invoke the MSBuild task to create test environments for integration testing including database and sample test data.
And my Web/Windows front end projects invoke the MSBuild to create runnable environments for test users/my manual testing
So, I am using MSBuild to create customisable builds/environments for testing/running. Additionally, I can wrap the Installation.dll into a configuration/setup tool to automate the installation for the user when the time comes to install.
Is this too complex a scenario? I'm worried I've over engineered this and overlooked something. It works well, but is bound by a lot of meta programming (eg. the database build code, configuration, build task, etc.) that is not directly involved with tangible, chargeable work.
I have SubVersion and TeamCity. I'd like to enable a CI build ultimately that is invokes on a daily/commit build trigger. Or can I use TeamCity in such a way to avoid rebuilding the database/etc. every build?
Thanks for any insight.
I am tasked to improve quality and implement TeamCity for continuous integration. My experience with TeamCity is very limited - I use mostly TFS myself and have some experience with CC.NET.
A lot should happen within a build process... actually the build is already pushed into three different configurations that will run one after the next.
My main problem is that in each of those I actually would need to start multiple runners. For example, the first build step shall consist of:
The generation of new AssemblyInfo.cs files for consistent in assembly numbering
The actual compilation
A partial unit test run (all tests that run fast and check core functionality)
An FxCop run
A StyleCop run
The current version of TeamCity only allows to configure one runner ... which leaves me stuck with a lot of things.
How you would approach this? My current idea is going towards using the MsBuild runner for everything and basically start my own MsBuild based script which then does all the things, pretty much the way that TFS handles it (and the same way i did things back in the cc.net way with my own Nant build script).
On a further problem the question is how to present statistical information, for example from unit tests running in different stages (build configurations). We have some further down that take some time to run and want that to run in a 2nd or 3rd step (the latest for example testing database generation code which, including loading base data, takes about 15+ minutes to run). OTOH we would really like test results to be somehow consolidated.
Anyone any ideas?
Thanks.
TeamCity 6.0 allows multiple build steps for a single build configuration. Isn't it what you're looking for?
You'll need to script this out, at least parts of it. TeamCity provides some nice UI based config for some of your needs, but not all. Here's my suggestion:
Create an msbuild script to handle your first two bullet points, AssemblyInfo generation and compilation. Configure the msbuild runner to run your script, and to run your tests. Collect your assemblies as artifacts.
Create a second build configuration for FxCop. Trigger it from the first build. Give it an 'artifact dependency' on the first build, which is how it gets a hold of your dlls.
For StyleCop, TC doesn't support it out of the box like it does FxCop. Add it to your msbuild script manually, and have it produce an html report (which TeamCity can then display).
You need to take a look at the Dependencies functionality in the TeamCity. This feature allows you to create a sequence of build configurations. In other words, you need to create a build configuration for each step and then link all them as dependencies.
For consolidating test results please take a loot at the Artifact Dependencies. It might help.
I am using CruiseControl.NET to build a C# project. I am using an msbuild task to achieve this. I want to build the project in both Debug and Release mode irrespective of whether either mode fails. But If I put these as two msbuild tasks in the 'tasks' section of the project and if the first task fails, the second is not executed.
I could define them as two projects, but I want the Label to be synchronized across both the projects. Is there a way to do this?
One solution I have is make the 'Release' config project to trigger a build whenever the 'Debug' config project is built. But in that case, If someone force builds the 'Debug' config project then, the labels will get out of sync.
To achieve what you want, I think you will have to use a custom task to call MSBUILD from a CMD file and pass the debug/release mode into MSBUILD via cmd line args.
Use multiple tasks for the project.
Note: See CC.NET preprocessor if you want to reduce tags duplication.
To increase the automated part of our build/release process, I would like to integrate some custom tasks in our visual studio projects. What's the best way to organize such solutions? The main problem is: If I add the project implementing the tasks to the solution, the tasks are cached by the visual studio instance. So a rebuild does not work, because the output assemblies of the task project cannot be overwritten.
I can put the task in a separate solution. Seems to be the best (only?) option, but I don't like to maintain two solutions. This makes continous integration more complicated.
Any hints? How do you manage solutions having project specific custom build tasks?
If the custom build tasks refer to some documents included in the solution, then you can make a custom build rules document, refer it in your solution and specify the custom build name for each document in the properties (this will spare you on writing command, dependencies and everything for each document, if the rule is specified correctly using the macros like $(InputPath), etc.)
If the custom build tasks refer to some operations that are not related to documents in solution, you can have them specified as commands in the post build event of the project in the solution that needs it. Another alternative can be to add a new, dummy project in the solution that will have only this post build event, dependent on all the other projects (so the post build tasks will be called only after all the other projects were built).