Wandering in the land of .NET

Mouse Gestures for Windows

2004-04-22T13:30:00.000+01:00

StrokeIt is a fantastic free piece of software that I just found: It allows mouse gestures in all of your Windows applications.

If you've never tried Mouse Gestures, you are really missing out. Essentially you hold down the right mouse button, draw a shape on screen, and "some action" happens depending on how you configure it.

It's great for UI-intensive tasks, such as designing orchestrations or web browsing, as you can quickly and easily close windows/run explorer and so on without needing to either aim at small screen icons or have a hand permanently at the keyboard, freeing it up for other handy things such as holding a cup of tea while you work.

Current favourite gesture (I could make this a feature?) are drawing "E" for explorer and "C" for close window :-)

Download it now!

Tickling the Scobleizer

2004-04-20T13:07:00.000+01:00

Ever given anyone a good soul tickling?

Now's your chance. Anyone interested in reading one of the best bloggers in Microsoft should check out The Scobleizer's blog which manages to be both content-rich and a highly entertaining read.

User Interface Process (UIP) Application Block - Version 2.0

2004-04-20T10:44:00.000+01:00

Microsoft have released the User Interface Process (UIP) Application Block Version 2. This application block lets you separate out your UI code from your UI navigation code by using a config-driven navigation/workflow system.

I've been using version 1 quite extensively on a project in my day job, and an in-house framework that was pretty similar at my previous company and I recommend you take a look at it if you have any kind of halfway-complex or repeating navigation/workflow.

One caveat - the back button support isn't quite as good in v2 as it could be. V1 had some serious issues with the back button for which I released a fix on the Got Dot Net community workspace. Having had a quick glance at the v2 source, I'm pleased to see that it looks like they've fixed one of my biggest gripes - namely that an out of order post back used the wrong controller - however three key issues are still present:

- You can't use the same ASP.NET page as the basis for multiple views
- Out-of-order postbacks of the same ASP.NET page are not detected as being an out of order postback
- Out-of-order postbacks (when detected and explicitly allowed) are potentially sent to the wrong nav graph.

In detail, it detects back-button usage by comparing the System.Type of the posted back page with the System.Type of the most-recently-rendered page and uses this to figure out the page's view name. This is where we hit the first issue: You can't have multiple views defined with the same underlying page. I use this scenario quite extensively when I want to have a common page which renders subtly differently in different contexts - for example on a customer details screen the page checks if it's the "new customer details", or the "amend customer details" view, and adjusts itself accordingly. Yes, I could infer this from the NavGraph but then the UI code becomes aware of the navigation, instead of only caring about its own state.

Secondly, the post back is handled by the most recent navgraph. Hence if your view is used in multiple navigation graphs (eg the 'new customer' and the 'amend details' nav graphs) then you're going to suddenly launch into the wrong navgraph if you use the 'back' button to get to a view used in an old navgraph. The UIP block does check that the view exists in the current nav graph, which seems to me to be a half hearted compromise. If you are doing context-sensitive navigation - for example by having a 'next' button for new customer but an 'update' button for amendments then Stuff will still break.

Finally, and as should be obvious from the above, the system can't detect that you're an out of order postback when you use the back button and post back a page of the same System.Type as the most recently rendered page.

So all in all the V2 release is better than the V1 release in terms of back button support, but still leaves a lot to be desired for my particular scenario. I'll try to get an enhanced back button support release together for V2 as soon as I can.

Google's Secret Sauce

2004-04-08T08:35:00.000+01:00

Aaron Skonnard's* blog has a fascinating link to an article about Google and their server architecture. Can they really have 100,000 servers? Wow... The story is well worth a read for any tecchie.

* I once was lucky enough to get taught a Developmentor XML course by Aaron, he's a great guy. I didn't quite appreciate how high profile he was at the time, shame, but I did tell him about this 'typical British humour' page. With hindsight, "Oh, the shame!"

The Register

2004-04-06T09:30:00.000+01:00

Urk! What a hatchet job on The Register's layout. I'm sure it'll grow on me in time...

BizTalk Server 2004 Documentation Online

2004-04-06T09:25:00.000+01:00

Sweet - the BizTalk Server 2004 updated documentation is available online.

Merge Modules and Web Project Installer

2004-04-05T13:31:00.000+01:00

It seems that if you include a Merge Module in an ASP.NET Web Installer project and leave the Module Retargettable property on the default setting of 'bin', you will get a Windows Installer Error 1606 "Could not access network location \bin" when you try to uninstall or upgrade the package.

To ensure you don't get this problem:
Highlight the merge module in your installer project
Expand the 'Merge Module Properties' node in your properties window
Change the 'Module Retargetable Folder' from 'bin' to '(Default)'

Now your web apps should roll on and roll off.

If you have already deployed your application with this broken method and are having problems you can butcher the registry to remove Windows Installer's knowledge of the package. You can Google for the "proper" way to do this - my solution was removing some registry keys under HKLM\Software\Microsoft\Windows\CurrentVersion\[Uninstall|Installer].

Disclaimer: If you hack about with your registry, you may well break your system. Of course you *are* using VMs for testing your install, right?

BizTalk Server 2004 Rollup Package 1

2004-04-05T08:47:00.000+01:00

Microsoft have released BizTalk Server 2004 Rollup Package 1 - it's good to see a relatively quick release to address some of the problems even if it's questionable that some of them ever made it into a release product...

BizTalk 2004 Documentation and other goodies

2004-04-02T09:29:00.000+01:00

When they said that the BTS2004 documentation would be available on the 2nd, I assumed they meant 23:59 PST, but no it's with us now! Thanks to Jan Tielen's excellent blog for the heads-up (specifically this post).

The documentation is here.

Orchestration naming conventions

2004-03-30T09:30:00.000+01:00

Scott Colestock's blog has a good post on the subject of Orchestrations, some interesting non-development ways to use them, and a reasonable set of naming conventions.

Well worth a read.

Slow Web Service calls

2004-03-25T13:32:00.000Z

Yesterday I had a problem with web service performance when calling a Windows 2003 ASP.NET Web Service from BizTalk 2004, both on the local network. My initial call to the web service ran really, really slowly - several tens of seconds. Subsequent calls to the web service ran quickly for a time, then if left alone a later call would again run really slowly.

My initial guess was that ASP.NET was taking an age to initialise the App Domain for the Web Service so I used the ANTS Profiler to examine what was happening. Surprisingly it wasn't anything to do with the Web Service itself - it was when the back-end tried to opening the first connection to our Sql Server. Subsequent calls ran quickly as they picked up the pooled connection, with the later performance spike obviously happening when the pool was empty.

After some playing around I found the problem: It seems that if you make a trusted connection using the IP adress of the server in your connection string, "something somewhere", probably a reverse DNS lookup, takes a very long time to complete. There are two solutions:

1) Use explicit username/password and leave the IP address, or
2) Switch to using the hostname with trusted connection.

Both restored performance to the expected level.

This KnowledgeBase article, FIX: Connection to SQL Server Database Using IP Address Is Unusually Slow, describes the problem exactly but supposedly should have been fixed by Sql Server Service Pack 2 and a MDAC 2.6 service pack. Since we are on Sql Server 3a and MDAC2.8 I'm surprised this was the problem, but I guess nothing to do with MDAC should really surprise me.

Have trouble with connection strings?

2004-03-24T16:27:00.000Z

Every now and then you come across a gem of a website that does exactly what it says on the tin.

http://www.ConnectionStrings.com is one of these if you have trouble remembering the exact connection string format for various data providers.

Microsoft hit by record EU fine

2004-03-24T12:16:00.000Z

Well, Microsoft has been hit with a record EU fine of 497m euros. Ouch. I'm ambivalent on the subject of Microsoft's bundling of "Non-OS" software in Windows but with tongue firmly in cheek I'll say that they deserved it - Windows Media was an abomination up until version 9 ;-)

Wouldn't it be nice if now MS have to provide "Rip to MP3" plugins for WM9 and if Apple were forced to open up their iPod API so that I didn't have to keep iTunes and Windows Media in sync?

Windows 2003 Event Log Security

2004-03-24T09:02:00.000Z

Just a little gotcha that I discovered the other day. When working with ASP.NET, IIS anonymous access and <identity impersonate="true"> on Windows 2003 you will find that you don't have permission to write to the Event Log.

The 'usual suspects' for this kind of problem are file permissions on c:\windows\system32\config, registry key access permissions, .NET CAS, or the RestrictGuestAccess registry key. None of these is the problem.

The real answer lies with Windows 2003 security: It has a new ACL for Event Log access not present in other versions of Windows. Look in HKLM\System\CurrentControlSet\Services\Eventlog\Security\CustomSD - this controls who can and cannot access the Event Log.

A full description is at this Microsoft Support article.

I found people with this problem all over the newsgroups but nobody with a solution, so I hope this helps.