Feed Icon  

Contact

  • Bryant Likes
  • Send mail to the author(s) E-mail
  • twitter
  • View Bryant Likes's profile on LinkedIn
  • del.icio.us
Get Microsoft Silverlight
by clicking "Install Microsoft Silverlight" you accept the
Silverlight license agreement

Hosting By

Hot Topics

Tags

Open Source Projects

Archives

Ads

Page 1 of 2 in the TestDrivenDev category(RSS) Next Page

Installing Subversion as a Windows NT Service

Posted in General | Test-Driven Dev at Wednesday, October 03, 2007 12:39 AM Pacific Daylight Time

Each time I set this up I always have to google to remember how to do it. The last time I set it up I came across James Kovacs' post on the subject which works great. The only thing I usually end up adding is the --listen-port=x since many clients do not allow me to open up a new hole in the firewall so we end up using port 443 which works great.

I actually couldn't find James's post (I think I was googling subversion windows service instead of svn windows service) and found it through Corey Ippolito who references James in his post.

So hopefully I never have to look hard for this again. :)

Continuous Integration 2.0

Posted in Test-Driven Dev | .NET at Friday, December 08, 2006 1:35 AM Pacific Standard Time

Just finished reading Bil's excellent post on his frustrations with Continuous Integration (CI) in the VS 2005 world. My feelings about CI with VS 2003 and the nAnt, nUnit, Subversion, CC.Net combo are the same as his:

Visual Studio 2003 and Cruise Control.NET. Simple and elegant. A basic NAnt script to build the solution and you're good to go. Run NUnit, output goes to a format CC can understand and Bob's yer uncle. Let me quantify this. Our cruise server has a subversion client (command line) and the .NET 1.1 SDK. Visual Studio isn't installed because, duh, it's a server and cruise just needs something to build the system with.

CI in VS 2003 with CC.Net and friends was great. Everything ran smoothly for the most part. When you went to setup a project the choices of what to use for unit testing, build automation, and CI were pretty clear. Now we have more choices on how to run our projects and it isn't always clear which choice is the best. I've done projects using both sets of tools: VSTS for testing, source control, and CI as well as the old school nUnit, nAnt, subversion, CC.Net combo. The old school method seemed much simpler and easy to use/understand. But I figured maybe it was just because it was what I was used to. However:

Continuous Integration does not need to be this hard. CruiseControl.NET is an excellent tool and very flexible with new tools and integrating output from those tools. However when those tools require a million registry settings and even more DLLs (put in very specific places, trust me, you can't just toss them in the GAC and call it a day) and dump gobs of XML that no mere mortal (well maybe DonXml could) would be able to translate, it's just wrong. And as for the built-in Team Build that you could us, that's equally as useless as a) you can't schedule builds to trigger off of code checkins and b) again it requires a full Team Suite client to be installed on the server.

I feel Bil's pain. However, you can schedule builds to trigger off code checkins, but configuring these things isn't as straightforward as it could be. I didn't setup our last build environment (Jesse did), which had check-in triggered builds with email notifications, but I seem to remember it was pretty complicated and you didn't get the nice CC.Net type emails which showed you exactly what was going on with the build. You had to go look at the build on the server to see what happened.

So for now, if it is a small project, I tend toward the Subversion, nAnt, nUnit, CC.Net path, using MSBuild to build projects as needed (MSBuild is a must for things like building/deploying VSTS Database Pro projects). The big question for me will be what to use when my next big project fires up. I really want to use the MS tools and to become proficient with them, but I also don't want to be constantly fighting with my CI toolset.

Subversion Revision Number in Nant

Posted in Test-Driven Dev at Tuesday, March 07, 2006 7:42 AM Pacific Standard Time
I was trying to figure out how to get the latest revision number from our SVN repository today and came across this great example of how to do this. Very nice. Now I can do a lot of build specific stuff in my build script.

Hardcore VPC Setup

Posted in SharePoint | General | Test-Driven Dev at Wednesday, November 16, 2005 7:59 AM Pacific Standard Time

From Patrick:

VPC images are saving my life as a trainer. Managing your VPC images however can be a daunting task if you don't know all of its capabilities. Andrew has an extremely well-documented process & strategy for using Virtual PC and how to optimize and manage disks to (1) maximize my disk space and (2) facilitate rapid creation of new Virtual PC’s when needed for testing/kicking the tires. Thank you very much Andrew for sharing this with all of us.

I've been doing my development on using Virtual PC for the last six months and the tips in this post are very useful. My setup is much simpler, but I can see some of the advantages this type of setup can give. However, I'm curious as to the drawbacks.

  • Is there a performance hit for using that many disks instead of a single disk? If so, how much are we talking about?
  • If you need to make a change to the base OS, can you make the change on the base disk or will this wipe out all your machines?

For my dev work I've just been creating a base VPC image with the OS and common tools and then setting the file to read-only and making a copy of it for each VPC I need to create. I've even been using fixed disk size in an attempt to eek out every last bit of performance that I can get. I have to pay for it with a larger hard drive, but that isn't too much of a price to pay.

CCNet 1.0 Released

Posted in General | Test-Driven Dev at Monday, November 14, 2005 10:11 AM Pacific Standard Time

via Sam Gentile:

We use CC.NET on our project so we are going to need to upgrade. You should too if you are using it.

Read the Release Notes here and download from here

Cool! I'll have to see if they fixed their stylesheet bugs, but if not you can get my custom stylesheets here.

Cruise Control XSL

Posted in General | Test-Driven Dev at Wednesday, November 09, 2005 8:48 PM Pacific Standard Time

As I mentioned in my last post, we have relied heavily on CCNet on our project along with other open source tools. A couple other tools we use are NCover and FxCop. Both of these tools run as part of our NAnt build script along with NUnit. We display the results of these in our CCNet build report using custom XSL stylesheets. The stylesheets are all based on the NUnit stylesheet that comes with CCNet (which I also modified to correct a bug that happens when you have two methods with the same name) .

We also had to do some post processing on the NCover report to weed out some duplicate (and invalid) coverage details. I created another custom xsl which I used with msxsl.exe to transform the report into something more useful. If you run into this bug let me know and I'll post that stylesheet as well.

 

 

Continuous Napolean

Posted in Avanade | Test-Driven Dev at Monday, November 07, 2005 11:10 PM Pacific Standard Time

Last night we released the version 1.0 of the software I've been working on for the last six months. Hopefully that means I'll have more time for blogging and more time to explore all the new stuff that has been released recently. One of the things that has been essential to the success of our project has been continuous integration via CruiseControl.Net. We have a couple of build servers running CCNet and the feedback on developer check-ins (through Subversion) has been key.

When a developer breaks the build with a bad check-in, the scary guy comes and hangs out on their monitor until they get it fixed:

We try to have fun. :)

I've also set up CCTray to run on my development box. You can specify sound files to play for the different cruise control events. There are 7 other developers in the room with me (also known as lounge A) so when someone breaks the build they all know (lounge B had their own sounds). Below are the Napolean sound bytes we used which were great fun. I found them all on the movie wavs site.

We still have more work to do, more releases to come, but we managed to hit all our dates thanks in part to test-driven development with freeware tools: nant, ccnet, subversion, and nunit

Master of Some

Posted in Sql and Xml | Reporting Services | SharePoint | BizTalk | General | Avanade | Test-Driven Dev at Thursday, September 01, 2005 4:05 AM Pacific Daylight Time

From Clemmens talking about technology overload:

Enter VS2005 and the summary of trying to achieve the same knowledge density is: “Frustrating”.

I feel his frustration. I remember going to PDC 2003 and realizing that it was getting very hard to keep up on all the new stuff coming out of Microsoft. Clemmens continues...

For “generalists” like me, these are hard and frustrating times if they’re trying to stay generalists. Deep and consequent specialization is a great opportunity for everyone and the gamble is of course to pick the right technology to dig into and become “the expert” in. If that technology or problem space becomes the hottest thing everyone must have – you win your bet. Otherwise you might be in trouble.

This statement not only applies to technology in general, but also to specific technologies: think SQL Server 2005. As Kimberly Tripp says, you must become a “Jack of all trades, master of some”. The hard part, as Clemmens mentions, is chosing the some.

For me it all comes down to what I'm working with. For instance, I just found out today that I will not be getting renewed as a Microsoft MVP for SQL Server. I expected this because I haven't had the time to contribute much to the SQL Server community lately. I tend to contribute based on what I'm currently working on. I haven't been a project that used SQL Server 2005 yet, so I haven't had time to really dig into it. If you read this blog you can probably figure out what kind of projects I have been on recently: a SharePoint (and RS) project last year and mostly BizTalk projects this year. I learn based on need.

I'm sure at some point in the near future (at least I keep telling myself this) I'll have time to dig into the new SQL Server 2005 and Visual Studio 2005 stuff (team system and all), but for now I'm pretty much focused on BizTalk 2004, test-driven development,  continuous integration, etc., since that is where I'm at.

I'll miss hanging out with the other SQL Server MVPs who are a great bunch of guys, but it has been fun being an MVP for the last five years.

Multi-Threaded and Multi-Domain Tests

Posted in BizTalk | Test-Driven Dev at Tuesday, July 19, 2005 7:58 AM Pacific Daylight Time

Just finished writing some test code for some shared utilities on my current project. The project is a BizTalk project so the utilities can be hit from multiple threads and from multiple boxes (with a shared database box). So I needed to test for these scenarios. The multiple threads was pretty easy, but I found this page to be very useful and thought I would pass it along.

I also attempted to simulate the multiple box scenario by creating multiple AppDomains (one domain per thread) and then hitting the utility from the separate domains. In figuring out how to do this I made use of this article by Eric Gunnerson. The tests all pass, which is good, but I'm not totally convinced that I'm really simulating things correctly.

Anyhow, both those links are good reads that I want to remember... 

Testing Custom Flat File Disassemblers

Posted in BizTalk | Test-Driven Dev at Sunday, May 15, 2005 4:01 PM Pacific Daylight Time

At my current project for Avanade I've been working with Hisham (who is also my Career Manager and whose blog I read before I even knew about Avanade) and we've been doing a lot of BizTalk stuff. As he stated here, BizTalk development, without the help of some external tools, can be very time consuming just in the build->deploy->bind->enlist->start process of running BizTalk. One of the pieces that I've been working on is a custom Flat File disassembler. I found that testing my component within BizTalk was very time consuming. I also knew that there was a utility in the SDK for testing flat file disassembly (FFDasm.exe) which uses the standard flat file disassembler (FFDasmComp). So, with a little help from Reflector, on my flight to Seattle I hacked together a new version of the utility (FFDasmEx.exe) which accepts an additional parameter for the name of the custom pipeline component that you would like it to use instead of the standard disassembler.

This makes testing a breeze as you can simply compile your pipeline component assembly, copy it to the Pipeline Components folder, and then run your test. You can easily debug your component using this same method but running the FFDasmEx project in debug mode.

If anyone is interested let me know and I'll zip up the project and post it somewhere. However, if you have a copy of Reflector you can probably put it together yourself in about ten minutes.

Page 1 of 2 in the TestDrivenDev category(RSS) Next Page