One of our core products, Gama System eArchive was accredited last week.

This is the first accreditation of a domestic product and the first one covering long term electronic document storage in a SOA based system.

Every document stored inside the Gama System eArchive product is now legally legal. No questions asked.

Accreditation is done by a national body and represents the last step in a formal acknowledgement to holiness.

That means a lot to me, even more to our company.

The following blog entries were (in)directly inspired by the development of this product:

• Laws and Digital Signatures
• Reliable Messaging and Retry Timeouts
• Approaches to Document Style Parameter Models
• XmlSerializer, Ambient XML Namespaces and Digital Signatures
• Security Sessions and Service Throttling
• Reliable Message Delivery
• Reliable Message Delivery Continued
• Durable Reliable Messaging

We've made a lot of effort to get this thing developed and accredited. The certificate is here.

This, this, this, this, this, this, this, this, this and those are direct approvals of our correct decisions.

Third incarnation of the .NET 3.0 Middleware Technologies day went through yesterday.

Here are the deliverables:

• PPT: Download [1]
• WCF Samples: Download
• WF Samples: Download

If you did not get/notice the printed articles, here's what should put you to sleep over the weekend:

• Concepts and Semantics of Service Contracts [1]
• Transactional Semantics in Loosely Coupled Distributed Systems [1]
• Cooperation Between Workflows and Services [1]
• Type Systems Compared - XML <> CLR [1]

Also, the accompanying book is available here.

[1] Only available in Slovene.

I just finished presenting my talk on the October 2006 Slovenian MSDN event.

Here are the deliverables:

Code: Download
PPT: Download [Slovenian]

Solution file includes:

1. WCF service using wsDualHttpBinding for duplex session communication scenario. WCF service hosts a workflow which computes stock tax based on the current (complex) Slovenian legislation.
2. WF workflow named ComputeTaxWorkflow. Workflow calls out to our public ASP .NET WebServices: StockQuotes and ExchangeRates.
3. WCF Client, which sends requests and receives responses when the workflow is done

Check it out. It's free.

Second incarnation of the .NET 3.0 Middleware Technologies day went through today.

Here are the deliverables:

Code: Download
PPT: Download [Slovenian]

Frequent answer still stands. This is the best playground.

Since there is so much interest, we are discussing a third repeat of the series. Anyone who wanted to attend, but did not get a seat, stay tuned.

A long running rumor has been made public a couple of days ago. WinFX name is dead and is superseded by Microsoft .NET Framework 3.0.

A part of me is grateful for being able to have a common name for the shipping technologies. Who wants to be acknowledged as a WinFX developer, when in reality she/he is a .NET developer? The decision to bundle WinFX technologies with Windows Vista and making it available down-level is awesome. Having it included with the .NET Framework is even better.

But there's another poor decision being made by the marketing folks at Microsoft. If this decision wouldn't be rushed, it would have made a wonderful release.

Microsoft .NET Framework 3.0 is ambiguous as a platform name. Since the press release states this explicitly, one can not complain as loudly as the reality demands. .NET Framework 3.0 is the first Microsoft .NET platform release that isn't really a platform - it's a marketing release. There's no CLR 3.0, no LINQ stuff, which was supposed to be in 3.0 release, no ASP .NET 3.0, no ADO .NET 3.0. In reality, there is current CLR 2.0 shipping, together with all the known friends: ADO .NET 2.0, ASP .NET 2.0. It even gets installed in the c:\windows\microsoft.net\framework\v2.0.50727 folder. At least, it's got its own folder inside the c:\windows\microsoft.net\framework directory. It is the 2.0 of the framework including WCF, WF and WPF. Goodness?

There exists a patronizing line of thought that nobody cares about the naming/install coherence and version matching. This is mostly heard from Microsoft, but the development community does not swallow it. The issue does not surface as this, actually.

Putting it mildly, this isn't serious. Suddenly separating CLR and framework version is a hack. A hack done to limit the damage that has already been done by establishing the WinFX bundle name. I'm happy that the LINQ team has not made a 'product name' breakthrough because suddenly we would run out of framework version numbers just to bundle the thing.

How is it possible, even in marketing terms, that .NET Framework 3.0 includes .NET Framework 2.0? What happens when LINQ gets shipped? Do we get CLR 3.0 and .NET Framework 3.5? .NET Framework 4.0? Do they get synchronized again and CLR skips versions? How do you distinguish the framework version? We will not be able to believe the compiler version, CLR version or BCL assembly version. They will all be 2.0.50727, but the framework is versioned as 3.0.

Even corflags.exe will still report a 2.5 CLR Header version, which is a mess even in current, shipping technology stack. It all follows the 'when the shit hits the fan' direction. Let's make it splatter, let's make even more mess.

Where is the compiler version change, runtime version change and metadata format version change? Where's the synchronization?

This is not serious.

Update: 2006-11-08, .NET Fx 3.0 is installed in a separate directory inside c:\windows\microsoft.net\framework.

If you are running WWF (Windows Workflow Foundation, part of WinFX) on a x64 box, and have problems debugging workflows, stop.

It's currently not supported. It should, but does not work yet. This should be fixed already, but it's not. And it will probably get fixed in the next CTP drop.

There is a workaround though:

1. Enter Configuration Manager (Build/Configuration Manager)
2. Select the active solution platform drop down, select New...
3. Select x86 platform
4. Hit OK and try debugging again

This will make sure that you are running your solution debugging under x86 mode and thus allow you to set breakpoints and debug your code.

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.

WinFX January 2006 CTP just went live.

With it, a Go-Live licence is available for WCF and WF. Sign and deploy.

Update: They managed to screw up the download links again. Beware: If you're downloading complete installs (and not the setup manager) use the lower links for x86 and x64 images (there are two on the get the beta page).

The following links will lead to correct complete download of WinFX January 2006 CTP Runtime Components:

• x86: http://download.microsoft.com/download/1/C/E/1CE323BD-3632-45CD-ADB3-61179B033434/winfxrc.exe
• x64: http://download.microsoft.com/download/2/0/6/2065648E-444C-40A6-AE58-3F46FC8E854F/winfxrc_x64.exe

You can also check the file version. The correct WinFX RTC version for January 2006 CTP is 3.0.50727.154 (file size 44.488 KB [x86] and 84.464 KB [x64]). December CTP was 3.0.50727.151 and file sizes were a couple KB lower.

Read this 7 times in a row: "Microsoft® Visual Studio® 2005 Extensions for Windows Workflow Foundation Beta 1.2 for Microsoft Pre-Release Software WinFX® Runtime Components - December Community Technology Preview (CTP)"

Wow.

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.