Thursday 30 October, 2008 (dasBlog | Fixes | Reviews | Team System | Visual Studio | Web)
I have been messing about with some template experiments in dasBlog using Notepad++ and Visual Studio 2008. That is changing the site layout by editing homeTemplate.blogtemplate, dayTemplate.blogtemplate and itemTemplate.blogtemplate for a dasBlog Theme. These files are basically html files with dasBlog specific macros for inserting the blog functionality.
Notepad++
First off I love Notepad++ as a replacement for Notepad. I have had a hard time doing more complex things in Notepad++ due to my addiction to Microsoft's intellisense... Editing the .blogtemplate files is dead simple in Notepad++ since it is very easy to get syntax coloring - you simply choose a language (html) from the language menu and viola everything is color coded. The file that you are editing doesn't need to have the correct extension or even be written in the language you choose. Notepad++ does its best and highlights whatever it can recognize.
There is also an auto completion function that you access by pressing CTRL+space, but this function is really only a text completion function and does not take any notice of the context that you are typing in. It just pops up an alphabetical list of potential text candidates based on the letters that you have already typed. For simple programming tasks this is more than adequate and Notepad++ does have a significantly smaller footprint than Visual Studio, so you can install it on pretty much any computer or server without anyone complaining for quick debugging tasks.
What I really have been missing is proper html intellisense for the .blogtemplate files.
Visual Studio 2008
Obviously Visual Studio does not have support for the .blogtemplate extension. For awhile I hacked my way around it by renaming the files to have a html extension while editing, which sort of works. The main problem is that I keep forgetting to change the extension back before I start testing my changes - so this was causing unnecessary pain... I had a vague memory of configuring something like this before and found these instructions. For the sake of completeness I include them here also:
1. Go to the Tools->Options menu.
2. Pick Text Editor -> File Extension from the tree in the left part of the Options dialog.
3. Type your file extension, .blogtemplate in my case, in the Extension text box.
4. Select the appropriate editor from the Editor dropdown.
5. Click Add and then Ok to close the dialog and re-open your files.
If you cannot see the Text Editor node in the tree view of the Options dialog then you probably need to click on Show all settings in the bottom left hand corner of the dialog...
Using this feature you can set up pretty much any color coding and intellisense support that you like in Visual Studio for file types that Visual Studio lacks support for. All I am missing now is auto completion for dasBlog macros in .blogtemplate files, this seems like a much tougher problem.
Friday 10 October, 2008 (.Net | BizTalk | Fixes | Tips)
The BOM is a two to four byte sequence at the start of an encoded file which tells the recipient if the characters are encoded using big-endian or little-endian byte order. In BizTalk generally the byte order mark is added when a file is UTF-8 or UTF-16 encoded using an XML assembler in a send pipeline. Sometimes applications cannot handle the initial bytes and you don't want them to be added to your message. I recently read two articles about removing the Byte Order Mark (BOM) from outgoing messages in BizTalk 2006 one by Saravana Kumar and the other an official Microsoft KB article. Both of them recommend creating a custom pipeline with an XML assemble stage where the PreserveBom property is set to false. I find it a little strange that they don't point out that you can accomplish this using the default XMLTransmit pipeline also. Just open the pipeline configuration in the Send Port properties and set PreserveBom to false... No custom Pipeline, no coding required.
Wednesday 08 October, 2008 (.Net | Bugs | Fixes | Vista | Web)
While trying out a complex URL rewriting scenario in ASP.Net I ran into a pretty strange problem that resulted in a 404 error:
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested Url: /6.aspx/t.aspx
My code is very similar to a solution that I have created previously in ASP.Net 2.0 on Windows XP so I was a little surprised that I was getting an error. The strange thing is that /6.aspx is the original URL and /default.aspx is the rewritten url, in the error message it looks like the original URL has partially overwritten the new URL!
The exception that is caught has a stack trace that ends with: System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath)
Looking around the Internet for people who have already encountered this problem (as I always do) didn't lead to any immediate solutions. On the IIS forum there is one discussion on Module doesn't work on IIS7 under vista business which lead me to a solution. It seems to me that URL rewriting is broken on Vista prior to SP1. Part of the SP1 upgrade incorporates changes to IIS 7 that were made in Windows Server 2008 as detailed on Microsoft TechNet. So after installing SP1 my solution works as expected.