I was shown a nice little trick today by a collegue who was trying to debug a Windows Installer CustomAction. The problem of course is that you can't debug the code because it is being launched and controlled by the Windows Installer/MSI. The trick is to add the line below somewhere in the code:

System.Diagnostics.Debugger.Break();

When this line is executed an "exception" is thrown, which launches the Visual Studio dialog asking you if you wish to debug the process as there is an exception. Now you can simply attach to your Visual Studio session and debug your code as normal! Nice trick, that after nearly 5 years of working with .NET, I had not come across.

It's worth noting that execution will continue after the Break method is called, so you need to have a normal breakpoint ready when you attach to the VS session.

I discovered today that Microsoft has launched MSDN Wiki . I was using fxCop and reading into some of the details for the rules that it said I was breaking . Normally you are taken to msdn2 help system, but was instead taken to the Wiki version.

The core reference is taken from exactly the same database as all the other MSDN help systems, but currently can only seemed to be accessed via the web site. I've always found the online documentation from Microsoft difficult to search and navigate, so I tend to use the thick client version of MSDN Library. It would be good to be able to link to the MSDN Wiki from the thick client (for online help searches of course) to make it a little better for searching.

All in all, it's such a great idea to be able to amend the documentation. I've lost count of the number of times that the .NET Compact Framework documentation was incorrect, misleading or just plain missing! However, until they make it easier to search, I'll be sticking to MSDN Library, but will be keeping tabs on the blog for updates.

The first Sql Everywhere CTP was realeased early this week which brings the Sql Mobile world to the desktop. Anyone familiar with working with the .NET Compact Framework and Sql Mobile will know the problems creating automated tests for a database application. The fundamental problem has always been that the database needed to be hosted on a device or emulator. Now, we'll be able run and test data access code on the development machine.

All this is great, except that it's not supported for ASP.NET applications! Steve Lasker from Microsoft has a blog post that highlights the design decisions around this, but I can't help thinking that it was a little misguided. What's the problem with a hosted environment? When a website needs to hold only a little content in a db, why should we have to use Sql Express? This is especially a problem in a place like NZ where hosting companies want to charge you a fortune for just 25Mb of Sql space.

Just to make sure, I tried creating and connecting to a database in ASP.NET. Surprisingly it let me create the database but it didn't let be read from it.

I've just added a Swiki to this blog, which is a customised, trainable search engine. Produced by Eurekster (a kiwi company!) it's a community based approach to searching, a portion of which can be embedded in your website.

When you create a Swiki, you create it for a topic, like ASP.NET. From this, a "buzz cloud" is created of keywords that people have used based on this topic, but most importantly, ranks the search results based on what others selected when they performed the search! So, all the good results will filter to the top of the pile. But also, as other people search in your topic area with new keywords, the "buzz cloud" will change, meaning that you can see what's hot and what's not within your topic.

Make sense? ... they have a better explanation on their site . Either way, check it and create your Swiki!

It's taken a while, but I finally found a blogging system that I liked.

ThinkJot is an ASP.NET 2.0 version of the latest release of the dasBlog engine. The reason for the split is that when running under ASP.NET 2.0, your site is running by default under "Medium Trust" rather than "Full Trust", which was the case in .NET 1.1. If you're running on a shared host as I am here, you'll probably find that it is running under the default security settings. No problem you think ... well, try running dasBlog 1.8 under "Medium Trust" and you'll find it doesn't work! It turns out that even things such as the date picker used, did some things that needed to run under Full Trust. For the full story go to the blog.

That's where ThinkJot comes in. It was simply a rebuild and tweak to make it ASP.NET 2.0 and Medium Trust friendly. I pass my thanks on now to the guys at Process64 who did this, you saved me a job!