We released the latest version of Photo Story yesterday, and it is now available for download for Windows XP users. If you're like me, you probably have a hard drive full of digital photos that you'd like to make into an easy-to-download (or e-mail) slide show. Well, this free tool makes that process extremely simple. Here are some of its features:
Channel 9 has an interesting 24 minute demonstration by Vladimir Rovinsky and a second 28 minute interview with members of the product team. Also, Paul Thurrott's SuperSite for Windows has a good review of Photo Story 3 that is worth reading.
Here's a thumbnail from some very nice wallpaper images from DivineError. He has a 1600 x 1200 version, a 1280 x 800 widescreen version and a non-glass version. He's created a lot of other great images too, if you spend the time to look through his collection.
Speaking of desktops and wallpaper, if you want to completely amaze your associates and suck all the power out of your laptop or desktop computer, try this very cool 3D animated desktop called Desktop Dreamscapes. It's a 3D animated desktop...not screen saver, and notice that it's been around since 2002. Amazing stuff.
And before I finish, let me plug my own Macro Wallpaper and Macro Wallpaper 2 posts.
You may recall that I've been waiting for one of two "triggers" to order a new computer. Well, even though my first trigger, Doom 3, has already been released, I found that it ran very acceptably on my current P4 1.8GHz Dell Dimension 8100 computer. So, I played through Doom 3 on my current computer and hoped that by delaying my purchase, I might possibly catch another technology wave (for example, PCI Express) before Half-Life 2 hit the shelves. Based on recent article and posting activity, I get the feeling that Half-Life 2 will RTM within a few weeks. And if that's the case, I need to order now because of the delay in obtaining the video card I want (NVIDIA GeForce 6800 Ultra). So, last night, I pulled the trigger and placed my order.
I decided to order the following system from GamePC:
The dual Western Digital Raptors will be configured as a RAID 0 system drive for maximum performance. The BFG Tech GeForce 6800 Ultra OC comes overclocked at 425 MHz for a little extra video acceleration. It's tough to choose a case when you can't see them in person, but I know that I don't want a full tower, since I don't tend to upgrade my machines much anymore, and I don't need the extra internal space. I also don't want a door in front of my drive bays, because I hate having to constantly open and close it (call me lazy). So, based on these choices, I went with the Lian Li PC-61 Mid-Tower, and I'm sure I'll be happy with it.
This is the first time I've ordered anything from GamePC, but if initial impressions are any indication, I'm already impressed with this company. First, they allow you to configure almost anything you'd like using their web-based rig generator. Yes, other companies have this feature on their sites, but GamePC has a much larger selection of top-end components that you can mix and match at will. Second, after I sent them my desired configuration and some questions about it via e-mail, I received a very comprehensive and technically satisfying answer within 30 minutes. When I followed-up with another question, I received another excellent response within a very short timeframe. Each subsequent e-mail exchange was quick, showed a deep understanding of their system components, and never pressured me to do anything. They left everything up to me. As a matter of fact, after slightly modifying my configuration based on their suggestions, I ended up saving $71 off the system I had originally configured myself. Now that's customer service.
As I suspected (and their rig generator confirmed), GamePC is currently waiting for more GeForce 6800 Ultra cards, because they are in short supply. So, I expect to wait a couple of weeks before they can finally complete the system build, burn it in, and ship it my direction. I'll definitely have a follow-up post when the machine arrives and I've had a chance to play with it.
Does anyone else have any experience with GamePC that they'd like to share?
Update: Read my impressions of the new computer.
I'm currently helping the Robertson Research Institute convert their large C# Visual Studio .NET 2003 applications to Visual Studio 2005 ("Whidbey") Beta 1. For the past year-and-a-half, we've used CruiseControl.NET (CC.NET), NAnt, NUnit, and FxCop to automate our build, unit testing, and static code analysis. Now that we're running under the .NET Framework 2.0, we'd like to leverage the MSBuild tool in our processes (unfortunately, the most recent version of NAnt doesn't understand the new file formats). Fortunately, the new formats can be directly consumed by MSBuild.So, I spent some time today trying to figure out how to get the latest versions of these tools to work together. Although I wasn't able to achieve a perfect solution, I did find a configuration that is workable until CC.NET adds native MSBuild support. Here are some of the ideas I considered:
Because I wanted a simple solution, I decided to try the commandLineBuilder. Additionally, since the CC.NET team is already planning MSBuild support, it should be an easy transition when the new feature finally arrives. So, the setup I'll describe uses NUnit 2.2, FxCop 1.30 for .NET 2.0, and the latest nightly build of CruiseControl.NET.
Before you do anything else, you should modify your NUnit 2.2 configuration file to prefer the .NET Framework 2.0. You'll need to do this for CC.NET to successfully run your unit tests. Open the nunit-console.exe.config file and find the following section:
<startup> <supportedRuntime version="v1.1.4322" /> <supportedRuntime version="v2.0.40607" /> <supportedRuntime version="v1.0.3705" /> <requiredRuntime version="v1.0.3705" /></startup>
Then, move the version 2.0.40607 element to the front of the list and save:
<startup> <supportedRuntime version="v2.0.40607" /> <supportedRuntime version="v1.1.4322" /> <supportedRuntime version="v1.0.3705" /> <requiredRuntime version="v1.0.3705" /></startup>
As a side note, if you plan to use the NUnit 2.2 GUI for manual testing, you'll have to make the same change to the nunit-gui.exe.config file.
MSBuild scripts can range from the very simple to the very complex. For this example, we'll stick with something easy. Whether you know it or not, the solution and project files that Visual Studio 2005 produces can be directly fed into MSBuild. So, for a solution called Bank.sln, I can build all of its projects by typing MSBuild Bank.sln. Although this works with solution files, they are not actually in the official MSBuild XML format. But, project files are. And the best part is that you can manually modify the project/MSBuild file and Visual Studio 2005 will respect your changes. Okay...I'm getting off-topic...let's get back on track...
If you don't want to run FxCop analysis as part of your CC.NET build, you do not need to create your own build file. However, if you'd like to include FxCop analysis, you can create your own build file in the same directory as your solution file. For example, I created the following Bank.msbuild file:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Target Name="Build">
<!-- Clean, then rebuild entire solution --> <MSBuild Projects="Bank.sln" Targets="Clean;Rebuild" />
<!-- Run FxCop analysis --> <Exec Command="FxCopCmd.exe /project:C:\depot\Bank\Bank.FxCop /out:C:\depot\Bank\Bank.FxCop.xml" WorkingDirectory="C:\Program Files\Microsoft FxCop 1.30" />
This file has a single target called Build. The first thing it does is call MSBuild on the Bank.sln file. The Targets attribute says that we'd like to execute the Clean task first (which deletes all of the old build output), then execute the Rebuild task. I run Clean so that there are no old files from the last build left sitting in the output folders. It can be confusing if your build fails but the unit tests pass. This is usually because the old unit test assembly is still hanging around from a prior successful build. Using Clean eliminates that problem.
Next, the Exec command executes FxCop. I have it execute against an FxCop project file, but you can call it directly against an assembly if that works better for you. I've directed the output to an xml file that will later be merged into the build and NUnit output so it can be reported by CC.NET.
Now we need to tell CC.NET to call our MSBuild file (or, if you don't need to run FxCop, you can directly call the solution file). Although there are many sections in the ccnet.config file, these are the elements that we're interested in:
<build type="commandLineBuilder"> <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.40607\MSBuild.exe</executable> <baseDirectory>C:\depot\Bank</baseDirectory> <buildArgs>Bank.msbuild /p:Configuration=Debug</buildArgs> <buildTimeoutSeconds>60</buildTimeoutSeconds></build> Notice that instead of using a build type of NAnt, we've specified the commandLineBuilder. This allows us to call anything we'd like at the command line. The baseDirectory points to the directory containing the Bank.msbuild file that we created earlier. The buildArgs specifies the name of the build file and any other command-line options we'd like to send to MSBuild. If you don't plan to run FxCop, you can simply call MSBuild on the solution file by replacing the buildArgs with the following line:
<buildArgs>Bank.sln /t:Clean;Rebuild /p:Configuration=Debug</buildArgs>
Since our MSBuild script doesn't get the latest source from the source repository, you'll want to let CC.NET do it by setting autoGetSource to true in your sourcecontrol tag.
To run the NUnit tests, use the nunit task by specifying the path to the NUnit console application, and list the assemblies that you'd like to test. Because we're using CC.NET's nunit task, we don't need to worry about merging the test output (like we might normally have to do if we were using NAnt).
<tasks> <!-- No file merging necessary if using CC.NET's NUnit task --> <nunit> <path>C:\Program Files\NUnit 2.2\bin\nunit-console.exe</path> <assemblies> <assembly>C:\depot\Bank\BankTest\bin\debug\BankTest.dll</assembly> </assemblies> </nunit> <!-- Merge FxCop output --> <merge> <files> <file>c:\depot\Bank\*.FxCop.xml</file> </files> </merge> </tasks>
Last, we do need to tell CC.NET to merge our FxCop output. This lets us see the FxCop detail on the CC.NET web site.
Although this isn't a perfect solution, it's a great temporary solution that doesn't take a lot of effort. By using this configuration, you'll be able to use MSBuild, run your NUnit 2.2 tests, and leverage the latest version of FxCop all under the control of CruiseControl.NET. The only downside is that—because CC.NET doesn’t know how to capture useful build output from the commandLineBuilder—you won't see your build warnings and errors in the CC.NET e-mail or on the web site. Although this sounds like a show-stopper, you can use the original log link on the web site, and it is trivial to quickly find the last failure.
If you're curious about MSBuild, you can find a three-part MSDN article here, here, and here. If you'd like to know more about CruiseControl.NET, continuous integration, and the Ambient Orb, check out my other article.
For those that requested some fall-themed macro photos for wallpaper, here you go. They're not quite up to my normal standards, but I have a feeling you'll like them anyway. Each image is 1280 x 1024 and weighs in at around 230KB in size. I hope you enjoy them.
By the way, if you missed the first two sets, check out Macro Wallpaper and Macro Wallpaper 2.