This is something I always forget how to do. When you use the Response stream to output a file or image, you often want the name of the stream to make sense. That way, if the user tries to save the file or image, the suggested name is what you specified.

Before ending the Response stream, add something like the following:

context.Response.AddHeader("Content-Disposition", "inline;filename=" + _filename + ".png");

I came across the Microsoft Office Live site today, which marks Microsoft's new drive towards an ASP (Application Service Provider) model. The emphasis is on getting small business sites up and running, complete with domain name and email registration, which will be free even after the beta period. This is great news for those businesses that don't know where to start with regards to the web, especially when the domain name registered through Office Live can be transferred if/when they outgrow it!

On top of the basics there are other paid services, based on the Office suite, to aid your business to function. I was particularly keen to try the project and sales lead tools, but unfortunately for myself and other Kiwi's, it's not available this side of the world. Hopefully soon.

A problem I had recently was that a GridView bound to a SqlDataSource was not deleting the records when the Delete command was executed. I've tagged this entry as a "gotcha" as it isn't completely obvious where the problem might be to the uninitiated.

The Delete Sql command was executing fine, but after using SqlProfiler I noticed that the “ID” parameter was set to “Null”, hence the fact that no record was deleted. This was not what I expected as I had used the normal SqlDataSource and DataGrid wizard to set up the controls. What I was missing was setting the “DataKeyNames” property on the GridView to the name of the primary key of my data … “ID”. Now, the SqlDataSource passed through the correct Sql statement and all was good!

I’ve avoided the SqlDataSource/Designer approach whenever possible for the very reason that it’s difficult to see what’s going on when something doesn’t work. I was creating a prototype so time pressures won out and I used it!

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!