Showing posts with label msbuild. Show all posts
Showing posts with label msbuild. Show all posts

Monday, September 9

1111 MSTestRunner Users

I'm happy to see today that MSTestRunner Jenkins Plugin I wrote and use every day has pass the 1K users this month.

Many thanks to all the users and specially to those who left comments explain how to improve it.

Have fun using it and keep on testing.

Saturday, June 29

ProjectConfigTransformFileName - Web.Config Transformation

The Need
We start to use AppHarbor .NET PaaS to deploy our web-application.
Because we still have another instance of the same application running in shared hosting provider we needed a way to support both deployment from the same code-base.

The Problem
Visual Studio support different configuration for project out-of-the-box. The two default configurations are Debug and Release. In web projects you also have a matching web.config transformation file for each configuration, that is web.debug.config and web.release.config. Each of them contain only the parts that need to change for each configuration.
I want to have a third web.config transformation with AppHarbor specific configuration without having a new project configuration.
Visual Studio does not support this setup, but MSBuild does.

Why?
I choose not to add a new project configuration, even though it's the route Visual Studio takes you, because it will mean that our team will have one more thing to learn, one more thing to maintain and one more thing that can go wrong.

The Solution
After some digging into Microsoft.Web.Publishing.targets that is located in C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web in my dev machine I found the MSBuild variable name ProjectConfigTransformFileName.
Microsoft did a great job of convention over configuration with this script. The convention is to use the web.config transformation name web.[configuration].config but if you specify ProjectConfigTransformFileName it will use that one over the convention.

Since we use Jenkins as CI server we simply pass one more parameter to the MSBuild /p:ProjectConfigTransformFileName=web.release.appharbor.config and now everything works exactly the same beside the fact we use AppHarbor web.config transformation.

Wednesday, June 26

Portable Class Library on Jenkins CI

Like any good developer I try to keep projects organized. Today we finish the first release of our globalization library which we put in a Portable Class Library (PCL) so it will be easy to use it in different projects.

When Jenkins pull the work and start to build it it compline about build errors we did not see on our development machines.

The first error was error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Portable\v4.0\Microsoft.Portable.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

We did not install Visual Studio on our Jenkins server so the same way I handle previous problems with target fiels I start by simply copy the target files from my development machine to Jenkins.
This didn't solve the problem just led me to the next problem: error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)

Little digging in the on the web and I found that this time Microsoft make our life easy and have a tool to install PCL tools on build machines.

Cross-Platform Development with the .NET Framework is the title of the document inside the MSDN website. There you can read all about cross-platform development for .NET and specifically download the Portable Library Tools and install it with the switch /buildmachine

There you go, PCL on your Jenkins Build machine made easy.

Monday, June 10

Continuous Delivery of ASP MVC with Jenkins and MSDeploy

We have been using Jenkins to deploy our web application for a while using continuous deployment, that is we used to push our changes into our git repository, go into Jenkins and run the deployment job.
Last month after successfully working in this way we decide we can trust ourselves and our systems and move to continuous deployment (or more accurately continuous release).

The ingredients

We divide the deployment process into several jobs and connect them all together using CloudBee Build Flow plugin.

The Jobs
  1. build & test - This job build and test both debug and release configuration of our web application
  2. deploy - This job deploy our web application using MSDeploy
  3. end-to-end-tests - This job run end-to-end test on our production web application using Watir web testing framework
  4. continuous delivery - This job is a build flow job that simply run jobs 1,2,3 in order. If anything goes wrong it notify us.
What's still missing?
  1. Staging - We are working on deploy our web application into staging environment and run the end-to-end test on it. This does not guaranty success but it does catch errors. 
In the next posts I'll go into details about each of the jobs.

Monday, February 20

Upload files to FTP with MSBuild

So, you are looking for a way to upload files to an FTP site using MSBuild tool.
Me and my colleague Lev try to do exactly that, we search and found msbuildtasks.tigris.org which should work, but didn't. We also found MSBuild Extension Pack which worked, but lack the proper abilities of upload whole directory and not file-by-file.

After some more search we found one tool that worked - NcFTP
This is a solid long-live FTP client application with command line interface.
It's free, it's simple and it's does all we need from FTP client.

So, if you also looking for way to upload file to FTP using MSBuild simply use Exec with NcFTP.

Sunday, November 13

Building .NET Application with Jenkins using MSBuild and MSTest

Objective
Quick feedback to the developers and transparent information about the health of the projects. This post will focus on .NET application.

Environment
Small team of 3 developers. Two projects: .NET WPF client application and J2EE RESTful web service.

Why Jenkins

I've decide to use Jenkins as Continuous Integration server. I've use CrouseControl.NET in the past but was not so happy about it. TeamCity was another very good option and I've decide on Jenkins after all because of the strong community involvement and quick development around it, and also the fact that it is free and stay free was important factor.

Notice
Those instructions are given as-is without warranty. Use them at your own risk. You should ensure you have the proper license to run each tool on your machines.

Step-by-step

  1. Download Jenkins for Windows.
  2. Run Jenkins setup. Install it in C:\CI\Jenkins (no spaces in name)
  3. Stop Jenkins service, open Jenkins.xml and change http port to 6080. Restart the service.
  4. Open http://localhost:6080 to confirm Jenkins installation
  5. Install GitExtensions to C:\CI\GitExtensions. Install msysgit co C:\CI\git
  6. Go into Jenkins configuration -> Plugins -> Available and install git plugin. Go into Jenkins -> Configuration and change Path to git execution to C:\CI\git\cmd\git.cmd (not git.exe)
  7. Change Jenkins windows service to run with specific Windows user by open the Services mmc, open the Properties dialog for Jenkins service and change the login user to a user in your machine.
  8. Login with the user and run command to create ssh public/private key: open git bash goto ~/.ssh and run ssh-keygen.exe -t rsa -C "your-name@your-domain.com"
  9. Use the command cat id_rsa.pub in git bash to get the public key (remove new lines)
  10. Paste the public key in the remote git site (assembla, github).
  11. Create new build task. Choose git as SCM and enter your remote repository address.
  12. Run the build task, which will hang, stop it after few seconds and copy the command Jenkins execute. Paste that command into command line window and run it. You will get a message ask to approve the remote service fingure print, approve it.
  13. Run the task again and everything should work as planed.
  14. Go into Jenkins configuration -> Plugins -> Available and install MSBuild plugin
  15. Go into Jenkins configuration and under MSBuild click Add MSBuild in the name enter .NET 4 and in Path to MSBuild enter C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
  16. Download Windows SDK for .NET 4 - select GRMSDK_EN_DVD.iso. Install only ".NET Development" component. (Update: Please download Windows 8.1 SDK if you are using Windows 8 and above).
  17. Using this script copy MSTest related files from your development machine into CI server at C:\CI\MSTest
  18. Use gacutil from Windows SDK to register ".Resource.dll" and ".UnitTestFramework.dll" - it is important the files will have version 10.0.0.0 (not 10.1.0.0)
  19. Run mstest registry file [MSTest Registry Export] to add test types and other values request by MSTest to the CI server registry
  20. Go the the job configuration and add build step of type Execute windows batch command with the following command Test Batch Command
  21. Go into Jenkins configuration -> Manage Plugins -> Available -> and select  JENKINS MSTest plugin
  22. Go into the build configuration. In the Post Build Actions check Publish MSTest test result report and write TestResult.trx in Test report TRX file
[MSTest Registry Export]
You will need to export values from your registry in order to run MSTest on Jenknis machine.
For 32bit machines export HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\EnterpriseTools\QualityTools
For 64bit machines export HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\EnterpriseTools\QualityTools

If you have 64 bit developer machine and 32 bit Jenkins server just do search and replace of Wow6432Node\ to nothing to remove the 64 bit registry path part.

[Test Batch Command]
del /f /q TestResult.trx
    C:\ci\mstest\mstest.exe /noisolation /resultsfile:TestResult.trx /testcontainer:Project\Project.Test.dll

    Sources
    I've use the following posts and articles to build my Jenkins server.

    Jenkins

    http://zeljkofilipin.com/jenkins-windows-and-git/


    unit test without VS

    Conclusion
    I've only start using Jenkins now but it already helping to improve our project. It took about 4 late nights to play with it and set it up but I think it worth the trouble.
    Next I'm going to add deployment package creation automation, after this will be solid I hope to get to continuos deployment by pushing the packages to our web site.
    Also add build task for our J2EE web service and finally put a wall-screen to present the state in our development room.