Since I’ve had a lot of interest in the VS.NET Starter Kits I created for the Facebook development I thought it worth mentioning I’ve updated both to their latest releases.

Facebook Developer ToolKit is now at v1.5 (starter kit download)

Facebook.NET is now at v0.3 (starter kit download)

Here are the relevant blog posts:

Visual Studio Starter Kit for Facebook application development

VS.NET starter kit for Nikhil Kothari’s Facebook.NET

Enjoy!

With the advent of Microsoft’s new MVC framework for ASP.NET I think there will be a fairly significant impact on developers who have come to rely heavily on WebForms and related controls. I believe the new framework will require a significant "rethink" of how applications and controls are developed. If you watch Scott Hanselman’s video you’ll see he uses Rob Conery’s Mvc.ToolKit to flesh out the UI and notice that it doesn’t use the designer nor web controls at all.

The MVC framework is clearly going to change how the VS.NET web form designer will be used and certainly makes it less important. It will be interesting to follow the evolution of the framework and to see how MS updates the designer and code editor to fit this new (as in new to MS) model. It will also be interesting to see how 3rd party control companies like Telerik and Developer Express respond.

While at CodeGear I had frequent discussions with Jim Tierney (who I co-developed Delphi’s ASP.NET designer with) about moving Delphi’s designer away from being a WebForm centric because of the development costs involved and instead focus more on the code editing experience. I think the MVC style of development does just that and I expect Microsoft to come up with a number of improvements to the framework and tooling to better support it. I’ll be curious to watch what this means for Delphi’s ASP.NET support.

One thing I think is particularly interesting is with WebForms out of the way ASP.NET developers will be in a better position to leverage non-Microsoft AJAX frameworks such as Dojo, Prototype etc. etc.

Kudos to Microsoft for following through on this much needed alternative to WebForms!

A few months ago I started working in an area I previously knew little about, EDI. EDI stands for Electronic Data Interchange and it defines standards for how businesses communicate with one another electronically. The basic flow of information for what I’m working on looks like this:

 
The document numbers above correspond to the following:

• EDI 850 = Purchase Order (PO)
• EDI 810 = Invoice
• EDI 997 = Functional Acknowledgement

My client represents the seller’s side of this diagram and I’m specifically working on the lower half of this picture, the invoicing portion, as there is existing software which handles PO’s. As indicated in light red there is a trading partner involved which brokers various services between buyers and sellers including providing EDI services. The EDI "documents" are cryptic delimited text files exchanged via numerous transport mechanisms though FTP is used in this case.

The Flow

Basically, there is a system which polls the trading partner, again via FTP, looking for new purchase orders. When one is found the file is downloaded, validated, processed and an acknowledged (EDI 997) is transmitted back to the trading partner. Eventually, the order works it’s way through the system and an invoice is generated at which point, an EDI 810 is generated and transmitted to the trading partner, validated and again acknowledged with an EDI 997, a mirror image of the EDI 850 processing. For brevities sake I’m glossing over parts of this process but you get the gist of what’s going on.

When I first was assigned to start working on EDI invoicing I had a lot of things to learn including EDI, the current processes involved in invoicing and the software that handled purchase orders among others. I quickly learned via not so subtle hints that the existing software which handles PO’s wasn’t considered maintainable and is badly in need of replacement.

Using CruiseControl.NET

Once I got my feet grounded I realized this system closely resembled a continuous integration process and started investigating using CruiseControl.NET as the primary engine to drive invoice handling. I already knew CruiseControl.NET brought a number of interesting features to the table including:

• Open Source
• Polling architecture for trigging task execution
• Open plug-in architecture for things like source control providers and task execution
• Easily configured using XML (ccnet.config)
• A customizable web based portal for monitoring projects
• Email publishing for notifications
• Logging

Basically, you can envision CruiseControl.NET as the two blue circular arrows in the middle of the above diagram. In a future, post talk more about the specific implementations of ISourceControl and ITask that I’ve written to manage this EDI process.

In this, my second post in a series on automated testing, I’m going to talk about a few steps you’ll need to take after your team has committed to automation. Diving into the deep end and immediately writing a bunch of tests isn’t the place to start. Organizing your project, preparing your code base and planning for automation are the first priorities. Of course, the assumption here is that you’re adding automation after the fact.

Organizing your build

If your project isn’t easy to build you’ve identified the first thing that needs fixing. Having a repeatable automated build is key to a successful test automation strategy. Essentially, getting your build organized means the following two things:

• Version control
• Continuous Integration

Version Control

The first step to organizing your build and preparing it for continuous integration is to make sure it’s under version control. There are lots of ways to implement version control but it’s the first step to repeatability which is what test automation is all about. Personally, I really like SubVersion otherwise known as SVN, and would highly recommend it particularly if you’re just starting out. There’s been plenty written about the benefits of version control so I won’t go into that here just make your choice and get your code checked in.

Build Automation

The next step is automating your build process. Jeff Atwood wrote The F5 Key Is Not a Build Process discussing the benefits of moving your build process beyond your IDE of choice and I couldn’t agree more. Build automation is really going to be the key to successful test automation. When changes are committed to your repository a build gets kicked off and subsequently launches your test automation. With this setup you’re automation is guaranteed to run against every change to your repository immediately notifying you when a change has "broken" the build.

For continuous integration I’m a fan of CruiseControl.NET but as with source control you have a lot of choices. CruiseControl.NET is open source and includes a web dashboard that’s easy to modify and supports writing plugins making it easy to extend the build system. Its rather light on documentation so if you don’t want get your hands a little dirty I’d recommend something like Automated Build Studio from AutomatedQA.

 

Putting it all Together

If you find this to be a bit daunting, have no fear I’ve put together a 10 minute video that demonstrates this entire process from beginning to end for a simple project. Of course, your project will be more complex but you’ll get a feel for how easy it is to get going. Note, I made this video in April '07 while still employed at Borland which is no longer the case nonetheless the video is still relevant.

Previous entries in this series:

• Automated testing advice - making the commitment

Other related posts I’ve written:

• Automated testing of ASP.NET web applications using Selenium
• Developing GUI test automation for a Continuous Integration environment
• Modeling UI for automated GUI testing
• Automated testing of Windows applications is hard

We’re using CruiseControl.NET with an MSBuild task to build the solution file for a large ERP system which includes 21 .csproj files and recently when some code was moved to a new project the build started failing with this error:

Velocity.sln : Solution file warning MSB4051: Project {958E0376-0272-4149-A1CF-E03521D12A72} 
is referencing a project with GUID {14F4138C-4DA7-4029-A8D3-B1B3954C2839}, 
but a project with this GUID was not found in the .SLN file.

The weird thing is that from within VS.NET the project would build just fine. It turns out that the .sln file was missing "EndProject" line just above the GUID mentioned. Here is the fragment of the .sln file with the problem (fyi, I’ve wrapped the two project lines):

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "VelocityProductionPlanning", 
  "VelocityProductionPlanning\VelocityProductionPlanning.csproj", 
  "{4BAFD59F-EBB5-4FDA-8639-F7FC63F7F351}"
 ProjectSection(WebsiteProperties) = preProject
  Debug.AspNetCompiler.Debug = "True"
  Release.AspNetCompiler.Debug = "False"
 EndProjectSection
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "VelocityLibraryMessaging", 
  "VelocityLibraryMessaging\VelocityLibraryMessaging.csproj", 
  "{14F4138C-4DA7-4029-A8D3-B1B3954C2839}"
EndProject

Notice, the project VelocityProductPlanning has no "EndProject" line. That caused MSBuild to generate the above warning and subsequently the build to fail.

Hope this helps.

UPDATED Nov. 6, 2008: A new release is available here.

I've created a Visual Studio Starter Kit for developing Facebook applications in ASP.NET using C#. This isn't necessarily new though this post title more accurately describes the download. I'd never created a Start Kit before and in fact, it was easier than I thought. I've been following Internet Searches people use to find my blog and "Facebook" as a search term is certainly picking up and it seems many, many people are blogging about FB these days.

Let me know if you have any problems or suggestions for improvements.

It's Thursday meaning my last day at CodeGear and my final Delphi wisdom list:

• Use the public newsgroups (though feel free to skip non-tech)
• Read the blogs
• Use Torry's
• Use a community search engine or build your own
• Use CodeCentral
• Use open source
• Log bugs
• Digg stories you read on Delphi blogs
• Add Delphi blogs to your Technorati favorites
• Comment on Delphi blog posts
• Ask questions the smart way
• Start a Delphi blog