which is a bit of code quite common in an authentication filter. The problem is it will throw a ThreadAbortException as soon as you put your code on a live site resulting in the error page for anyone who is not logged in. This is probably not what you want since you are attempting to redirect them to the login page.

Now it is a little unfair to say that it’s an issue because that is the intended functionality. But it doesn’t fit well with MVC controllers, especially since Microsoft’s official suggestion is to set the endResponse flag to false. That is just downright misleading since your controller action (which the filter just decided you can’t access) is still executed after the filter fails authentication – resulting in the action code being executed anyway whilst you see the login screen on the browser and assume it all went swimmingly! Meanwhile those files that this user shouldn’t have access to got deleted.

Yeah, that’s what I just did during testing whilst proving to myself that you can’t fake the URL as a non-registered user. Imagine my surprise. It’s true that the chances of a malicious user actually working out the URL might be low, but that’s no reason to leave the door open.

Oh, and your unit tests probably won’t catch this because the filters don’t get executed by the unit tests. But I digress…

To cut a long story short, this bit of code in your base controller (assuming you have one, otherwise stick in in all of the controllers) will prevent the issue:

So here’s the problem – you create a website that allows the upload of images (or any file types for that matter). It’s very likely you’re going to want to limit the size of those uploads or you’ll end up in a world of pain when your users go and use up all your disk space. By default IIS allows upload sizes of 4Mb which is ample for image purposes. However, if someone uploads a file above that size you’re likely to want to notify them by telling them gently they’re an idiot for not reading the note above the file input field and then allow them to reselect a file.

But you can’t because the requests never gets to your page. IIS simply drops the request and seems to respond with nothing at all. That leaves the user looking at a ‘Web site could not be found’ error, which is misleading and just plain wrong.

And this is the situation I found myself in. Simply put, you can’t catch the HttpException in your code and recover gracefully. Unfortunately the vast majority of people out there believe the answer is to increase the maxRequestLength in web.config. How can that be considered a solution? It’s like saying the way to deal with traffic congestion is to double the size of every road. Someone, somewhere will then try and upload a file that is even bigger and the problem repeats itself.

I spent a long time looking for a solution and eventually came across a little trick which you can pull in your Global.asax:

Thanks to this guy for the hard work.

It seems to be about the only place in the code that you can do anything about the error. What it’s actually doing is reading in the whole of the request even though it is over your maximum request size. Once the whole request has been read you are able to make a response to the calling client, in this case a redirect to an error page. It’s possible that you could take this further and carry on with the page the user originally intended to work with, catching the error and displaying it there. But I’m too burned out to try that right now and this solution works fine for me!

And this is the code in the View:

I know it’s still only in Beta, but I think it’s time some of the Microsoft boys tidied up their otherwise useful blogs to remove and update many incorrect usage instructions for the latest cut of the framework. After all, it’s the only documentation we have at the moment.

One more issue I’ve found is the name that is assigned to the resulting <select> tag. It’s a bit irritating as I may not want the name to be the same is the key that is used in the ViewData (which is what it uses here, i.e. “PortfolioSelectDropDownList” in my case). That messes up my typed view. The only way I’ve found around this is to use the name of the variable in my typed view for the ViewData key, e.g. “Project.PortfolioID”. The result is that I get a select list and when the form is posted back my Project object is populated with the selected value.

To be honest it has a certain elegance to it so it may even be the intended usage! Still seems a bit strange to me though…

But frameworks change during development and you come across the issue that all of the top hits for your query are based on previous versions. When that previous version did it differently you’re stuck! I had this problem today when trying to create strongly-typed views. I love strongly-typed anythings, but I’m just a sucker for having a project that is more likely to work when another developer makes an edit and doesn’t bother fully checking the effects of their changes. It’s another safety net, and I’m a sucker for safety nets as well.

So, this is how I did it in bite-sized chunks. First the controller function:

Next I created a new view by right-clicking the above method (bear in mind that I’m using Visual Studio 2008) and checking the ‘Create a strongly-typed view’ before entering the full name of the object type (ContentClass). That produces an aspx.cs which looks something like this:

So far so good, but where I really came unstuck was actually using this in the view. Turns out it’s simpler than ever. All you need to use is the ViewData.Model parameter, which is automatically typed to whatever you set the view up as previously:

All that I have to do now is pass that through to a UserControl. I’m assuming I can strongly-type those as well. We shall see.

Or at least that’s what you’d think. You know how it is – you get it all working on your lovely development machine and then once the decision has been made on where to host the final result, you upload your application and…bang…

HttpException (0x80004005): The incoming request does not match any route.

Oh yes, that works so well.

Suddenly that belief that, finally, someone has produced a framework which is so nicely integrated with your target platform comes crashing down around your head as you weep softly into your keyboard. No, ASP.NET MVC is not actually supported on anything under IIS7. Does your host offer IIS7 at the moment? I guess not.

Now don’t get me wrong, it does work on IIS6 but you have to mangle it a bit and unless you pay a fortune each month for access to your own virtual server then you’re likely to lose those pretty urls. That’s not the same as being supported. For those that have spent the last two hours Googling and still getting the same problem, here is the man with the answer:

http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx

Simple, I thought – text-align:right in the CSS and the jobs a good ‘un. Well yes, you would think so. The fact of the matter is that text-align:right is only supposed to apply to block level elements (according to the CSS2 specs), although it isn’t quite implemented that way in all browsers. So, add display:block in there as well just to be on the safe side:

Left Align: <input style=”padding: 0px; text-align: right; display: block” type=”text” />

Job done! Well, not quite if you are viewing this in Internet Explorer 7. Click in the input field which is aligned to the right and no cursor displays at all! I must be tired today because this took me ages to work out and I found no reference to it anywhere in the web. For some reason the cursor is there – it’s just off to the right a little too far. I say ’some reason’ when I now know that the actual reason is that the padding is set to 0px. The reason for this happens to be because it has inherited the property from other elements in my form layout, but in this example I have added it specifically. Add a little padding to the right and hey presto:

Left Align: <input style=”padding: 0px 1px 0px 0px; text-align: right; display: block” type=”text” />

That’s just strange. Zero padding displays the cursor on the left, but not the right. Except in Firefox, which just shows it correctly in either case.

Anyway, to cut a long story short, my evangelising on the subject usually ends in the words ‘here you go then, write an installer for that’. And so I end up with the job yet again.

That’s not to say it doesn’t have its issues like so many other things in the world of software development, especially when you end up writing some monster installer that installs a web-client, web-services, windows-services and the odd database or two.

Today’s issue was ConfigureIIS which is a custom action executed if you are creating a <WebVirtualDir>. Unfortunately even if you are not installing the web component that needs IIS to be configured it will still attempt to execute ConfigureIIS which causes an error to appear if IIS is not installed. Just having a web component in your installer is enough to fire it off.

Looking on the WiX mailing lists it seems that it is a known issue and the only way around it currently is by modifying and recompiling the source code for WiX itself. Not a lot of fun when you just want to write an installer and it takes you away from the currently released code, which I find it is best to avoid when working for other clients.

However, in the process of modifying the source I found the property SKIPCONFIGUREIIS. Set this to true and it no longer runs the ConfigureIIS custom action. Obviously you need to make sure it’s only turned off for the relevant features of your installer. It’s just a shame they didn’t make it a little more widely known!

To be honest I could have kicked myself since I already knew of the SKIPINSTALLSQLDATA for turning off the database activity when not required. That one is a little more published though.

A chance comment I came across whilst Googling for something else seems to have cleared up the issue. It seems my technique of using the Network utility in the Finder was the main issue. It is certainly the simplest option and most people seem to use it for that very reason. The trouble is it doesn’t always get the protocol right. You can check this by creating a connection to your server (in the finder choose Network and then browse to your server and connect to a share), selecting the new connection and then checking the info (Apple key and I). Mine shows up as:

cifs://my_server/backup

Since my Linux server uses Samba for the network shares it’s far better to connect using the Samba protocol:

smb://my_server/backup

The easiest way to set this up is through the ‘Connect to Server’ utility in the Finder. This also stores your server connections for easy future access. You should be able to simply type the connection string in and then connect at will. Hopefully you’ll see a much more stable connection in future.

(An extra tip – once you have the connection set up you can automatically connect at login by adding it to the list in System Preferences->Accounts->Login Items)