The wummer

The core of the Web Updater program is complete; it can now connect to web servers, obtain wum.xml files, validate them against a public wum schema, perform a differential check against the locally installed files on the client and download the obsolete/missing files. After downloading it can now replace the files on the client via decompression (if the wummer tool had compressed them when publishing) or, just renaming them into place.

My "wummer" publishing tool is finished, save a few UI nuances, and so together they have created a functioning publish/update circuit.

The Web Updater still needs a few more things; certain disaster recovery scenarios still must be accounted for, like if it can't access files it's trying to update or it's connection drops while downloading. It also still needs the ability to accept command line arguments when it runs, and finally it needs the ability to re-launch the target application it's updated. So I guess it's about 85% complete.

Here it is, dutifully "updating" a bunch of nonsense files. I added the little treeview to it this evening, just for fun.

wum

So the XNA Content Assistant is largely finished and I wanted to distribute it using some kind of web update model, to make it easier for all of you to update the Assistant in the future. So I built a little update functionality into the Assistant under the Visual Studio ClickOnce model.

ClickOnce is really neat and very easy to use, but unfortunately for the XNA Content Assistant it is unacceptable. The problem is that you can't effectively launch a ClickOnce application from another program e.g. via Process.Start while passing command line arguments. At best, you can submit a query string to a web-based application, but having the Assistant be entirely web based is not acceptable. The Content Assistant must be installed on the local machine and must be callable via command line with arguments.

Therefore I abandoned the ClickOnce model and for the past couple days I've been crafting a web update system. This is something I will require anyway, to allow updates to my future XNA applications, so it's somewhat of an inevitable project.

The Web Updater does its best to be somewhat generic; in a nutshell it just needs to know the URL of your application's "wum.xml" file (Web Updater Manifest), a simple xml file which describes the current files available on the update server (name, size, last update, etc). The Web Updater grabs the wum and checks it against whatever application it's updating on the local machine, and updates files as necessary.

To that end, now I'm in the process of writing a companion tool for wum publishing called the Wummer. The Wummer is for developers, we point it at our Release folder (or, whatever you want to publish), and the Wummer uses an IO.CompressionStream to publish your application to your web host as .gz files, creating the wum.xml file for you (an otherwise tedious task).

So I've been pretty busy working on all this lately, juggling work and 3 of my own little mini-projects! I believe these will all be helpful tools though and I hope to have them finished up pretty soon.

XNA Content Assistant

The logistics of how content gets built in the VB template will change when GS 3.0 is released. Rather than hard-code all of the content building specifics into the VBContentManager class, this functionality has been moved into a stand-alone application, which will act as a bridge between a non-Game Studio project and the Content Pipeline. This application is called the XNA Content Assistant, and is a Windows form application with a graphical interface. However, it also supports being called from the command line in an invisible mode.

I'm currently putting the XNA Content Assistant through beta, naturally I want to debug such an important component thoroughly. It is functional at this time, and so here's a preview of what it looks like, and what it does:



You start out by opening your game's Visual Studio or Visual Express project file. (when running from a command line, you would supply this as an argument)



Based upon the location and contents of the specified project file, the XNA Content Assistant will automatically determine where your content folder is (even if you did not name it "content"). It will then automatically determine which XNA framework version your game is programmed against. The XNA Content Assistant understands how to build content for Game Studio Express (1.0 Refresh) projects, Game Studio 2.0, and Game Studio 3.0 projects created in either VB or C# in Visual Studio 2005, 2008, and the Express editions.

On the GUI, we can see the Assistant has successfully harvested content from my "Timeclock" application, and I am proceeding to select a platform (this would be the 2nd and final parameter you would need to supply via command line)



And lastly when we execute the build process, we can see that MSBuild's output is integrated nicely into the Assistant's UI, to help troubleshoot build issues such as missing fonts, etc. It also exports a log and a copy of the content project submited to MSBuild in your project's folder for reference.



As future XNA versions are released, XNA Content Assistant will be updated and your existing template can simply continue to utilize the updated Assistant, rather than requiring code changes to the template itself (i.e., the VBContentManager class, which will be largely obviated by the Assistant).

XNA 3.0 CTP

The XNA/GS 3.0 CTP is out and I'm in the process of updating the VBContentManager in preparation for the official release.

XNA 3.0 content processing expects to use the .NET Framework v3.5 edition of MSBuild. For those not interested or ready to move to XNA 3.0, XNA 2.0 compatibility will be retained in the VBContentManager.

To that end, the GS 3.0 release will mark a small change in how the VBContentManager works. A version enumeration is now required by the VBContentManager class, and moving forward, the VBContentManager will be augmented with new version support (rather than replaced wholesale) so that future editions of the VBContentManager can target prior XNA versions (dating back to 2.0). Just pass in which XNA version you're targeting, and it will process your content accordingly.

The VBContentManager currently available for download was never updated with functional, XACT-based audio importing. I do have this working in my "production" VBContentManager, and as part of the 3.0 update I will include this for backward compatibility with 2.0's XACT-based audio. And of course the new audio importing for 3.0 will be available as well, which is what I'm working on now.

Microsoft.VisualBaggage

Here's an interesting article on Paul Vick's blog (not exactly new, but it was to me): VB Runtime agility, Orcas and new platforms.