With Windows Vista's release to volume licensees just over three weeks away, Microsoft spent this week accelerating the rollout of what will become the company's key development tools going forward: not the old-school, monolithic Visual C++ and Visual Basic, but instead the newer, leaner, revitalized suite empowering modern applications and Web services.

The .NET Framework 3.0 runtime package has been released, which only makes sense, since Vista development is now essentially done. If you blinked, you missed how Microsoft's marketing scheme was altered: The .NET common language runtime hasn't changed at all: .NET 3.0 actually contains .NET 2.0.

The term ".NET Framework 3.0" was simply co-opted to replace what Microsoft was going to call WinFX. It now includes the principal libraries upon which Vista-oriented development now hinges: Windows Communication Foundation ("Indigo"), Windows Presentation Foundation ("Avalon"), Windows Workflow Foundation ("Windows Workflow Foundation"), and the identity management system CardSpace.

For compatibility's sake, applications that take advantage of Windows Vista (where these libraries are built in) will need to also run on Windows XP and Windows Server 2003. Apparently, the decision was made that it would expedite adoption of these libraries among XP users to treat them as upgrades to .NET 2.0, rather than as a product line unto themselves.

As Maheshwar Jayaraman, one of the developers on the Indigo project, wrote for his MSDN blog yesterday, the final bug fix for WCF ended up being the first one spotted: "Sometime last Friday, amid cheers and high fives," he wrote, "our lead PM resolved the last bug that stopped us from signing off on WCF. Bug # 1 was opened way back when Indigo was in planning stages, and with this bug we signed off on the product."

More importantly for developers, the SDK for these libraries has been released, along with new Visual Studio 2005 extensions that take into account Workflow Foundation, as well as Indigo and Avalon.

Microsoft recommends that users uninstall their betas of .NET Framework 3.0

Yesterday also marked the release of Beta 2 of ASP.NET AJAX, which is Microsoft's implementation of Asynchronous JavaScript. As we reported last month, when Beta 1 was released, the company chose to divide its AJAX components into two packages: one which it would officially support, and a second that would represent a continual development path for features that could be incorporated into future official releases.

With Beta 2, this second package has been given a rather financial-sounding name: "ASP.NET AJAX 2.0 Futures CTP." Here, the version in which these new features would be integrated, is clearly labeled.

As ASP.NET developer Matt Gibbs blogged yesterday, "Some of the code has been around awhile and continues to evolve, while some of what we will include in the Futures CTP may shift more dramatically based on feedback and further scenario work."

There will be notable changes in customs and practices that developers will need to incorporate, even between Beta 1 and Beta 2. Links to documents which list those changes appear on this page.

Finally, Microsoft chose election day in the US to announce what should become one of the key future components of its next generation of Visual Studio, and perhaps the suite's principal "non-open-source" development tool. Called Dotfuscator Community Edition (as though communities enjoy getting together regularly to "dotfuscate" in public), the tool will enable developers to employ encryption and IP protection directly within their source code, for the protection of the code itself.

Dotfuscator CE is a basic version of a commercial product currently sold by Preemptive Solutions, described as a ".NET obfuscator."

As Preemptive's Web site reads, "Unprotected applications can easily be reverse engineered by decompiler tools. Our .NET obfuscator's patented technology counters this threat by transforming applications - renaming identifiers to meaningless characters, obfuscating metadata, and altering control flow so that the obfuscated .NET code is much harder to understand." Not that mis-interpreting Microsoft source code hasn't been enough of a problem anyway.