Jay Harris's blog on coding .Net, automation, and improving quality through code. RSS 2.0
 Friday, June 22, 2007

CruiseControl.Net 1.3 was released this morning. To me, most important was the new Build Queue functionality, stopping multiple projects from building at the same time. If ProjectB depends on ProjectA, and they both get code changes committed at the same time, they will fail from contention. Either ProjectA will fail because it can’t delete its old assemblies (because ProjectB has a lock on them) or ProjectB will fail because it can’t find the ProjectA assemblies (because ProjectA deleted them in its rebuild).

No more.

I’m so excited that I am already upgrading our servers!

Friday, June 22, 2007 9:19:30 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
Tools | CruiseControl.Net | Continuous Integration
 Monday, October 09, 2006

For those that missed the announcement last week (like I did), the latest version of CruiseControl.Net has been released.

I plan on checking it out this week, then possibly upgrading our Build environment on Saturday. There are some modifications that I am really excited about:

  • Log4Net is used. (Default: Rolling file appender for logging server output.) If the traditional Log4Net configuration block is included in the application configuration file, I will probably change that to the ADONet appender, instead.
  • Users can volunteer to fix a broken build. How sweet is that!?!
  • <prebuild /> section allows custom tasks to run prior to the build. This one is a big bonus; previously, if something went wrong with the build, often the external log files (NUnit, FXCop) from the previous build would get included in the current build’s report. Now the prebuild can give them the boot.
  • Caching is used on WebDashboard. We have some huge log files and some not-so-powerful build servers. Sometimes it takes the machine a while to process the XSL. I am hoping that caching will help with that.
  • WebDashboard can stop and start projects. I am very excited about the ability to pause individual projects without having to modify the setup or stop the entire service.

This seems like a nice package (Release Notes). I am eager to pull it down and give it a go.

One gotcha that everyone should be aware of: Old versions of the dashboard and CCTray are incompatible with the new version of the service, so both will need to be replaced. Give your development team a heads-up, so they know to replace their tray installation as soon as the new server version is installed and online.

Monday, October 09, 2006 9:51:12 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
Continuous Integration | CruiseControl.Net | Tools
 Wednesday, February 15, 2006

NAnt hates .Net’s resource files, or .resx. Don’t get me wrong–it handles them just fine–but large quantities of resx will really bog it down.

Visual Studio loves resx. The IDE will automatically create a resource file for you when you open pages and controls in the ‘designer’ view. Back when we still used Visual SourceSafe as our SCM, Visual Studio happily checked the file in and forgot about it. Now, our 500+ page application has 500+ resource files. Most of these 500+ resource files contain zero resources, making them useless, pointless, and a detriment to the build.

This morning I went through the build log, noting every resx that contained zero resources, and deleted all of these useless files.

The compile time dropped by 5 minutes.

Moral of the story: Be weary of Visual Studio. With regards to resx, VS is a malware program that’s just filling your hard drive with junk. If you use resx, great, but if you don’t, delete them all. NAnt will love you for it.

Wednesday, February 15, 2006 11:31:31 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
ASP.Net | Continuous Integration | NAnt | Programming
 Tuesday, November 15, 2005

CruiseControl .Net 1.0 has been released. download | release notes

This is a must upgrade for anyone running v0.9 or earlier. There are many updates that I am excited about, most notably the overhaul to CCTray (the client-side build monitoring tool that sits in your system tray). Our developers have had to use Firefox’s CC.Net monitor extension to monitor multiple builds, simultaneously. No more.

We will be upgrading within the next week.

Tuesday, November 15, 2005 11:34:32 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
Continuous Integration | CruiseControl.Net | Tools
 Saturday, November 05, 2005

MSIExec error code 1605 has been a thorn in my side for quite a while. When an MSI was command-line deployed by one user (manually deployed by me in the middle of the day), it couldn’t be uninstalled by another (automation during the nightly) due to the “Just Me” default. If I installed it through using the UI, and installed it for use by “Everyone”, then the nightly would build just fine. I needed a way to run an “Everyone” install from the command line, but Google wasn’t helping me out. Unfortunately, Microsoft does not seem to have a lot of documentation on this functionality, either.

It further frustrated me this morning when my nightlies were failing again, but only on one server. Of course, I manually deployed the package to this same server to a few days ago. I tried Google again, and this time hit pay dirt. Executing it with ALLUSERS=2 in the command line makes it available for everyone. Apparently, it forces an “Everyone” install for the UI, too.

Finally I can pull the thorn out.

MSIExec /i mypackage .msi … ALLUSERS=2

Saturday, November 05, 2005 11:06:26 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
Continuous Integration | Tools
 Friday, October 14, 2005

I know. I haven’t posted in a while. But I’ve been crazy busy. Twelve hour days are my norm, right now. But enough complaining; let’s get to the good stuff.

By now you know my love for PsExec. I discovered it when trying to find a way to add assemblies to a remote GAC [post]. I’ve found more love for it. Now, I can remotely execute my performance tests!

Execute LoadRunner test using NAnt via LoadRunner:

<exec basedir=”${P1}”

    program=”psexec”

    failonerror=”false”

    commandline=’\${P2} /u ${P3} /p ${P4} /i /w “${P5}” cmd /c wlrun -Run -InvokeAnalysis -TestPath “${P6}” -ResultLocation “${P7}” -ResultCleanName “${P8}”‘ />

(I’ve created generic parameter names so that you can read it a little better.)
P1: Local directory for PsExec
P2: LoadRunner Controller Server name
P3: LoadRunner Controller Server user username. I use an Admin-level ID here, since this ID also needs rights to capture Windows PerfMon metrics on my app servers.
P4: LoadRunner Controller Server user password
P5: Working directory on P2 for ‘wlrun.exe’, such as C:\Program Files\Mercury\Mercury LoadRunner\bin
P6: Path on P2 to the LoadRunner scenario file
P7: Directory on P2 that contains all results from every test
P8: Result Set name for this test run

‘-InvokeAnalysis’ will automatically execute LoadRunner analysis at test completion. If you properly configure your Analysis default template, Analysis will automatically generate the result set you want, save the Analysis session information, and create a HTML report of the results. Now, put IIS on your Controller machine, and VDir to the main results directory in P7, and you will have access to the HTML report within minutes after your test completes.

Other ideas:

  • You can also hook it up to CruiseControl and have your CC.Net report include a link to the LR report.
  • Create a nightly build in CC.Net that will compile your code, deploy it to your performance testing environment, and execute the performance test. When you get to work in the morning, you have a link to your full performance test report waiting in your inbox.

The catch for all of this: you need a session logged in to the LoadRunner controller box at all times. The ‘/i’ in the PsExec command means that it interacts with the desktop.

* Sidenote *
PsExec is my favorite tool right now. I can do so many cool things. I admit, as a domain administrator, I also get a little malicious, sometimes. The other day I used PsExec to start up solitaire on a co-workers box, then razzed him for playing games on the clock.

Friday, October 14, 2005 10:35:40 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
Continuous Integration | NAnt | Testing | Performance
 Thursday, August 25, 2005

With our new nightly database restore we now have the desire to automatically run all of the change scripts associated with a project. We’ve found a way; I created a NAnt script that will parse the VS DBP (Database Project) and execute all of the change scripts in it. Here’s how we got there.

Problem 1: Visual Studio Command Files are worthless
Our first idea was to have everyone update a command file in the DBP, and have NAnt run it every night. Visual Studio command files are great and all, but we have discovered a problem with them: they do not keep the files in order. We have named all of our folders (01 DDL, 02 DML, etc) and our change scripts (0001 Create MyTable.sql, 0002 AddInfoColumn to MyTable.sql) accordingly so that they should run in order. We have found that the command file feature of VS.Net 2003 does not keep them in order but rather seems to sort them first by extension, then by order, or some similar oddness. Obviously, if I try to at InfoColumn to MyTable before MyTable exists, I’m going to have a problem. So, the command file idea was axed.

Problem 2: Visual SourceSafe contents can’t be trusted
Our second idea was to VSSGET the DBP directory in VSS and execute every script in it. However, the VSS store cannot be trusted. If a developer creates a script in VS.Net called ‘0001 Crate MyTable.sql’ and checks it in to the project, then proceeds to correct the spelling error in VS.Net to ‘0001 Create MyTable.sql’, VS does not rename the old file in VSS. Instead, it removes the old file from the project, renames it locally, then adds the new name to the project and to VSS. It also never deletes the old file name from the VSS store. Now, both files (’0001 Crate MyTable.sql’ and ‘0001 Create MyTable.sql’) exist in VSS. Performing a VSSGET and executing all scripts will run both scripts, which could lead to more troubles.

So, we can’t use a command file, because it won’t maintain the order. We can’t trust VSS, since it can have obsolete files. We can only trust the project, but how do we get a list of files, ourselves?

Fortunately, DBP files are just text in a weird XML-wannabe format. The NAnt script will open the file and run through it looking for every ‘SCRIPT’ entry in the file. If it finds a ‘BEGIN something’ entry, it assumes that ’something’ is a folder name, and appends it to the working path until it finds ‘END’, at which time it returns to the parent directory.

It’s not perfect. It still runs in to some problems, but here it is in v0.1 form.

<project name=”RunDBPScripts” default=”RunScripts”>

<!

Execute all scripts in a VS.Net DBP

Author: Jason Harris

Email: captain *dot* loadtest [-at-] gmail (dot) com

This script is offered as-is.

I am not responsible for any misfortunes that may arise from its use.

Use at your own risk.

>

<!– Project: The path of the DBP file –>?

<property name=”project” value=”Scripts.dbp” overwrite=”false” />

<!– Server: The machine name of the Database Server –>

<property name=”server” value=”localhost” overwrite=”false” />

<!– Database: The database that the scripts will be run against –>

<property name=”database” value=”Northwind” overwrite=”false” />

<target name=”RunScripts”>

        <property name=”currentpath”

            value=”${directory::get-parent-directory(project)}” />

        <foreach item=”Line” property=”ProjectLineItem” in=”${project}”>

            <if test=”${string::contains(ProjectLineItem, ‘Begin Folder = ‘)}”>

                <regex pattern=”Folder = &quot;(?’ProjectFolder’.*)&quot;$”

                    input=”${string::trim(ProjectLineItem)}” />

                <property name=”currentpath”

                    value=”${path::combine(currentpath, ProjectFolder)}” />

            </if>

            <if test=”${string::contains(ProjectLineItem, ‘Script = ‘)}”>

                <regex pattern=”Script = &quot;(?’ScriptName’.*)&quot;$”

                    input=”${string::trim(ProjectLineItem)}” />

                <echo message=”Executing Change Script (${server+”+database}): ${path::combine(currentpath, ScriptName)}” />

                <exec workingdir=”${currentpath}” program=”osql”

                    basedir=”C:\Program Files\Microsoft SQL Server\80\Tools\Binn”

                    commandline=’-S ${server} -d ${database} -i “${ScriptName}” -n -E -b’ />

            </if>

            <if test=”${string::trim(ProjectLineItem) == ‘End’}”>

                <property name=”currentpath”

                    value=”${directory::get-parent-directory(currentpath)}” />

            </if>

        </foreach>

    </target>

</project>

I used an <EXEC> NAnt task rather than <SQL>. I found that a lot of the scripts would not execute in the SQL task because of their design. VS Command Files use OSQL, so that’s what I used. I guess those command files were worth something after all.

If you know of a better way, or have any suggestions or comments, please let me know.

Thursday, August 25, 2005 11:15:41 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
Continuous Integration | NAnt | Task Automation
Navigation
Archive
<May 2008>
SunMonTueWedThuFriSat
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567
Blogroll
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2008
Jason Harris
Sign In
Statistics
Total Posts: 63
This Year: 3
This Month: 1
This Week: 0
Comments: 1
Themes
Pick a theme:
All Content © 2008, Jason Harris
DasBlog theme 'Business' created by Christoph De Baene (delarou)