I've mentioned in the past that I've experimented with a number of different options for styling and syntax highlighting code snippets on this weblog, with varying degrees of success.

For a few months I've been using CSS-based syntax highlighting based on the code generated by Vim's :TOhtml command, and it's been working out pretty well. It means that my RSS feed doesn't have any color, but at least the code itself is correctly formatted.

The part I didn't enjoy too much about :TOhtml, however, was that it would only generate the minimum number of style rules it need to highlight the piece of code it was generating the HTML for. This works fine in many scenarios, but it was annoying for me because it meant I needed to continually update my site code.css file as new rules were generated for new snippets that I didn't have in there before.

So what I really wanted was a way to convert the Vim colorscheme of my choice into a CSS useful for my site. Naturally, I turned to PowerShell and came up with convert-vim2css.ps1:

It's not very fancy and it only supports GVim schemes, but that's enough for me and does the trick for now.

Vim, PowerShell

Yesterday on my post about mice, I mentioned that I was still seeing a little problem with my new mouse:

For some strange reason I haven't been able to figure out, however, I'm still seeing moments where the mouse will stop responding (stop moving) for short periods of time.

It now appears that I found the cause of the problem: I had the wireless receiver of the mouse connected to one of the USB ports on my Dell UltraSharp 2208WFP monitor.

As soon as I plugged the receiver directly into one of the USB on my latop, the problem went away. It's not all that surprising, since I had already noticed problems before when I tried Natural Ergonomic Keyboard 4000 connected to the monitor: keys would randomly repeat in very inconvenient ways!

It would appear then that either the USB ports on my monitor have some issues that cause devices to function incorrectly (possibly a timing problem?), but not sure if it's a general problem with this monitor line or if it's a problem with my unit specifically.

Mouse, Dell

The two previous mice I've using lately are my trusty Microsoft Trackball Explorer, which, though a bit old, still works flawlessly, and a Wireless Notebook Presenter Mouse 8000.

I just recently gave up on the Trackball explorer for a simple reason: Pain. I'm not a very heavy gamer, and most of the games I own are fairly old ones, but the problem with the Trackball Explorer is that I end up doing too much effort with my thumb, causing a nasty pain in the thumb muscle.

The Notebook Presenter Mouse is great in idea: Bluetooth, has 5 buttons and the control/presentation buttons on the lower side are great for controlling your media player. I don't even have much of a problem with its small size. However, the mouse has several really annoying features:

• The wheel is too soft and has almost no feel to it, which makes it hard to actually control scrolling.
• The position of the buttons 3 and 4 is, well, just useless. Pressing them requires twisting your hand in extremely unnatural positions.
• The mouse isn't very precise. In fact, I strongly suspect mine is possessed or something becomes it sometimes goes wherever it wants instead of where I'm trying to move it to.
• It would occasionally stop responding for 1-2 seconds, which was extremely annoying. This might be a problem with my laptop's bluetooth radio, though, so it's hard to say.

I just got a new Microsoft Natural Wireless Laser Mouse 6000 (who comes up with these names?!?), and I'm trying to get used to it, but to be honest, I still don't know if I really like it.

The mouse has a different feel to it because of it's shape. It's a lot taller, almost like a ball, in a way, which forces your hand into a different position than the previous mice I owned.

Basically, instead of your hand being more or less parallel to the table, it's in a more natural position inclined to one side. It feels reasonably comfortable for the fingers and the arm, but I've already discovered something I don't enjoy about it: I have a really crappy way of using the mouse and I've always tended to drag the lower part of my hand and rest it behind the mouse.

I know I shouldn't do this (mostly) but it's an habit that's hard to break, and hasn't really caused me much trouble in the past. With the Laser Mouse, however, it has now become a problem.

The reason is that with the new position, it means that if I rest the lower side of the hand on the pad, the hand doesn't rest on one side only, which puts all its weight right on the bone, where I don't have much muscle to cushion it. So it's now a bit painful. I'm now going to try and find a mouse pad with some wrist protection and I'm hoping it will significantly improve this.

There are some things I did like quite a bit:

1. The mouse wheel feeling is a lot better than on the Notebook Presenter and even than the previous Laser Mouse 6000. However, I still hold the opinion that the mouse wheel was a whole lot better on the old Microsoft mice when it "clicked" and presented certain resistance to scrolling. I just haven't been able to really like the "soft" wheel movement in the several latest incarnations.
2. The weight: The new mouse is a bit heavier than previous MS mice I had. Surprisingly, it doesn't seem to cause any problems for moving it, and feels more "solid".
3. The overall feel of the mouse is pretty good. Like the other Microsoft laser mice I've used, it is a bit too sensitive for my taste, but it's not bad.

For some strange reason I haven't been able to figure out, however, I'm still seeing moments where the mouse will stop responding (stop moving) for short periods of time. It's not the surface I'm using, of that I'm sure, so I'm starting to suspect it is something in my Vista installation that's causing the trouble or interference of some kind. If anyone happens to have any idea as to what it may be, it would sure be appreciated.

Microsoft, Mouse

Some readers of this blog might have noticed that my posting frequency has been somewhat reduced during the past few months. Some of this is the result of working on several different projects, some of which isn't stuff I can talk about much.

Besides my usual .NET/BizTalk work, I've been increasingly spending time working on some Java stuff as well. I would say that I probably spend my time 50/50 between both technologies nowadays. There are good and bad things about this, but that's a topic for a different post.

One of the interesting things I've worked on lately on the Java side has been  implementing custom Binding Components based on the Java Business Integration (JBI) specification. JBI isn't a new technology; it's been around for a while, but until now I had not had the opportunity of working with it.

Mostly, I've been working with Sun's OpenESB, which is actually not that bad, though I've also used JBoss/ServiceMix a bit.

It took me a little while to fully grok the core of the JBI model. There are many similarities in the concepts it uses to other messaging technologies, but the terminology used can be somewhat different, which can be confusing sometimes. In case you're not familiar with JBI, it defines two different kinds of components developers might wish to implement:

• Service Engines, which are just components that do some processing and send and/or receive messages.
• Binding Components, which are mostly transport-level adapters. These are the equivalent components in JBI to BizTalk adapters and WCF's transport channels.

I'm not going to do a comprehensive comparison of JBI to BizTalk or WCF, but did want to make a few observations about some aspects that I found interesting.

Abstraction

The JBI spec is a fairly low-level specification. Much of the spec is really concerned with how components interact with the JBI server and how class loading and deployment work, as opposed to defining a more higher-level messaging model.

Actually, maybe I should say that the JBI spec doesn't really define abstraction layers. It's all a single layer that addresses a number of different concerns.

Most of the JBI messaging model is really defined to match the WSDL model, and there are advantages and disadvantages to this. On the plus side, the WSDL model is generic enough to be useful in a broad set of scenarios, and it is fairly well known. It also makes a lot of sense considering the terminology used throughout the spec (once you get familiar with it).

On the bad side, it means that components also have to get intimate knowledge of the WSDL contract model and this forces some compromises I personally don't quite agree with.

For example, in WCF and BizTalk, if I'm writing a transport-level adapter/channel, I may need to be intimately aware of the contract definition being used by the client/server. But it's not really necessary most of the time, particularly when you're working with network-level transports. Mostly, you care about the Message Exchange Pattern (MEP) that the contract demands.

In JBI, however, you have to understand the entire contract. This might be fine for Service Engines, but it can be rather inconvenient for Binding Components, as now you have to figure out out how to map contract operations to your transport, and even how to marshal data back and forth based on the contract definition.

Configuration

This leads me to my second gripe about JBI: Configuration.

Endpoint configuration in JBI is done through a combination of two things:

• The WSDL that defines the contract you'll want to receive or send messages to (extended with your binding component specific port/binding/operation configuration data)
• The deployment descriptors which tell your component if you want to receive or send messages for the corresponding WSDL file.

In reality, WSDL permeates the entire JBI development experience, including how messages are represented internally between the JBI runtime and binding components / service engines.

A huge downside of this, though is that the code needs to "understand" the contracts being used, so parsing the WSDL files and extracting your component's configuration data is your responsibility. Libraries like WSDL4J help, but it can still be a drag.

What does really irk me a bit about JBI though is not that you have to manually craft WSDL files (not that it's a lot of fun). It's that the JBI spec doesn't address the design time aspect of JBI components at all besides, you guessed it, manually crafting WSDL files and deployment descriptors.

So if you're creating JBI components and want a decent design time experience, then you need to target each different server/tooling specifically. For example, for OpenESB you'd craft a custom NetBeans module, while for another tool you'd do something different. It's just not nice.

What's worse is that some servers decided this model wasn't good enough either and added their own configuration models for components and contracts. For example, while ServiceMix supports the stuff mandated by the JBI spec, it also supports an alternative XML-based configuration syntax. While it's more compact, it's hard to argue it really is a significant improvement.

Encoding

This is one aspect where I thought the JBI spec really blew it. As I said above, the JBI spec uses an XML representation for messages internally, that matches the WSDL message definition (parts and all).

There's no layering here that allows binding components to worry about sending and receiving messages without really caring about message contents. They have to care about the message contents and how to map that to however that message was defined in the contract WDSL definition. This might mean looking at which parts are defined and how to break the message down to them, or how to decode complex XSD types defined in the contract.

Instead of being delegated explicitly in the spec to separate components, it's all the responsibility of the binding components themselves. The obvious benefit of having this layered would've been more reusability of said encoding/decoding components, particularly if a minimum set of encoders were mandated by the spec.

Just to take one example: basic XML encoding/decoding is such a basic part of the system, that it's just really odd each component writer gets to redo it from scratch."

I think this is one aspect that BizTalk in particular gets very right. WCF does keep encoding/decoding an explicitly separate task, even if transport channels are responsible for using the encoders directly, but it is still a much better solution than what JBI came up with.

JBI, Java

I've been spending a bunch of time today doing some customization of some ASP.NET custom controls (yes, I know!). One of the things I needed to get working was decent design time support for a property of the control that returned an array of a simple custom structure.

This should've been simple, but it took me a far longer time than I expected to get working correctly. Getting the basic design time work done wasn't too much of a problem; since the property type was an array and not a custom collection, the default editors did the right thing and offered a good design time experience out of the box.

However, you still need to provide the designers and ASP.NET a way to store the property contents as an string, so that you can use markup to specify the value of the property.

Time to write a TypeConverter! I went ahead and wrote a simple TypeConverter that would take a string and return an array of structs based on its contents, or take an array and return a string based on the values in it. Nothing fancy.

I then enabled the type converter by using the TypeConverterAttribute on the property declaration:

Once I added this, the designer worked right away. I could change the array contents in the designer, and it would get serialized into the aspx page markup correctly. Loading the page worked as well and all values would be correctly deserialized.

I thought I was home free until I tried to actually build the ASP.NET site (this was on a VS WebSite, not a Web Application Project). As soon as the ASP.NET compiler tried to compile the ASPX page hosting the control, it would error out with the dreaded error message:

That's it. No stack trace, no more details at all. I knew it was related to the TypeConverter, but that one was working correctly (already tested and verified). Checking further, I came to the conclusion that the error would appear every time that my TypeConverter.ConvertFrom() implementation would return an array with a non-zero size (useful, huh?).

So the array conversion was working perfectly, but ASP.NET was choking on the values contained in the array. At this point I realized the problem wasn't with the TypeConverter itself, but with how the ASP.NET was manipulating the values returned to generate the code from the ASPX page.

After much head-scratching and finding little explicit documentation about the issue I ran into this documentation piece on MSDN. The last section in the article talks about how "To implement a type converter that produces constructor-based property initialization code".

Based on that, I wrote my yet another custom TypeConverter that, following the guidelines on the article, implemented ConvertTo to convert from a MyStruct value to a corresponding InstanceDescriptor object. I applied this second TypeConverter to the struct declaration itself:"

And lo and behold, this time it worked perfectly: No complication errors anymore! Hopefully, next time I run against this and have forgotten again all about TypeConverters and its brethren, I'll remember to look here for hints .

ASP.NET, TypeConverter

The Windows SDK Team blog has posted an open question about some potential features of future SDK releases and is gathering our opinions about it. I'd like to comment a bit on them and provide some feedback.

There are 9 areas the team is looking for feedback on. Let's consider each one:

1. A new, small download of “Core SDK” components is made available to customers, with only the basics.  What components should be included in this product in addition to the Windows headers and libraries?

I think the idea of offering smaller download options is a good one overall, and one that a lot of people (myself included) have asked for a number of times in the past. It's true that the special web downloader/installer we had in the past allowed you to download just parts of the SDK, but it just didn't work sometimes at all, and it was too rigorous in enforcing dependencies that might, or might have not, applied to your specific needs.

However, I disagree on what the contents of the "Core SDK" should be. To me, the most important part of the SDK nowadays is not the Windows headers/libraries, but the SDK tools. Hence, I want the minimum download option to be just the tools. The headers/libraries package should be built on top of the tools package, not the other way around (which is what has happened some times in the past).

My justification for this is that the SDK tools package today is very relevant to all SDK users; both .NET and Win32/64 developers. The headers/libraries package, however, is only relevant most of the time to the second camp.

2. PowerShell Build environment. The Windows SDK would include a script similar to SetEnv that users could run, which will set up an SDK build environment under PowerShell.

I've already said in the past I think this is an excellent idea, which I fully support. For now, I make do with my own custom version tailored to some particular needs of my dev environment.

3. Quick method to install “only .NET” or “only Win32” components.  For example, Win32 developers could quickly choose to receive only Win32 resources in the documents, tools, samples, etc.  Developers focused on managed code could choose to receive only .NET Framework resources in the documents, tools, samples, etc.

I guess this might be a good choice for many people, but to be honest, it's not one I'd particularly use much.

4. Improvements to documentation: better Table of Contents, better filters, search, etc.

Improved documentation is always welcome. The table of contents is the main entry point into it for a lot of people, so organizing it better would definitely be beneficial.

As for the rest, search and filtering really depends a lot on the underlying medium that hosts the documentation itself (the offline help viewer or the online MSDN site), so not sure what the SDK team can actually do to address those issues.

On the face of this, I'd say just focus on improving the content itself.

This does remind me of something: The current local help viewer MSDN uses (and many of the dev-side tools) is not something I'm particularly fan of. I was around when the original HtmlHelp engine was introduced and replaced the old Infoviewer that MSDN/Technet used, and was one of those that complained a lot about it.

I now long for the good old days of HtmlHelp. For example, I've seen the BizTalk SDK docs (which usually ship in the current help technology) in the old HtmlHelp format, and damn, it was way better/faster than what we have now. That sucks.

5. Improvements to documentation: integrate the SDK docs with MSDN docs.

We've had integration between the SDK docs into the MSDN docs in the past. In fact, I'm somewhat surprised it isn't now (I haven't installed either MSDN or the SDK docs in years!).

I used to think this was a good idea; I'm not so sure anymore. Two things come to mind:

• MSDN is already huge, and somewhat bloated. Adding the SDK docs on top isn't going to improve the situation. In fact, considering point 4 above, integrating them is going to make search and filtering them even harder/worse.
• The MSDN/SDK docs integration we had in the past had one significant flaw, in my humble opinion: It tried to integrate the SDK table of contents into separate sections in the MSDN TOC. So if you opened the standalone SDK help, you'd see all the SDK content grouped together, but if you launched the MSDN docs, there wasn't a single place in the TOC where the entire SDK content was hanged of. Annoying as hell.

The second point, in particular, brings up one question: Do we really want them integrated, or merely accessible from a single place?

6. Ship a new “Tools Explorer” to group the tools and provide a more friendly and efficient way for users to search and use the SDK tools.

Not interested. Keep the SDK lean and mean and get it back into shape.

7. Ship a new “Samples Explorer” to group the samples and provide a more friendly and efficient way for users to search and use the SDK samples.

Not interested on an offline tool for this. I think there might be some use for this as an online tool where I could look for a sample and quickly get the code just for that specific sample, instead of having to download the entire SDK samples package (which is huge) to find it.

8. Windows SDK in non-Visual studio IDEs. Provide additional support for other IDEs, such as Windows SDK integration with non-Microsoft development environments, links to Windows SDK documentation from within other IDEs (Eclipse, IBM VisualAge for C++, Borland’s C++ Builder), among other possible integration scenarios.

Haven't been using them at all, so I'm not qualified to really talk about it. I do believe that, for the most part, the SDK should be completely independent of VS and should be usable in a standalone fashion.

9. Create a new Download portal with SDK ‘nuggets’ so that you can download small packages – perhaps a popular tool or file that shipped broken or was missing from a released SDK.

Might be a good idea, but if you're going to do it; do it right and stick with it. The SDK has seen as many changes in installer/downloaders as name changes, and it's a drag.

Don't get me wrong, it's OK to change installers if they bring a significant improvement to the SDK user, but I've never really found that obvious during the several last installer changes. I'm sure each one might have improved something for the SDK team, but from where I'm sitting, it's just been an annoyance to me without bringing any benefits.

It does bring up the question of just what exactly the SDK needs an installer for, besides just registering environment variables and creating the start menu entries...

Windows SDK

A few days ago the second beta release of Vim 7.2 came out and I decided to give it a try. Seems to be working great so far, and I'm pretty excited about this release for a couple of reasons:

1. Performance Improvements: Under Windows, Vim 7.1 had some  performance problems, particularly related to redrawing the screen. This was particularly noticeable when scrolling large windows with syntax highlighted code with the mouse wheel, and when redrawing the [omni-] completion menu.
   The former feels much snappier, even with long lines, while the second appears to be fixed altogether!
2. Floating Point support: I don't create much Vim scripts myself, but I'm excited by some of the possibilities this opens up for scripts I may use. One example of this is Yukihiro Nakadaira's HueRotation script.

Vim

The DocumentSpec class in the Microsoft.BizTalk.Component.Interop namespace of the Microsoft.BizTalk.Pipelines assembly is commonly used in custom pipeline components (particularly assemblers in disassemblers) to represent a compiled BizTalk schema (a document specification).

This class has one interesting method: CreateXmlInstance(), which can generate an sample instance XML based on the associated schema [1]. Recently I saw a question in the BizTalkGurus forum about how to use this functionality if you had a schema definition with multiple potential root elements.

Turns out its pretty easy, once you understand how DocumentSpec works and how Schemas are compiled into BizTalk assemblies.

The constructor for the DocumentSpec class takes two arguments: The docSpecName (schema name) and the name of the assembly it is defined in.

The clue to support multi-root schemas is that the docSpecName is, in reality, the namespace + type name of the class generated by the compiler when you compile the Schema into the BizTalk assembly. Each schema becomes one class in the generated code.

If the schema has a single root, that's the end of it; All you need to know is that docSpecName == Namespace.ClassName. If the schema has multiple roots, however, each root becomes a nested class within the schema class.

The way to select which root element to use for the sample instance generation, then, is to provide the type name of the root element nested class as to the DocumentSpec constructor instead of the name of the schema class. In other words, in this case docSpecName == Namespace.SchemaClass+RootClass.

[1] One annoyance of this method is that it takes a TextWriter argument but doesn't actually write the generated XML into it; instead it returns a Stream you need to read!

BizTalk Server 2006

I just pushed all the source code for my BizTalk 2006 PipelineTesting library to GitHub. I'll keep this public repository updated whenever I make any changes to the library, so if you're interested in keeping track of the code or forking it, this should make it a lot easier.

You can find the clone URL for the new repository is: git://github.com/tomasr/pipelinetesting.git

Enjoy!

BizTalk Server 2006, PipelineTesting

I spent some time this weekend organizing a few files and source code repositories. As part of this process, I wanted to take advantage of NTFS hard-links and junction points, both of which are supported on Windows Server 2003/8 and Vista.

I had no problems with hard-links at all. I'm using the ln.exe tool from http://www.flexhex.com/docs/articles/hard-links.phtml to create them, and it worked great right from the start (I could also use the "fsutil hardlink create" command).

Junction points, however, gave me quite a bit more trouble. I've used Junction points in the past very successfully. I work with some code bases that for many reasons expect to have certain directories in the C:\ drive, but I keep all my code in the E:\ drive.

For this I've used cross-drive junction points to have the folder in C:\ point to the real folder in E:\ and it's worked great for a couple of years. One other tool I've used for this sometimes is Junction Link Magic.

Yesterday, however, I discovered that on Windows Server 2003, if the junction folder was on the same drive as the target folder, it just wouldn't work correctly. I could create the junction just fine, and I could even see the contents of the directory through the junction using explorer, cmd.exe or PowerShell.

Actually trying to access any of the children through the junction would result in the error:

I tried both of the tools I mentioned before, and it just wouldn't work. I tried creating the junctions from WinServer2K8 (where they worked perfectly) and then using the drive from 2003, and it still wouldn't work. This was easy to test, by the way, since this is a VHD image I share between several virtual machines.

Eventually, fellow MVP Juan T. Libre insisted I tried the linkd.exe tool in the Windows Server 2003 Resource Kit. I was reluctant to it since the other tools could create working cross-drive junctions and I was starting to suspect an OS limitation, but I gave it a go.

Much to my surprised, linkd.exe was able to create working same-drive junction points on Windows Server 2003. My guess is that there's some (probably undocumented) detail about how the APIs need to be called that can affect whether this works correctly or not.

Looking at the junctions using the "fsutil reparsepoint query" command clearly shows that the Reparse Data is slightly different between cross and same drive junctions, but not sure what it means from the API point of view. Just something to watch out for.

The lesson: Use linkd.exe on Windows Server 2003 to create same-drive junctions.

Windows Server 2003, NTFS