Build a Reporting Services Solution with MSBuild 4.0

I recently was tasked with setting up a build for a large solution of Reporting Services reports. The goal was to build and deploy them. The build was pretty easy although disappointing. Reporting Solution projects are not msbuild projects. You can however build the solution from the command line using devenv.exe. Which looks something like this:

devenv.exe /Build debug /out ".\Logs\SSRS.Log" ReportingServices.sln

So automating this on a build server was pretty simple. Install a copy of Visual Studio 2008 or 2005 depending on the version of your reports. (No 2010 can’t even open a reporting solution let along build it.)

In source control in the same folder as your Reporting Services Solution create a batch file with the above command. I would pass the drop location in to batch file and put the log there instead of in the source directories. So the batch file may look more like this.

mkdir %1\Logs
devenv.exe /Build debug /out "%1\Logs\SSRS.Log" reportingServices.sln

Now in your build process template drag in an invoke process activity, and populate 

ExitCode is a Variable of the type int32 that you would create in your build process.

BuildDetail.DropLocation and SourcesDirectory are variables already set up for you that hold the Drop Location you selected in your Build Definition and the Sources Directory defined by your Build Agent Working Directory.

TFS Build Invoke Process Activity

Likely the most useful tool in the list of Team Foundation Build Activities is InvokeProcess. This little Activity lets you call out to anything you want. I have found it very useful for executing a batch file that is stored with my source code to do a number of things. Invoke a PowerGen build for PowerBuilder Applications. Invoke Devenv.exe for building Reporting Services, or calling a deployment script you don’t want to rewrite at the moment.  

When I went to use this activity the first time there was not much out there as an example so I thought I would post a quick and dirty example of using the Invoke process.

Find the place in your process where you want to make the call and drag in an InvokeProcess Activity.

Next you want messages that come from the application you are calling to end up in your Build report. This is done via stdout and stderr. So drag over a WriteBuildMessage Activity and a WriteBuildError Activity into the Invoke process as seen below.

There are two variables defined stdOutput and errOutput they need to be placed in the message property of the Write Activities. I would set the Importance property on the WriteBuildMessage Activity to High. Like this:

Now for the properties of the Invoke process. It’s pretty simple really.

DisplayName: This will be exposed in the Workflow so it’s good to name it something that reads well and tells the reader what you are doing here. 

FileName: The file you want to call. For batch files I find it useful to put the file in source control with the app. Then use the SourcesDirectory variable to find it. See Below.

Arguments: What you want to pass to the called application or batch file.

Result: Your ExitCode variable. The last thing you call from the batch file or the app will generally return an exit code then you can use that to determine if you want to carry on in the build process.

EnvironmentVariables: This dictionary of <string, string> allows you to specify environment variables and their values.

OutputEncoding: You can specify the encoding that is used to read the output (StandardOutputEncoding) and error (RedirectStandardError) streams. I have only ever used the default value.

So if I wanted to call a batch file named MyBatchFile.bat and it was in source control at the root of my solution folder, and I want to pass in the Drop Location from my build definition. My InvokeProcess might look like this.

ObjectSharp At the Movies is in the Cloud

 
 

Join ObjectSharp and Microsoft on May 5th for a Half Day in the Cloud! Learn to provide stability and elasticity for your web based solutions as we leverage Windows Azure. Technologies including Silverlight, ASP.NET, Team Foundation Server, Visual Studio and Powershell will be in the Air as we rain data down from the Cloud. This is one summer blockbuster event that cannot be missed!


ATM 2011 Learn More!
FacebookTwitterFlickrRSS

2010 At The Movies

Thursday, May 5th, 2011
Registration: 8:00am - 9:00am
Presentation: 9:00am - 12:00pm

2010 At The Movies

Scotiabank Theatre
259 Richmond Street West
Toronto, ON M5V 3M6
Directions

2010 At The Movies
FREE admission

TFS Power Tools March Release

A new version of the TFS PowerTools were released recently.

This release includes changes to the following areas:

  • TFS Backup
  • TFS Best Practices Analyzer
  • TFPT.EXE Version control command line
  • Windows Shell Extensions

You can get more details and download from here.

March 8th MS Announcements

I’m a little slow getting to this. Just no time to Blog in the past coupe of weeks.

Last weeks big announcement and two service packs and a Feature Pack oh my!

1. Unlimited Load testing. Now you can load test your application without having to purchase Virtual User Packs. You use to have to purchase Load Test Packs to be able to simulate 100o users. Now this comes free with the Ultimate edition of MSDN.

2. VS/TFS 2010 SP1 and TFS-Project Server Integration Feature Pack is out in Beta. The Service Packs includes a bunch of fixes see links below, while the Feature Pack allows you to integrate your project Server with TFS.

MetaData Override

 

I learnt something I didn’t know, so I thought I would share it. I was creating a build for a client that builds several technologies. PowerBuilder, Java, .net 1.1, SQL Server 2008, Reporting Services and .net 3.5.

I altered the Default Template to perform the other technology builds. The problem was The Build Settings argument is required and in this case I didn’t want it to be. They may use the process to build something that is not a .net solution after all.

The trick I found: If you add the Buildsettings to the MetaData argument and don’t make it required it overrides the default.This way you can still use Buildsettings just like you would in the DefaultTemplate however if it’s not needed for the build definition you are creating it will not be required.

Visual Studio 2010 Feature Pack 2

Deb Forsyth posts lots of great information about TFS and it’s related tools for the Test community. She put up a post recently about the new Feature Pack for Visual Studio.

There is one feature in this Feature Pack that is particularly useful, the Coded UI Test Editor. If you have worked with Coded UI Tests you will know, although powerful the tooling around version 1 needs some maturing. We'll it’s already begun. When you create a Coded UI Test it generates a couple of files. The UIMap.uitest  which maps methods that manipulate the UI and assertions to the application under test, and  the Coded UI Test class which is really just a test class with test methods that call methods in this UIMap object.

Prior to Feature Pack 2, to make a change to the UIMap.uitest has not been easy you would have to have a good working knowledge of .net development. However, now we have the Coded UI Test editor. After you install the new Feature Pack open the UIMap file in your test project and an editor will open that allows you to see all the methods in your UIMap rename them split them out into other methods. It will also allow you to change an assertion as seen in the image below.

This is a welcome tool when writing automated tests using Visual Studio.

TF215097: An error occurred while initializing a build for build definition

If you ever get an error like this in the build. Think back, did you recently remove a build argument from the build process template?

Apparently when you modify the Build process template and therefore it’s no longer in sync with the build definition you can get this error.

To solve this problem you need to get them back in sync. Even though from the process tab of the build definition your arguments all seem to be ok.

To fix the problem open the Build definition and from the process tab refresh the build process.

That fixed the problem for me.

Thanks to Jakob Ehn for his post which explains this issue in more detail.

PowerBuilder and TFS Source Control

I have been helping customers who are implementing Team Foundation Server (TFS) and would like to put PowerBuilder Code into TFS source control. I’m not sure how different this would be in the newest versions of PowerBuilder that support xaml and where powerscript is a .net language. However for the older versions where the customer is still using native PB there are a couple of things you might want to do to make the experience better for all involved.

First let me explain one problem with PowerBuilder and TFS: If you just add the PBL’s in your target to TFS all the exported objects end up in one folder and it’s hard to tell where everything comes from. This may not be a big deal if you never look at the source explorer in Team Explorer, but why wouldn’t you?

So here are my suggestions:

1. First set up a folder structure that will become your local working copy of the PB code. I recommend putting each PBL into it’s own folder. This might seem odd at first but once TFS gets a hold of it and all your objects are in each folder along with the .PBG file it will be a lot easier to work with. So lets say your folder structure looks something like this:

MyPBApp  
Logistics
Order
Shipping
Warehouse

2. Now put your target file in the MyPBApp  folder. In .net speak the PBL is the project and the target is like the solution. There is one more level above that (the workspace) but I’m going to ignore that in source control and just keep it local. You will have to fix the target in PowerBuilder so that it can find the PBL’s in their new locations.

3. Make sure PowerBuilder is connected to TFS via the MSSCCI provider. You can set up the connection by right clicking on the PowerBuilder workspace, select properties and go to the Source Control tab. I would also install Team Explorer so you have access to the full feature set of TFS.

4. From PowerBuilder pick your target and select Add To Source Control. This will export all the objects out of their PBL’s and create a PBG file which is a manifest of the objects inside that PBL. Now anyone on the team can get latest and open the Target in their local workspace.

5. Make sure to tell everyone to make the local copies of their PBL’s writable. Or they will have to check them out when they check out an object. Trust me it’s easier to make them writable locally.

Code Metrics PowerTool

 

Would you like to be able to run code metrics for your application via the build process. As of two days ago you can. ON Jan 26th 2011 MS published the Visual Studio Code Metrics PowerTool 10.0.

With this power tool you can perform code metrics via the command line so it can be called from your build.

Just download and run metrics.exe /? for help.