Matevž Gačnik's Weblog

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

Download this.

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.

This has to be one of the best written analogies between current framework use cases ever.

We indeed are in a state of using ANYTHING that can make our developer lives easier, no matter what the consequences are. An often times, consequences manifest themselves in increased costs, time-to-ship prolongation, complexity and speed.

Go read it. It's worth way more than the time spent.

Well, as more news bubbles up, there's a couple of things the 'Origami consortium' should do:

• It should pull a Steve Jobs on Origami: "... and it's available today for $X99."
• It should NOT discuss the follow-up models. I just do not want to know that in 6 months a better Origami will surface. One with a keyboard and 12 hour uptime, for example.
• It should make sure that the Xbox 360 launch does not replay itself in terms of market congestion.

Tommorow at 9-12AM GMT a new Origami video will be available on Channel 9. I'm watching that space.

Juval Lowy, a fellow RD, posted a complete and compatibile Visual Studio 2005 schema for February 2006 CTP of Indigo (WCF).

Download here.

Copy it to Visual Studio Schema directory: c:\program files\microsoft visual studio 8\xml\schemas.

I wonder how he did it.

After several weeks of me following the Origami story, I'm now really dazzled.

Tried everything to find more details. RD/MVP channel is numb. The web is full of speculation. Nobody knows the details - it's being kept as a real secret.

Now, if Scoble says it's good, one has to concur. I'm so jazzed up, I'm thinking of buying one even if it sucks cat's eyeballs.

Is just can't suck that bad. It has to be something worth spending money on. I'm seeing it in person in Hannover, later this week.

Here you can find today's source code I did on SLODUG (Slovenian Developers User Group):

SLODUG_Feb2006_WCF.zip (39,67 KB)

It's an Indigo service with a corresponding client. It uses three different endpoints with separate transport semantics.

If you've got 10 minutes and want to read a couple of pages, this is a must read.

There is so much difference between how Jobs and Gates do presentations. If you haven't seen one of them yet, there are many (Gates CES 2006 speech) options (Apple MacWorld 2006).

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.

Just a day after my 'Sparke in CTP form' wishes, they came true.

Microsoft Expression Interactive Designer (codename Sparkle) is out (January 2006 CTP).

Get it here and have fun with real Avalon capabilities.

This is a little application I wrote to demonstrate some of the abilities of WPF framework, It's got all the necessary animations in the selection ListBox and also a full blown picture viewer.

Run it in a command prompt, preferably in a directory which includes pictures (.jpg, .bmp, .gif).

You need December 2005 or January 2006 CTP of WinFX Runtime Components and a good graphics card.

Download:

• Executable
• Source

Screenshot:

The WPF (read Avalon) application and programming models are just beautiful.

Having the ability to display the same markup in a standalone app or a web browser based app is fantastic. HTTP deployment scenarios are a snap (if you can figure the damn MIME types out).

Having said that, there are still major issues with the "Cider" designer, which shipped in December 2005 for the first time and resurfaced in January 2006 CTP (release notes here).

For it to be of any use, there are currently a couple of major disadvantages (yes, it's a CTP):

• It does not support (or has really limited support) to include external classes that one would want to use in a rich client, Avalon application. The following mapping PI <?Mapping XmlNamespace="my" ClrNamespace="MyNamespace" Assembly="MyDLL"?> breaks the designer and if one needs to include the class inside XAML, one needs to put it in a directory behind environment variable CIDER_MAPPING_DLL_DIR.
• There's no support for generating event handler implementation methods automatically. There's even no double clicking on the components one has drawn on the design surface.
• There's no ability to delete a component using a designer, once it's been drawn. You have to delete the approprite XAML block in an XML editor.
• Certain container components (like System.Windows.Controls.WrapPanel) do not allow a component to be draged (drawn) inside itself. You have to manually move the appropriate XAML block inside the <WrapPanel> element.
• There's no way to display a custom user control inside the current build of "Cider" designer. You can, however, display any Page, Window and Panel based components.

I'm wondering when Sparkle (Microsoft Expression Interactive Designer) is going to be updated to the latest WPF bits so it could work with 2.0.50727 and December 2005/January 2006 WPF. We need it as a CTP. Hell, if you're at it, release the complete Expression suite in CTP form.

Note: December 2005 and January 2006 bits of WPF should be binary compatible. I hope that this is a first indication of stabilization process starting. There's just too many products that rely on WPF rendering engine for it to be volatile.

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.

A fantastic presenter, but an even better friend had a news year's day epiphany.

It came out as a resolution: 'I should start blogging'.

Dušan Zupančič, welcome to the blogosphere. Keep those <asp:*> tags flowing..

There's a nice little (and dangerous) tool present in every .NET Framework SDK.

It's called corflags.exe. If you run it, you might get something like this:

C:\corflags testme.exe

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  2.0.50727.42
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 1
ILONLY    : 1
32BIT     : 0
Signed    : 0

What this tells you (via the CLR Header) is that testme.exe assembly hides a .NET Framework 2.0 compiled code. All 2.0 framework code will have 2.5 header version, while all 1.0/1.1 compiled code will have 2.0 header version. It's a bit of a mess, but noone can change history.

Next important value is PE. It tells you whether this assembly is a 32-bit or 'any cpu' compiled assembly. If PE value should be 'PE32+' than you could conclude that this is a 64-bit capable assembly.

The 32BIT property, contrary to its name, does not represent bitness of the assembly. In this case, 32BIT property holds a value of 0, which would mean that this is a 64-bit assembly. Actually this assembly can be run anywhere, since it was compiled with agnostic setting of 'any cpu'. If I wanted to, I could turn this knob using the following:

corflags.exe /32BIT+ testme.exe

Now, this assembly would always execute under WoW64 (emulated 32-bit environment on a 64-bit box). In a case where this execution would not be possible - ie. run against an ia64 box - one would get a BadImageFormatException exception.

There is no way (for now) to demand execution in a 64-bit process because this thing is not controled by a metadata flag. Rather it's controled at compile time and compiler has to emit PE32+ compatible code.

Recap: CLR Header property denotes compiler version which was used to produce the assembly. PE property tells you whether this assembly is either 32-bit (PE32), 'any cpu' (PE32) or 64-bit (PE32+). If the 32BIT property is set it mandates execution in a 32-bit process, if the platform allows it.

If you happen to be in the 64-bit world (read running a 64-bit OS on the x64 box, not IA64), there are two options on how your managed code runs.

It can run:

• In a 32-bit process (loads x86 CLR)
• In a 64-bit process (loads x64 CLR)

The high order bit here is the flag under which the image was compiled. Since you cannot compile for 64-bit architecture in .NET Framework 1.0/1.1, and 2.0 is your only choice, let's focus on Visual Studio 2005/.NET Framework 2.0 features.

If you look under the hood on a x64 box, you will find that VS 2005 installer will drop TWO frameworks on your machine.

The 32-bit framework will install in c:\windows\microsoft.net\framework directory, the 64-bit framework will install in c:\windows\microsoft.net\framework64 directory.

If you installed .NET Framework SDK, you will get two SDKs too. One will be in c:\program files\microsoft.net\sdk\v2.0 64bit (64-bit), the other in c:\program files (x86)\microsoft visual studio 8\sdk\v2.0 (32-bit, installed in VS 2005 base directory).

What happens at load time is the CLR runtime host decides on which CLR it needs to load based on the CLR metadata flags. Normally, if you do not change the defaults in VS 2005, your assemblies will be compiled using the 'anycpu' (also known as MSIL flag) which will allow the runtime to host the managed app in a 64-bit process on a x64 box and in a 32-bit process on a x86 box.

You can, however,  control and override this default behaviour even after your code has been compiled. There's a handy tool called corflags.exe present in the SDK that allows you to force 'anycpu' compiled code to use 32-bit process in 64-bit world.

More on that in another blog entry.

My old laptop died on me this past weekend. Even though it wasn't much of a machine lately, it was dependable to the very last moment, when it decided to stop working completely. Dell Inspiron,  RIP.

My new workhorse is a fabulous machine: Acer Ferrari 4005 WLMi

It's a 64-bit machine, based on AMD Turion 64 processor. It looks splendid, although I have to admit that if it would be possible, I would remove the Ferrari logo during my meetings - even though I am a Ferrari F1 fan.

I'm running Windows Vista December CTP x64 edition, including VS 2005 + .NET Frameword 2.0 x64, WinFX RTC December CTP x64, Windows SDK x64, etc.

Running Indigo in a 64-bit process is a breeze. :)

Anyone deciding between Pentium M and Turion 64 based machine should read: Clash of the Titans: Dothan vs. Turion

The article compares Intel Pentium M 760 (Dothan) and AMD Turion 64 ML-37. It's a great article considering the shift to 64-bit is currently underway.

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.