Vlad Hrybok's Tech Notes

I thought I knew ASP.NET. I started ASP.NET programming in 2001, and I started it with customer/server control development and was cranking them out with no problem. So theoretically I should not have struggled for six hours with a CompositeControl not being able to save nested controls' state between postbacks.

All it came down to is calling EnsureChildControls() from the OnInit().

[ToolboxData("<{0}:BogusCustomControl runat=server></{0}:BogusCustomControl>")]
public class BogusCustomControl : CompositeControl
{
    Button btn = new Button();

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);

        this.EnsureChildControls(); // << This is it! This makes ViewState work for a CompositeControl
    }

    protected override void OnLoad(EventArgs e)
    {
        if (!this.Page.IsPostBack)
        {
            // Set value once to test whether it's preserved between postbacks
            this.btn.Text = DateTime.Now.ToLongTimeString();
        }

        base.OnLoad(e);
    }

    protected override void CreateChildControls()
    {
        this.btn.ID = "whatever";
        this.Controls.Add(this.btn);

        base.CreateChildControls();
    }
}

HttpVPN™, a redistributable component for hosting web applications targeting home users and small businesses, is released as Beta. It makes web applications accessible on the web at MyOwnSecureWeb.com right after the installation and does not require users to fiddle with routers, set up DMZ, etc. Just a consumer-friendly, secure self-hosting of web apps.

In general, I love Microsoft development tools. The reason I never felt compelled to venture far into either Java or LAMP world is because combination of the Visual Studio, .NET Framework runtime, SQL Server and other MS tools has always been an extremely strong development platform, both for the value delivery for end users, and for something as prosaic as having fun programming 8 hours day in and day out. Therefore, it's borderline pathological that Microsoft HTML editing tools have not evolved beyond "D-" grade since their first tool I tried over a decade ago, Front Page 98. Consider this, I am taking a short break (to vent my dissatisfaction) from writing content for a web site because when I edit an HTML file using Visual Studio 2008 SP1, it mangles the HTML by cutting up closing tags, turning "</a>", "</h3>", "</span>" and others into ">". I thought, alright, Expression Web 2 is going to save the day. I open the page in the Expression Web, and what I found is that it doesn't handle keyboard key strokes well, ranging from failing to respond to arrow keys, to Ctrl+V shortcut for Paste simply not working, rendering Expression Web unusable. I use Microsoft keyboard and their drivers. I am a developer, not a designer, but if getting such basic functions as arrow keys in their editor is impossible for MS, what chances do they have with professional designers? And don't get me even started with Expression suite not supporting MS own source controls for two versions. Microsoft's inability to get HTML design tools right for such a long time creates a fear that MS is losing it.

It all started with a need to use TimeZoneInfo class of .NET Framework 3.5. My ASP.NET application, however, was of ASP.NET 2.0, even though I develop it in Visual Studio 2008. Since moving from ASP.NET 2.0 to 3.5 should be pretty easy, I promptly switched target .NET Framework to 3.5 in the project settings, recompiled and ran it without a problem - at first. Suddenly, one page failed with "control with id 'whatever' requires a ScriptManager on the page", while ScriptManager was already there - set at the master page level. Googling provided solutions that didn't work.

What it turned out to be is that my old AjaxControlToolkit version was apparently incompatible with .NET Framework 3.5. Once I got Ajax Control Toolkit made specifically for ASP.NET 3.5, my pages started working properly.

I had this seemingly simple task yesterday: populate TreeView control (ASP.NET) with data from SQL Server 2005. The query returning data from SQL Server was spanning three joined tables with one-to-many relations, returning the denormalized set of records that has some redundancy due to information from parent tables replicated in each record (like having Company and Department information in each Employee record). Populating hierarchical TreeView from flat recordset is pretty inconvenient, so I decided to give a shot to the XML output feature of SQL Server 2005.

Converting flat denormalized result set output into hierarchical XML was as easy as adding "FOR XML AUTO" to the end of my query. I ran the query and the output was exactly what I wanted - no redundancy at all, with child records neatly nested inside the parent table XML nodes (for proper record nesting be sure to use correct order of the selected columns: parent table columns should precede child table columns in the T-SQL SELECT statement). Now I needed to bring this result back from SQL to the business tier of my C# application. I extensively use DataSets with the the convenience of built-in data-access methods created using DataSet Editor's query wizards. I right-clicked an appropriate table adapter and went through the "Add Query..." wizard, mapping my new stored procedure returning XML to the new data access method. At the end of the wizard "Tabular Data" option for the query result type was understandably grayed, because XML is hierarchical, not tabular. But generated method turned out to return Object type, and you would never know it unless you looked at the generated source code - properties of the generated methods do now show the return type of the method. I test-ran the method and it turned out to return what you would expect - XML text with all the data.

One could stop digging right here and simply use XmlDocument and XPath to parse out and the walk the XML, populating tree nodes in the process, but I wanted to turn XML data into a strongly-typed hierarchical structure instead of walking XML nodes. In .NET all you need to turn XML into a strongly-typed structure is XML schema. A nice little utility called xsd.exe converts XSD schemas into C# or VB.NET classes, which are XML-serializable. SQL Server 2005 is sweet enough to generate schema, along with bringing the XML data. I temporarily modified my query to have "FOR XML AUTO, XMLSCHEMA" appendix, ran it in SQL Server and got the XML preceded by the schema. I copied schema over to an XSD file and undid the change to the query, reverting the appendix back to "FOR XML AUTO".

Now, having created XSD schema defining XML structure returned by my query, all I needed to do is to feed the XSD file to XSD.exe utility to produce C# file with classes corresponding to m XML nodes, right? Almost. This was the part where things stopped going smoothly. First, xsd.exe complained, as it always does, that it could not find sqltypes.xsd schema, which is imported by the schema produced by SQL server. If you ever used either xsd.exe or wsdl.exe against schemas that import other files, you probably know that all the imported files need to be downloaded and saved locally, and in the case of xsd.exe, all imported schemas should be explicitly listed in the command line. Here's the example of xsd.exe command line (run Visual Studio Command Prompt to load command prompt window with all environment variables set):
   xsd.exe yourschema.xsd sqltypes.xsd /classes /namespace:WhateverIsYourNamespace
This command will produce yourschema_sqltypes.cs file with strongl-typed C# classes wrapped into the WhateverIsYourNamspace namespace. If you expect to simply include this file into your project and rejoice at this point, not so fast. Although the code will compile, at run time using XmlSerializer.Deserialize() produced odd results - it complained that my root element with xmlns='' attribute was not expected. That was because schema got the default name when it was generated by SQL Server, while actual XML data did not reference the schema at all. To fix that I had to remove XmlTypeAttribute and XmlRootAttribute attributes from declarations of the generated classes. I had to keep XmlRoot attribute for the class representing root node, by its declaration was simplified to look like [System.Xml.Serialization.XmlRootAttribute(IsNullable = false)].

Once that part was done, deserialization of XML into strongly-typed hierarchical data structure started working just fine.

One more quick note: when .NET classes are generated from XSD schema, nullable data fields get done in a slightly different way compared to the DataSet. In the dataset, you'll get "type<Nullable>" or "type?" declaration for nullable data columns of value types (int, DateTime, etc). .NET classes generated by xsd.exe won't have nullable fields. Instead they will have extra boolean fields telling whether the field is nullable. For example, if your SQL data table has nullable BirthDate, the C# class produced by xsd.exe will have boolean BirthDateSpecified property, which does what BirthDate.HasValue would do in the dataset.

The whole process was not terribly smooth, but also not prohibitively burdensome. Of course, much better design would be if Microsoft allowed to specify XML schema for the TreeView control, and then to let data-bind the TreeView control to a SQL query or an object method that returns XML. This way it would be still strongly-typed, but the whole business of building XML-serializable C# classes out of the schema would not be necessary. This approach would also allow design-time definition of TreeView node formatting, just like GridView does it with strongly-typed datasets. Another useful feature would be automatic generation of C# classes - just like generation of strongly-typed datasets - for data-access methods returning XML.

Since I use ASP.NET HTTP handlers quite often, I decided to figure out what advantages IHttpAsyncHandler has compared with IHttpHandler. As I looked at many people's claim that IHttpAsyncHandler somehow magically improves performance by shifting request processing on to another thread, I realized that MSDN documentation of IHttpAsyncHandler is laking in a fundamental way: it fails to mention that simply moving request rendering onto another thread does not yield any benefit.

When you simply move your request handling logic from the original ASP.NET thread to your own thread (IHttpAsyncHandler), you gain exactly nothing because both threads come from the same pool. The benefit of IHttpAsyncHandler comes in only when your request processing thread is blocking, waiting for another thread. For example, if your request processing calls a web service, your request processing thread will wait for the IO completion happening on another thread - where request is sent to the web service. In this case there will be two threads involved: your request processing thread, and the IO thread where outgoing web service request is being executed. This is the situation where IHttpAsyncHandler can help: instead of holding on to the request processing thread while waiting for the outgoing request to complete, one can release the original request processing thread back to the pool, and finish response rendering on the IO thread after the web service request has completed. This way, instead of holding two threads for the duration of the relatively long-running process of invoking a web service, your request processing is using only one thread.

So, the bottom line is this:
- You should only concert yourself with IHttpAsyncHandler if you are running out of request processing threads.
- If you do, check your logic for whether it's waiting for an IO completion (or is using other threads for other reasons), and only if that's the case, switch to IHttpAsyncHandler.
- Otherwise simply increase the size of the ASP.NET thread pool in the web.config and stick with good ole' IHttpHandler.

Microsoft marketing folks are incorrigible. When explaining new technology they invariably fail to make anything any more clear. Case in point: Microsoft Azure. Parsing through the Azure site left an impression that MS don't really want anyone to find out what in the world they are really doing.

For those who don't have time to filter through MS marketing noise, consider reading this very concise, pretty funny even if somewhat crude-worded Windows Azure review:
http://www.theregister.co.uk/2008/11/03/dziuba_azure/print.html

Update: This white paper penned by David Chappell is most to-the-point Azure doc so far.

Update 2: Azure pricing information.

It's much easier to read large numbers when thousands are separated by commas. But I can never remember how the numeric format with thousands comma-separated is defined for .NET String.Format() method and for the databinding. So more as a note to self, here it is:

string output = string.Format("{0:#,#}", 123456789); // Will produce 123,456,789

The same goes for data binding data sources to data controls like DataGridView. Specify format as "{0:#,#}".

If your ASP.NET 1.1 or 2.0 application throws "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms" exception, the easiest way to fix is to add 
      <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>
line to the <system.web> section of the web.config file of your application.

FIPS compliance is required for software installed on US government computers. The compliance requirement can be turned on and off.

Source: http://support.microsoft.com/kb/911722

Upgrading or replacing a motherboard on a machine running Windows Server 2003 (in my case it was Windows 2003 R2 Standard Edition with Service Pack 2 x64) is relatively straightforward, and more or less works as described in the MS Knowledge Base article: you start upgrade process by running Windows setup while old motherboard is in-place, and once upgrade process reboots the machine, you intercept it by turning the computer off and replacing the MoBo, and then allow upgrade process to continue. It worked alright, and wasn't too long a process.

What the KB article didn't mention is that after the upgrade a few things may be broken or missing. In my case there were two big things broken:

• IE was corrupted in a way that prevented downloading files by clicking a link. Page browsing still worked and "Save target as..." worked, but clicking a link that redirects to a file download resulted in the strange error message: "The requested look-up key was not found in any active activation". My way to fix it was to upgrade IE6 to IE7, but since IE7 download links were those redirect links that didn't work, I had to install FireFox, which had a link accessible via "Save target as", and then I used FireFox to download and install IE7.
  
  
• .NET Framework 2.0 has disappeared, wracking havoc making pretty much all applications (SQL Server Management console, ASP.NET apps in IIS) not working. Fixing it was not too bad though - I downloaded and installed .NET Framework 2.0 x64, then made a couple of runs of Windows Update to ensure the server won't try to reboot soon after being brought online, rebooted the machine just in case, and that was it.

Overall entire process, although not completely seamless or worry-free, took only about an hour, not counting time required to physically replace the board.

After installing Visual Studio 2008 on a new machine and starting playing with a simple Windows Communication Foundation project, I attempted to change service's WCF settings using WCF Service Configuration Editor utility (SvcConfigEditor.exe). However, I got the "Windows SDK is not installed correctly" error. "Internets" were surprisingly mum on the subject, so I had to figure out the solution myself.

To fix the problem, I had to install Windows SDK 6.0 manually. After I did that, the problem went away. Just quit Visual Studio 2008 before installing Windows SDK.

Update: Even after reinstalling Windows SDK, first time right-clicking on the web.config in the Visual Studio '08 Solution Explorer does not bring "Edit WCF Configuration" item to the menu. However, after I did Tools | "WCF Service Configuration Editor", "Edit WCF Configuration" item started showing up upon right-clicking the .config file.

When ASP.NET 2.0 and Visual Studio 2005 came out I hoped that ASP.NET themes will be developed en masse by third parties and sold like those on TemplateMonster.com. Today, tired of ugly GridViews in my apps, I decided to find an ASP.NET theme for at least a GridView, but to my surprise, the only thing I found was this, which is not even a skin. There are millions of sites, books and blogs telling how to make themes in ASP.NET 2.0, but it looks like market for third-party templates has never materialized. Given how fierce the competition in the graphics & UI design world is, I wonder why everyone is missing a chance to take this niche. Microsoft has a few starter themes, but just a few and without live test-drive sites - one has to download and install Visual Studio plug-ins and build the site to see it in action. All this is very strange: it's hard to believe there is no business model in making skinnable themes for ASP.NET applications.

After releasing build 1.7 of my open-source redistributable ASP.NET-based MP3 player application, I used it for a while and I am pretty happy with its stability and functionality. The design goal for the project was to demo a concept of an easily-redistributable web application for SOHO market. With unquestionable popularity of web-based applications in the business world, removing complexity of the web hosting infrastructure to make home web applications possible as a category is poised to be the next big thing.

MS AJAX is great, but if you wanted to make an installable application with it, there was no way of including AJAX into your MSI-based setup project. I made a Visual Studio manifest that makes MS AJAX Extensions a Visual Studio Setup Project prerequisite:

To AJAX-enable your existing ASP.NET 2.0 application follow this video. It takes only a few minutes and essentially makes you create a dummy new Ajax-enabled ASP.NET application and then copy & paste relevant pieces of its web.config file into your application's web.config.

If you are planning to use Ajax Control Toolkit, then instead of creating dummy project from the "ASP.NET AJAX-Enabled Web Site" Visual Studio project template, create the dummy project using "AJAX Control Toolkit Web Site" template. Its web.config has additional entry in the <controls> section of the web.config that will be necessary for your application.

Although usually I prefer to make a clean installation of a new OS to lose all the junk accumulated since last OS upgrade, this time I decided to upgrade our family Media Center box instead, because unlike my desktop the MCE box has just a few basic server apps, like IIS, email server, ORB, WebGuide, and of course MCE 2005.

Overall, upgrade was a success, but most of the drivers and applications had to be either upgraded or reinstalled. There were quite a few things to take care of:

• Running Vista Upgrade Advisor was a good idea. It tells upfront which drivers, services and application will not, or may not work. The most important thing it told me was that I don't have enough space on drive C:, so since it was still an XP I used Norton Partition Magic to increased the C: partition size by 25 GB. I also downloaded some Vista drivers before starting the upgrade just in case my network card would not work after the upgrade.
  
  
• Although ATI Catalyst software was not among those Vista Upgrade Advisor suggested to remove, the screen resolution settings were not preserved by the upgrade process. Moreover, standard MS ATI driver didn't support resolutions required by some HDTV sets. I had to visit ATI web site and download the latest driver and the Catalyst software. Once I've done that I was able to adjust the resolution back to what it used to be.
  
  
• MCE settings partially survived. Scheduled series settings carried over fine, but Signal settings and Guide had to be specified again by going through the setup wizard. I had my recorded TV shows location in XP MCE changed from the default. While new MCE in Vista has found them, I still had to specified the location for new recordings. Thankfully, it was easy - the UI allowing to change the location of newly recorded shows is built into Vista's MCE app. Pictures and Music location settings have carried over with no problem.
  
  
• The hardest part was to revive ASP.NET applications and sites after IIS was upgraded from IIS5 on XP to IIS 7.0 on Vista. The hardest problem was that caused by the remnants of some old version of .NET Framework 2.0. That caused application pools hosting .NET 2.0 to crash hard on the very first request while spitting out strange errors, like "The worker process failed to pre-load .Net Runtime version v2.0." to the application log. It took me two days of Internet searching to find the solution.
  
  ASP.NET 1.1 applications were also all not working. I had to run aspnet_regiis.exe from the 1.1 Framework to bring them back to life.
  
  In many cases I had to manually ACL folders containing ASP.NET applications with access rights for "NETWORK SERVICE" user account. I also had to change anonymous authentication account from IUSR_whatever to appPool identity.
  
  The bottom line is migration of ASP.NET web apps was not trivial.
  
  
• Both Orb and WebGuide stopped working after the upgrade. I upgraded ORB with no problem and uninstalled the WebGuide so I could install Vista-specific version of the WG. It all went fine - that's after I was done fixing all the IIS7 glitches.
  
  
• dasBlog 1.9 - the software running this blog - ended up being incompatible with Vista. I had to move this blog to another server running good ole' Windows 2003/IIS 6.0. After moving the app to another server, which was free of surprises, the final challenge was to redirect links going to old blog location pointing to IIS7/Vista to the new one. Unlike IIS6, IIS7 does not have a UI where you could choose "A redirection to a URL" as a destination for your virtual directory. Redirection in IIS7 can be done but it requires running a command-line utility. Fortunately that worked.
  
  
• Unlike IIS, UltiDev Cassini Web Server underpinning WebGuide4 went through upgrade precess as smooth as it can be.

Summary

UPDATE: This sample is an open-source project now.

This article describes how to build a redistributable ASP.NET application that allows users browse remote server's file system and pick folders with MP3 files to be played by embedded Macromedia Flash-based MP3 player.

Article Sources

Download article's C# source in a form of Visual Studio 2005 Solution comprising ASP.NET application and a Setup Project. Unzip the archive to "C:\".

End Result

  

After building the project you will have an MSI-based setup package that can be installed on virtually any Windows-based PC. Installed application will be accessible from inside the LAN as an intranet application without having to install IIS.

Prerequisites

- Visual Studio 2005.
- UltiDev Cassini Web Server for ASP.NET 2.0. UltiDev Cassini is packaged together with the application into the Setup.exe so that the final application would not depend on IIS being present on target system.

Let's Begin (Getting Ducks in a Row)

A few weeks ago I stumbled upon a great piece of free software:Flash-based XSPF-compatible MP3 player. When embedded on a page, it can take playlist over HTTP and play it. Second nice thing was that XSPF play list format has XSD schema available. .NET Framework xsd.exe utility allows easy conversion of XSD schemas into C# or VB.NET classes incapsulating the structure of the data defined by the XSD, as well as implementing XML serialization to and from XML files conforming to the schema. So I had an XSPF-compatible MP3 player and a free code generating XSPF-compatible XML. That meant I could easily create XSPF-compatible playlists on a fly. Only if I had free ID3 tag (MP3 file metadata) access API...

Finding ID3v2 library for .NET was harder than I expected. However search was ultimately successful. The UltraID3Lib ended up being just what I needed. It's a nice library; may be just be a bit over the top object-oriented.

Final piece is UltiDev Cassini Web Server for ASP.NET 2.0. It's necessary because first, it can be packaged and shipped along with any ASP.NET application eliminating requirement for IIS. Second, unlike IIS UltiDev Cassini service works under "Local System" account, which enables access to any local file and folder on the server. One thing to note, while this is quite convenient to have a web server running under powerful account, it may pose a risk if the application is exposed on the web. It's best to work with the application inside protected local area network.

After you have downloaded the solution, unzip it on C:\. It will create "C:\UltiDevMusicPlayerSample" folder. If you want to put it in some other folder - you can do that too - simply adjust your project debugging settings later to point to the correct application folder (see below).

Application Flow

- Application has a single page (Default.aspx) containing the player control and file a system browser (Controls/PlayerControl.ascx and Controls/PlayerControl.ascx.cs).
- After user selected a folder with MP3 files, file system browser tree gets hidden and player control is re-rendered to point to the dynamically-generated playlist representing selected folder.
- Player control requests dynamic playlist and custom IHttpHandler (AppCode/PlaylistClass.cs and AppCode/xspf.cs) serves XSPF-encoded playlist containing songs in the selected folder. Playlist contains song information retrieved from songs' ID3v2 and ID3v1 MP3 tags.
- Player plays songs one by one: requesting each one from the custom IHttpHandler (Handlers/Song.ashx) serving songs from local file system. After song started playing player also requests song album artwork (cover art) from custom IHttpHandler (Handlers/CoverArt.ashx) which serves image extracted from song's ID3v2 tag.

Debugging

I had troubles getting Visual Studio 2005 internal web server to serve Flash component. I switched to UltiDev Cassini for debugging and that has solved the problem. Debugging with UltiDev Cassini is probably a good idea anyway since the application is eventually going to run under UltiDev Cassini.

To switch to UltiDev Cassini, bring up ASP.NET application's properties, select Start Options of the left, and check "Start External Program" radio-button. Enter "C:\Program Files\UltiDev\Cassini Web Server for ASP.NET 2.0\UltiDevCassinWebServer2.exe" as the program to be used for debugging, and specify "/run c:\UltiDevMusicPlayerSample\WebApp Default.aspx 4125" (no quotes) as command line arguments. If you have unzipped solution to a folder other than "C:\", then you will need to modify c:\UltiDevMusicPlayerSample\WebApp part of the command line arguments to point to the actual application location.

Setup Project

Unlike regular ASP.NET application, this application is using regular (non-web) setup project for installer implementation. The reason for that is the Visual Studio web setup project is actually IIS setup project. Since we are using UltiDev Cassini instead of IIS, regular setup project is required instead.

Setup project packs UltiDev Cassini into Setup.exe bootstrapper and ensures application is registered with UltiDev Cassini during installation process and gets unregistered during uninstallation.

Creating a setup project for ASP.NET application bundled with UltiDev Cassini is not complex, but if you need step-by-step guide, please refer to this walk-through.

IMPORTANT: When installing the application, don't just click the .MSI file. You will need to run Setup.exe to ensure UltiDev Cassini web server gets installed on target system. This is especially true on Vista, where clicking .MSI and running Setup.exe are not nearly as functionally close as it used to be on Windows XP.

Build & Enjoy!

Recently I've been working on the small ASP.NET 2.0 app that has a page containing Macromedia (now Adobe) Flash object. When I tried debugging it with Visual Studio 2005 and its internal web server, the Flash piece has never been loaded by Internet Explorer - I am not even sure whether it was the Flash player that failed to load or the .SWF file. I wonder if anyone else had this issue. I could not check which component was not loaded because WebDev.WebServer2.exe serves only local applications, and I could not use an http tracer to see which request gets stuck.

I worked around the issue by switching to our own UltiDev Cassini for ASP.NET 2.0 for application debugging. It served all the bits and pieces required by Flash without a hitch.

Here's how it works: for the last two years we at UltiDev LLC work mainly on HttpVPN - our flagship product and the main reason why our company exists. Once upon a time we've decided that making a simple redistributable web server software would be a great value-added piece completing HttpVPN offering and allowing us to probe prospective market for HttpVPN, gather contact information of people who may by interested in HttpVPN and setup our QA, build and release processes along the way. The experiment turned out to be as successful and we hoped it would be. We've got about 15,000 (and counting) installed UltiDev Cassini Web Server runtimes worldwide and we are receiving overwhelmingly positive feedback from users. All this also means that about every six months we have our Cassini task tracker full enough to suspend HttpVPN work for a few weeks and do another release or UltiDev Cassini. This time was no exception.

Although we always hope to keep our Cassini mid-version upgrade development cycle limited to three weeks, it took us usual five weeks to fix, test, fix again, test again and release the latest version of UltiDev Cassini Web Server. This release had two main points of focus: to eliminate all known installation/registration hurdles and to make UltiDev Cassini compatible with all 64-bit Windows platforms. 64 bit OSes are gaining popularity very rapidly thanks to the fact that most of the recent (and even not so recent - think Pentium D) CPUs from AMD and Intel are x64-compatible. Windows Vista comes in 32- and 64-bit versions right from the start, while existing Windows XP Pro x64 and Windows 2003 Server 64-bit were somewhat obscure because they were released before 64-bit CPUs hit the mainstream. Nowadays it's pretty much impossible to buy a CPU that does not have x64 compatibility. Hoping to please Vista 32 and 64 bit users we made sure that our latest version of Cassini runs smoothly on all the latest multicore 32 and 64 bit CPUs and supports entire (reasonable) line of Windows operating systems: from Windows 2000 to Vista.

Now, whether you own an older version of our tiny but powerful UltiDev Cassini, or you never tried it - go ahead and download the latest version. If you owned old version - most of the known issues will go away (or if you had none you will be less likely to face issues in the future). If you never saw our Cassini - it's a perfect time to spend 20 minutes on something you probably will go "wow!" about. Check it out now!