Matevž Gačnik's Weblog

These have been brewing for a couple of months. They're out today.

They contain a number of patches that improve fix Vista. You can get them here:

Windows Vista Performance Update:

• x86 Download
• x64 Download

Windows Vista Reliability Update:

• x86 Download
• x64 Download

Go get them. Now.

Based on my previous post, I managed to get distributed transaction scenario working using WCF, MTOM and WS-AtomicTransactions.

This means that you have the option to transport arbitrary files, using transactional ACID semantics, from the client, over HTTP and MTOM.

The idea is to integrate a distributed transaction with TxF, or NTFS file system transaction. This only works on Windows Server 2008 (Longhorn Server) and Windows Vista.

Download: Sample code

If the client starts a transaction then all files within it should be stored on the server. If something fails or client does not commit, no harm is done. The beauty of this is that it's all seamlessly integrated into the current communication/OS stack.

This is shipping technology; you just have to dive a little deeper to use it.

Here's the scenario:

There are a couple of issues that need to be addressed before we move to the implementation:

• You should use the managed wrapper included here
  There is support for TransactedFile and TransactedDirectory built it. Next version of VistaBridge samples will include an updated version of this wrapper.
  
  
• Limited distributed transactions support on a system drive
  There is no way to get DTC a superior access coordinator role for TxF on the system drive (think c:\ system drive). This is a major downside in the current implementation of TxF, since I would prefer that system/boot files would be transaction-locked anyway. You have two options if you want to run the following sample:
  
  
  • Define secondary resource manager for your directory
    This allows system drive resource manager to still protect system files, but creates a secondary resource manager for the specified directory. Do this:
    • fsutil resource create c:\txf
    • fsutil resource start c:\txf
      You can query your new secondary resource manager by fsutil resource info c:\txf.
      
      
  • Use another partition
    Any partition outside the system partition is ok. You cannot use network shares, but USB keys will work. Plug it in and change the paths as defined at the end of this post.

OK, here we go.

Here's the service contract:

[ServiceContract(SessionMode = SessionMode.Allowed)]
interface ITransportFiles
{
   [OperationContract]
   [TransactionFlow(TransactionFlowOption.Allowed)]
   byte[] GetFile(string name);

   [OperationContract]
   [TransactionFlow(TransactionFlowOption.Allowed)]
   void PutFile(byte[] data, string name);
} 

We allow the sessionful binding (it's not required, though) and allow transactions to flow from the client side. Again, transactions are not mandatory, since client may opt-out of using them and just transport files without a transaction.

The provided transport mechanism uses MTOM, since the contract's parameter model is appropriate for it and because it's much more effective transferring binary data.

So here's the service config:

<system.serviceModel>
  <bindings>
    <wsHttpBinding>
      <binding name="MTOMBinding"
          transactionFlow="true"
          messageEncoding="Mtom"
          maxReceivedMessageSize="10485760">
        <readerQuotas maxArrayLength="10485760"/>
      </binding>
    </wsHttpBinding>
  </bindings>
  <services>
    <service name="WCFService.TransportService">
      <host>
        <baseAddresses>
          <add baseAddress="http://localhost:555/transportservice">
        </baseAddresses>
      </host>
      <endpoint address=""
          binding="wsHttpBinding"
          bindingConfiguration="MTOMBinding"
          contract="WCFService.ITransportFiles"/>
    </service>
  </services>
</system.serviceModel>

Here, MTOMBinding is being used to specify MTOM wire encoding. Also, quotas and maxReceivedMessageSize attribute is being adjusted to 10 MB, since we are probably transferring larger binary files.

Service implementation is straight forward:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class TransportService : ITransportFiles
{
    [OperationBehavior(TransactionScopeRequired = true)]
    public byte[] GetFile(string name)
    {
        Console.WriteLine("GetFile: {0}", name);
        Console.WriteLine("Distributed Tx ID: {0}",
          Transaction.Current.TransactionInformation.DistributedIdentifier);
        return ReadFully(TransactedFile.Open(@"C:\TxF\Service\" + name,
          FileMode.Open, FileAccess.Read, FileShare.Read), 0);
    }

    [OperationBehavior(TransactionScopeRequired = true)]
    public void PutFile(byte[] data, string filename)
    {
        Console.WriteLine("PutFile: {0}", filename);
        Console.WriteLine("Distributed Tx ID: {0}",
          Transaction.Current.TransactionInformation.DistributedIdentifier);

        using (BinaryWriter bw = new BinaryWriter(
            TransactedFile.Open(@"C:\TxF\Service\" + filename,
              FileMode.Create, FileAccess.Write, FileShare.Write)))
        {
            bw.Write(data, 0, data.Length);
           
            // clean up
            bw.Flush();
        }
    }
}

Client does four things:

1. Sends three files (client - server) - no transaction
2. Gets three files (server - client) - no transaction
3. Sends three files (client - server) - distributed transaction, all or nothing
4. Gets three files (server - client) - distributed transaction, all or nothing

Before you run:

• Decide on the secondary resource manager option (system drive, enable it using fsutil.exe) or use another partition (USB key)
• Change the paths to your scenario. The sample uses C:\TxF, C:\TxF\Service and C:\TxF\Client and a secondary resource manager. Create these directories before running the sample.

Download: Sample code

This sample is provided without any warranty. It's a sample, so don't use it in production environments.

I dived into WS-Management support in Vista / Longhorn Server Windows Server 2008 this weekend. There are a couple of caveats if you want to enable remote WS-Management based access to these machines. Support for remote management is also built into Windows Server 2003 R2.

WS-Management specification allows remote access to any resource that implements the specification. Everything accessed in a WS-Management world is a resource, which is identifiable by a URI. The spec uses WS-Eventing, WS-Enumeration, WS-Transfer and SOAP 1.2 via HTTP.

Since remote management implementation in Windows acknowledges all the work done in the WMI space, you can simply issue commands in terms of URIs that incorporate WMI namespaces.

For example, the WMI class or action (method) is identified by a URI, just as any other WS-Management based resource. You can construct access to any WMI class / action using the following semantics:

• http://schemas.microsoft.com/wbem/wsman/1/wmi denotes a default WMI namespace accessible via WS-Management
• http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default denotes access to root/default namespace

Since the majority of WMI classes are in root/cimv2 namespace, you should use the following URI to access those:

http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2

OK, back to WS-Management and its implementation in Vista / Windows Server 2008.

First, Windows Server 2008 has the Windows Remote Management service started up by default. Vista doesn't. So start it up, if you're on a Vista box.

Second, depending on your network configuration, if you're in a workgroup environment (not joined to a domain) you should tell your client to trust the server side.

Trusting the server side involves executing a command on a client. Remote management tools included in Windows Server 2008 / Windows Vista are capable of configuring the local machine and issuing commands to remote machine. There are basically two tools which allow you to setup the infrastructure and issue remote commands to the destination. They are:

• winrm.cmd (uses winrm.vbs), defines configuration of local machine
• winrs.exe (winrscmd.dll and friends), Windows Remote Shell client, issues commands to a remote machine

As said, WS-Management support is enabled by default in Windows Server 2008. This means that the appropriate service is running, but one should still define basic configuration on it. Nothing is enabled by default; you have to opt-in.

Since Microsoft is progressing to a more admin friendly environment, this is done by issuing the following command (server command):

winrm quickconfig (or winrm qc)

This enables the obvious:

• Starts the Windows Remote Management service (if not stared; in Windows Vista case)
• Enables autostart on the Windows Remote Management service
• Starts up a listener for all machine's IP addresses
• Configures appropriate firewall exceptions

You should get the following output:

[c:\windows\system32]winrm quickconfig

WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:

Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
Enable the WinRM firewall exception.

Make these changes [y/n]? y

WinRM has been updated for remote management.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.

There are options in winrm.cmd to fine tune anything, including the listening ports and / or SSL (HTTPS) support. In a trusted environment you probably don't want to issue commands using HTTP based mechanism, since you are located behind the trust boundary and have complete control over available (allowed) TCP ports.

You can now issue remote management commands against the configured server, but only if the communication is trusted. So in case you are in a workgroup environment (client and server in a workgroup), this should get you started (client command):

winrm set winrm/config/client @{TrustedHosts="<server ip or hostname>"}

You can specify multiple trusted servers using a comma:

winrm set winrm/config/client @{TrustedHosts="10.10.10.108, 10.10.10.109"}

This trusts the server(s) no matter what. Even over HTTP only.

Enumerating the configured listeners - remember, listener is located on the destination side - is done via:

winrm enumerate winrm/config/listener

OK, now we're able to issue commands to the remote side using WS-Management infrastructure. You can, for example, try this (client command):

winrs -r:http://<server ip> -u:<username> -p:<password> <shell command>, ie.
winrs -r:http://10.10.10.108 -u:administrator -p:p$38E0jjW! dir -s

or

winrs -r:http://10.10.10.108 -u:administrator -p:p$38E0jjW! hostname

You can even explose HTTP based approach through your firewall if you're crazy enough. But using HTTPS would be the smart way out. What you need is a valid certificate with server authentication capability and a matching CN. Self-signed certs won't work.

Simple and effective.

If you happen to be on a Windows Vista or Windows Server 2008 box, there is some goodness going your way.

There is a basic managed TxF (Transactional NTFS) wrapper available (unveiled by Jason Olson).

What this thing gives you is this:

try
{
   using (TransactionScope tsFiles = new TransactionScope
      TransactionScopeOption.RequiresNew))
   {
      WriteFile("TxFile1.txt");
      throw new FileNotFoundException();
      WriteFile("TxFile2.txt");
      tsFiles.Complete();
   }
}
catch (Exception ex)
{
   Console.WriteLine(ex.Message);
}

WriteFile method that does, well, file writing, is here:

using (TransactionScope tsFile = new TransactionScope
      (TransactionScopeOption.Required))
{
   Console.WriteLine("Creating transacted file '{0}'.", filename);

   using (StreamWriter tFile = new StreamWriter(TransactedFile.Open(filename, 
          FileMode.Create,
          FileAccess.Write,
          FileShare.None)))
   {
      tFile.Write(String.Format("Random data. My filename is '{0}'.",
          filename));
   }

   tsFile.Complete();
   Console.WriteLine("File '{0}' written.", filename);
}

So we have a nested TransactionScope with a curious type - TransactedFile. Mind you, there is support for TransactedDirectory built in.

What's happening underneath is awesome. The wrapper talks to unmanaged implementation of TxF, which is built in on every Vista / Longhorn Server box.

What you get is transactional file system support with System.Transactions. And it's going to go far beyond that.

I wrote some sample code, go get it. Oh, BTW, remove the exception line to see the real benefit.

Download: Sample code

This sample is provided without any warranty. It's a sample, so don't use it in production environments.

Four banks. Three types of exchange rates. Two clicks. One installation.

We support four banks:

• Bank of Slovenia
• NLB
• SKB
• NKBM

The same is true for the backend programmatic interface (read SOAP). Here's the service.

Download here:

• Slovenian readers: http://vista.gama-system.com
• English readers: http://vista.gama-system.com?cat=1&lang=eng

Update: Version 1.0.0.1 - EUR bugfixing release available (2007-01-25)

Disclaimer: We are tracking usage. Anonymously of course.

As promised, our second gadget went gold today. We call it Slovenian Portfolio and as the name suggests, it allows you to track your portfolio on LJSE.

Here's the feature list:

• Stock selection
• Stock search on LJSE (Ljubljana Stock Exchange)
• Display of selected stock values
• Display of relative daily changes
• Stock value graphs for the previous week, month, three months, six months and year
• Complete portfolio market value

Again, this Gadget supports English and Slovenian locale too, so fellow citizens should get a nice Slovenian UI when Windows Vista Slovenian MUI ships.

Download here:

• Slovenian readers: http://vista.gama-system.com
• English readers: http://vista.gama-system.com?cat=1&lang=eng

Post about the Slovenian Radio gadget is available here.

Disclaimer: We are tracking usage. Anonymously of course. No financial data is being transferred to our servers.

Today we launched our first public Windows Vista Sidebar gadget.

In v1, we support Slovenian radio stations. The radio station list is centralized (dynamically retrieved), but there is a way to persuade the gadget to use any of your radio feeds, if you know how to develop Windows Sidebar gadgets.

Gadget supports English and Slovenian locale, so fellow citizens should get a nice Slovenian UI when Windows Vista Slovenian MUI ships.

There are more gadgets coming out of our dev labs. Stay tuned.

Download here:

• Slovenian readers: http://vista.gama-system.com
• English readers: http://vista.gama-system.com/?cat=1&lang=eng

Our gadgets are and will be free, so spread the news.

Update: New radio stations available [2006-12-05]

We made a bunch of new radio stations available. Currently we support Radio Antena, Radio Študent, Radio Belvi, Radio Dur, Radio Ekspress, Radio Hit, Radio Ognjišče, Radio Sora, Radio Center (Ljubljana), Radio Center (Maribor), Radio Geoss, Radio Rogla, Radio Capris, Radio Energy, Radio Odmev, Studio D, Radio Robin, Radio Kranj, Moj Radio, Radio Bakla, Radio SiOL and Radio SiOL Klub.

Update: Version 1.0.0.3 available [2006-12-08]

Minor bugfixes and design changes.

Update: Version 1.0.0.4 available [2007-04-24]

Minor bugfixes, default radio list was integrated. Radio list is still dynamically retrieved when there is a new list version available.

Update: New radio stations available [2007-08-06]

We made a bunch of new radio stations available. Currently we support Radio Antena, Radio Študent, Radio Belvi, Radio Dur, Radio Ekspress, Radio Hit, Radio Ognjišče, Radio Sora, Radio Center (Ljubljana), Radio Center (Maribor), Radio Geoss, Radio Rogla, Radio Capris, Radio Energy, Radio Odmev, Studio D, Radio Robin, Radio Kranj, Moj Radio, Radio Bakla, Radio A1, Val 202, Radio Si, Radio Maribor, Radio Koper, Radio Capodistria, Radio ARS, Muravidek Magyar Radio, Radio SiOL and Radio SiOL Klub. 30+ radio stations and counting!

Disclaimer: We are tracking usage. Anonymously of course.

If you haven't installed it yet, do it now.

New York Times Times Reader. Available here. It's a great Vista/WPF application, showing the possibilities of next-gen user experience.

Here's a quick glance of the front page.

Watch out for this, my fellow citizens:

Via ZDNet News.com

The once-daily shiproom meetings have become twice-a-day events as the
product has neared completion. Projected onto a screen is a list of
unresolved issues that need to be addressed before Vista can leave. There
were about five dozen such issues at a meeting last Wednesday morning.

Sven Hallauer, who heads up the process, moved quickly through the list as
about 40 programmers, nearly all with a laptop in tow, worked to keep up. At
each sticking-point, the person responsible for tracking the issue gave a
one-sentence report on where things were.

In one case, there was a bug in the Slovenian release of Vista. It was
quickly tabled as not pressing, given that Slovenian is not in the first or
even second wave of localized versions of Vista. Other reports came in--this
software program has a hitch, this particular laptop has trouble waking up
from sleep.

Huh? It seems we're getting an added value version.

It took a loooong time.

Now, Vista is done.

The OS, including .NET Framework 3.0, RTMed.

This post has been cooking for quite some time, quietly sitting on my desktop. Since Miha started the debate, I'm letting it go...

I've had a pleasure to work with the Acer Ferrari 4005 machine for a while. It was a great machine: AMD Turion 2.0 GHz, 64 bit, 2 GB RAM workhorse. Until I left it on the roof of my car and drove off...

Since then, I've been hammering on IBM Lenovo ThinkPad T60p, same specs, although x86 architecture. This is, in all terms, a great machine.

Having said that, I was running Windows XP x64 SP2 + Windows Vista x64, and Ferrari is actually one of the best machines to be on, when running x64. They have flawless driver support.

Let me get straight to the point.

Current prevailing architecture is x86. It's not going to stay that way for long. In the beginning of next year 99% of machines sold will have x64 support. Core 2 Duo is going to sweep the x86's dusty history.

The problem is, the majority of consumer base will decide by comparison, as always. It's just the magic of numbers, again. Imagine all the talking going on inside different computer stores and online forums, speculating how much better x64 is. In reality, x64 is currently (and for at least a couple of years) not going to be substantially faster - in the consumer space - than x86.

Nevertheless, a lot of people, who will now own the x64 chip, will want to run a x64-based edition of the OS. And here the problem lies.

Consumer Windows drivers have not been known for their robustness in the x86 world. There are devices that have real trouble running on Windows XP x86. Even though Vista will require signed x64 drivers, their availability is subject to questioning.

So the situation is this:

• You get the latest and greatest hardware, including a Core 2 Duo
• You get the latest and greatest software, including Windows Vista x64
• There are numerous well known problems with running apps in WoW, on x64 machines
• Currently, general device support is, well, flawed
• The drivers that exist have not been tested - for the consumer market.

Enterprise x64 market is quite different. There are a lot of production systems running Windows Server x64 successfully.

People are going to be pissed. It's Vista x64 and it is not going to launch successfully to the customer base.

This has bothered me for two weeks. There was no way to install .NET Fx 1.1 on a Vista 5456 box.

Here's the solution: http://blogs.msdn.com/astebner/archive/2006/07/06/658484.aspx

After the permission fix, Framework 1.1 and SP1 for 1.1 install flawlessly.

Thanks Aaron Stebner!

This post will focus on how to enable IIS7 in Windows Vista client and to use it to host a service activated Windows Workflow.

Procedure is based on the current build of Windows Vista (5381.1), which is a RC1 for Beta 2 milestone. Also, WinFX February CTP is used, which includes Windows Workflow Foundation Beta 2.

There are a couple of prerequisite steps necessary to enable hosting, first of all, installing IIS7. Go to Control Panel/Programs/Turn on or off Windows Features and enable 'Internet Information Services':

Installer in build 5381.1 (and 5365) is stable enough to be useful. If you're running a previous build of Vista (5308, 5342) consider installing IIS by running this monster in the command prompt:

start /w pkgmgr /l:log.etw /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

Make sure you also check ASP.NET under World Wide Web Services/Application Development features, since this will install and enable ASP .NET 2.0 under all IIS7 sites. You can also do this later on using aspnet_regiis.exe, but Vista will notify you that the preferred way is using Turn on or off Windows features dialog.

Now, when you have IIS installed run the administrative console inside Administrative Tools and define a web application by right clicking on Default Web Site:

This will allow you to run your workflow as a service inside the default application pool. You can check and notice that default application pool uses a new integrated IIS7 mode and not ISAPI as in IIS5/6.

You're ready to deploy your workflow activated service now. use the steps described in my previous post, under Ad 1.

When you hit the service endpoint you get this:

IIS7 is noticing you that your config files are not compatible with the new hosting model.

You have two options:

• Change the configuration files
• Change the hosting model

You can change the configuration files by running: c:\windows\system32\inetsrv\appcmd.exe migrate config "<Site name>/<VRoot name>". AppCmd.exe is a tool which automatically migrates your old config, to IIS7's new config format.

Another option is that you enable old style ISAPI hosting model inside your application pool that is running your default web site (or another site, if that's what the workflow is supposed to be running under). You can do this either by:

1. Running c:\windows\system32\inetsrv\appcmd.exe set app "<Site name>/<VRoot name>" /applicationPool: "Classic .NET AppPool". This changes the site to use another, preconfigured app pool, which uses ISAPI by default.

Here's a screenshot of the default pipeline modes for IIS7:

2. Changing the hosting model on the current Default Web Site site. You can right click on Application Pools/DefaultAppPool and select Set Application Pool Defaults. Then you change the pipeline mode from Integrated to ISAPI. Here's how you do it:

I prefer going through route 1. Integrated mode is how you should be running your sites under IIS7, so changing the config to make IIS7 happy is the way to go. If you have specific ISAPI functionality (not limited to Workflows) you can, though run in classic mode by designing your app pool around it.

Now your service activated workflow will run and execute under IIS7. Again, beware of the caveats I described here.

Running Windows Vista? Build 5308 (February 2006 CTP)? Got ATI?

Download this.

My current occupation leads me to spend as much time as possible in WinFX.

WinFX should stand for Windows Framework Extensions. What a Windows Framework is, I don't know. I know what .NET Framework is, but that's another drop in the ocean.

Having said that, there seems to be inconsistency between what is, will be or was inside WinFX (or WinFX Runtime Components, if you wish).

In 2003, WinFX (if you were at the majorrevealingconferenceoftheyear - PDC 2003), you would concur that WinFX will be:

• Indigo (related to everything communication)
• Avalon (related to everything presentation)
• WinFS (related to everything storage, somehow)

In 2004 things changed.

WinFX mysteriously dropped WinFS and inherited something called Workflow - Windows Workflow Services (now called Windows Workflow Foundation).

At first, Windows Workflow Foundation was acronymed WWF, which makes sense - you've got WPF (Windows Presentation Foundation - Avalon), WCF (Windows Communication Foundation - Indigo) and WWF (Windows Workflow Foundation - WWF).

It is now 2006 and WWF is acronymed WF (just Windows Workflow) and it is still a part of WinFX. WinFS is still gone (scheduled to be released after Vista ships).

What worries me the most is that the current plan precludes that this technologies won't make it into the Vista ship vehicle. They just won't be deployed with the OS. If you make all the fuss around it, invest major tolars in education budget you still won't be sure that the client supports it.

Windows Installer 3.1 is a wonderful thing, but nonetheless, if anyone can deploy groundbreaking technology in no time it's Microsoft. Sure, there are 'small footprint security implications' guidelines driving Vista, but no one is saying this beast should be deployed in active state. Make it available and make it passive. Support it via Windows Update if showstoppers arise.

There is no need to be scared of another IIS 4 story. There are mechanisms for deploying technology and not using it by default.

Please, do not make WinFX fade.

If you plan to upgrade your WinFX bits with the yesterday released January 2006 CTP of WinFX Runtime Components consider the following:

You do not need to do a fresh reinstall, even though that is what is suggested in the docs:

• Reinstall procedure works on Windows XP SP2 (x86 and x64)
• Reinstall procesure workd on Windows Vista 5270 (December 2005 CTP)

First, uninstall all December 2005 CTP bits in the following order:

1. Visual Studio 2005 Extensions for Windows Workflow Foundation (December 2005 CTP)
2. Visual Studio 2005 Extensions for WinFX (December 2005 CTP)
3. Microsoft Command Shell (December 2005 CTP, comes with Windows SDK)
4. Windows SDK (December 2005 CTP)
5. WinFX Runtime Components (December 2005 CTP)

Then, invert the installation process:

1. WinFX Runtime Components (January 2005 CTP)
2. Windows SDK (January 2005 CTP)
3. Visual Studio 2005 Extensions for WinFX (January 2005 CTP)
4. Visual Studio 2005 Extensions for Windows Workflow Foundation (January 2005 CTP)

For now, I can't see any major differences in programming model of January <> December WinFX CTP.

If you are planning to install or have already done so, there's an issue with the automated install of December CTP of WinFX RC (Runtime Components).

The following link will install November 2005 WinFX RC:

http://www.microsoft.com/downloads/details.aspx?familyid=BD3BA2D5-6ADB-4FB2-A3AA-E16A9EA5603F&displaylang=en

And to make it even more complex, if you happen to install it in Windows Vista December CTP, there is no way to remove it and have a clean machine afterwards.

Use the complete download link, ie:

• x86: http://download.microsoft.com/download/9/4/9/949EEA41-364A-45DC-8F4E-47E7AC147D25/winfxrc.exe
• x64: http://download.microsoft.com/download/8/3/F/83F862AA-FF41-4D54-9567-1F37888A41DB/winfxrc_x64.exe

How do you know if this thing screwed you up? You will not be able to install a 1GB pack of Windows SDK (December 2005), which also includes WinFX docs and samples.

Another proof are filename timestamps of for example System.ServiceModel.dll and friends, which are 11/18/2005 - equaling to November 2005 CTP dates.

If you downloaded Longhorn build 4074 from MSDN Universal Subscription download site, you are missing Longhorn SDK.

Wait. Wait. It's going to be available in a couple of days.