When you’re developing a large website, you often find yourself with a couple of broken links floating around on your site. As most developers working on dynamic sites generally don’t think about it, your first indication that you have a problem is usually only after deployment.

Either you’re unlucky enough to have it brought to your attention by a customer, or you discover it yourself using a tool like Google’s Webmaster Tools.

This is exactly what happened to me while working on our new Cape Town Accommodation venture www.stayunlimited.com.

The webmaster tools will allow you to drill into the info and find the offending links. Now you happily go off and fix the problem in your site and deploy again.

But hang on a second. How can you be sure that you haven’t created more broken links in the process of fixing the problem you initially identified? With a dynamic site making heavy use of URL rewriting this is a major possibility (and it happens to be exactly what happened to me).

Obviously you need to test that your site is now broken link free. You can be optimistic about it and wait for Google to re-index your site so you can check the webmaster tools again (probably not a very good idea). Or you can use one of the many online link checkers available to scan your site. But that isn’t that great a solution either, because at this point you’ve already deployed the site.

First prize then would be to check your site for broken links in your development environment before deploying. There are a number of tools available for doing this, but most are commercial and not free of charge. The SoftwareQATest.com website has a number of tools listed if you’re interested.

From their list I discovered the excellent freeware Xenu utility by Tilman Hausherr. This little Windows app will scan through your locally deployed website and highlight any broken links, allowing you to fix them before deploying!

What more could you ask for?

So Miguel just let slip on Slashdot that they're working on some very fancy features for Mono and ASP.NET / MVC.

I agree that Visual Studio is a very nice tool.

Luckily the code that you produce with Visual Studio will run on Mono (no recompilations necessary) including code that uses ASP.NET MVC. And with the new support for ASP.NET precompiled sites in Mono (available in Mono 2.4) you do not even need to copy the source code to your target server.

Click "Publish" in visual studio, enter the location for your shared directory, and you have a fully working ASP.NET MVC app running on Linux, without leaving Windows.

We are working on various integration points for Visual Studio that will give developers even more: debugging from Visual Studio remote applications deployed on Linux systems and producing packages ready-for-distribution on Linux. [Miguel on Slashdot]

I doubt that this was a secret to begin with, but it is the first I've heard of this and it excites me greatly. I mean, come on, debugging a Mono hosted ASP.NET application remotely using Visual Studio? It doesn't get better than this!

This post is pretty irrelevant considering the amount of excitement this has generated in the blogosphere already, but for those of you who've been hiding under a rock:

I’m excited today to announce that we are also releasing the ASP.NET MVC source code under the Microsoft Public License (MS-PL). The MS-PL is an OSI-approved open source license.  The MS-PL contains no platform restrictions and provides broad rights to modify and redistribute the source code. [Scott Guthrie]

For those of us who like to dabble in the open source world, this is major news. Especially for those of us who've adopted Linux and Mono as our cloud server operating system of choice.

And no, as hard as it is to believe, it's not an April Fool's joke. I think maybe Microsoft has hired just one too many open source software developers :)

Miguel de Icaza is already talking about integrating the code into Mono. This has some obviously major benefits: no more reverse engineering and thus far less compatibility problems. It looks like the dream of running .NET on free operating systems is beginning to solidify nicely!

To find out more about how this happened, go read it from the source:

ScottGu
Rob Conery
Phil Haack
Scott Hanselman

If you're serious about .NET I would suggest subscribing to all of the above blogs if you haven't done so already. 

The Novell guys have pushed out another release of Mono, and I've just updated my VPS.

I'm glad to report that everything works great with BlogEngine.NET on Ubuntu. I've updated my instructions for installing Mono on Ubuntu to include the latest release.

If you haven't given Mono a go yet, what are you waiting for?

With the Website Template in Visual Studio, all classes in the App_Code directory of your web site is compiled into a temporary assembly of its own when the web app is loaded by IIS. In order to get a handle to the assembly, you can use the following code snippet:

Of course, in Mono it doesn't work that way. To get the temporary compiled assembly you need to use the following:

Note that like everything on Linux, the casing matters here!  "app_code" will not work, unless you're running XSP on Windows.

Strangely enough the Mono implementation makes more sense. I couldn't find any information on the interwebs about this issue, so I eventually got it by guessing the correct name!

Not being able to trace through your code while doing a Mono port of an ASP.NET application can seriously hamper productivity. Until the Mono debugger is finally ready for prime time, we'll have to debug the old-school way.

One easy way of getting debug output from a Mono application is to simply use Console.WriteLine. If you're running your ASP.NET application through XSP2, the console output will be visible from the terminal that XSP was run in.

.NET supports using TraceListeners for capturing System.Configuration.Debug output. There is a handy ConsoleTraceListener that will convert all calls to Debug.WriteLine to console calls. This would be fantastic for Mono usage, but alas, Mono does not appear to support TraceListeners at all! My tests have shown that the overridden abstract methods in a TraceLister descendant are never called.

UPDATE: Seems my assumptions about TraceListeners not working in Mono was a bit premature, but not all that far off the mark.

As it turns out, TraceListeners do work, but only when you're running an application that has debugging enabled. This is the expected behaviour, and .NET follows the same guidelines.

However, when running a "Web Site" project (one that hasn't been pre-compiled), Mono still seems to have some issues. If you set the <compilation debug="true"> flag in the Web.config file, the application should be build with debug symbols and all debug output should function as expected. I've confirmed this to work on .NET, but am unable to get this working with XSP2 (Windows or Linux). The debug output does work however if you use a pre-compiled web site (i.e. ASP.NET Web Application in Visual Studio) compiled under the Debug configuration.

The Mono ASP.NET page suggests doing the following:

$ MONO_OPTIONS=--debug xsp2 

Listening on port: 8080 (non-secure) 

Listening on address: 0.0.0.0 

Root directory: /tmp/us 

Hit Return to stop the server.

This hasn't worked for me however. If anyone knows what I'm doing wrong here, please drop me a line and let me know!

I just came across the official mono porting ASP.NET applications guide. If you're planning on doing a port, I'd suggest you give this guide some attention.

The guide has some real gems like the following:

Using MONO_IOMAP

On Unix systems, Mono supports an I/O compatibility mode which allows you to ignore the file name case when accessing files on disk. The mode also takes care of disk designators (e.g. c:). Enabling the translation carries, obviously, some performance penalty, but is a good way to get your application up and running quickly. To enable the compatibility mode, make sure your web server's (XSP's or Apache's) environment contains the MONO_IOMAP variable set to all:

MONO_IOMAP=all export MONO_IOMAP

If you're using mod_mono, put the following line in your virtual host config file:

MonoSetEnv MONO_IOMAP=all

Knowing about this would have saved me a good couple of hours on the BlogEngine.NET port!