Monday, March 31, 2008

VS2008 Express - Launching nUnit on F5

Here is the How To:

Add these two lines into the section of your project .csproj.user file.


<StartProgram>C:\DEV TOOLS\Program Files\NUnit 2.4.3\bin\nunit.exe</StartProgram>

Pressing F5 will launch NUnit now and start debugging.

Thursday, March 27, 2008

Web development 2008 ! We've come a long way ! Now where’s Notepad ?

Darren, our framework developer who plays with all the new cool tech had a play with VS2008 web development, and the results were not very pretty.

Today I had a simple task; Make a small application to demonstrate the new features in Visual Studio 2008 for Webform development. I had attended the Brisbane "Heroes Happen 2008" Microsoft launch event the previous day and thought "A quick 20 minute job". Hmmmm...

The Agenda...

  1. The impressive UpdatePanel
  2. Intellisense in JavaScript editing
  3. Debugging JavaScript in Visual Studio

I should say at this point that I am a dyed-in-the-wool Winforms developer although I have developed a fair few websites in my time. I've built web apps (mostly modestly sized affairs) using everything from Visual Interdev (remember that?), Notepad, and all .NET Visual Studio editions. I've done it but I have to say I don't like it. Why? If I'm brutally honest I hate the pace of development, the fact the tools aren't properly integrated and browsers that can't agree how to render anything useful; These are just my top 3 hates.

Anyway, yesterday I was truly impressed with the demos and found myself thinking maybe web development could be fun at last...

How wrong I was.

I had about 90% of the demo complete well within my initial estimate and then proceeded to put the breakpoint on the JavaScript code in the page and entered a world of pain. I use Firefox as my main browser and, naturally, VS 2008 JavaScript debugging doesn't work there. Okay, set IE 7 as my default browser for the web project, problem solved... well, no. Hmmm... Reboot? No. Repair install of Visual Studio? No. Another reboot? No. Go moan to someone else about how s@#t web development is? Worked like a charm.

Somebody please explain how bringing someone over to your PC and showing them how something doesn't work can suddenly kick it into life. I say this, but it didn't work the *first* time, just the second and every time since.

Its things like this that give me killer headaches and make me want to go back to the nice cosy world of framework development...

Aside from a nice preview of the 'design' and the (admittedly) cool CSS stuff there aren't a lot of compelling reasons to spend a large wad of cash rather than just use notepad. I mean, if I'm going to get stressed and generally harassed by technology that isn't reliable, doesn't work and then magically cooperates I may as well start in the position of expecting things to be tough and just use everyone's favourite free web development tool.

PS I don’t really mean that we should be using notepad because it would be really frustrating. The issue is that Visual Studio 2008 is so close, but so frustratingly far from being a great web development environment.

PPS I love everything else about Visual Studio.

Wednesday, March 26, 2008

FXCop and string culture

Rules are great, unless blindly followed.

I thought I would just send this out as a reminder. While everyone is eager to do right by FxCop we should not forget to use the Invariant Culture where appropriate.

FxCop will complain about any string formatting without an explicit culture. If you are formatting for internal use and not for display you really should consider using CultureInfo.InvariantCulture. This is particularly important if you plan to consume the string with software. Using the current culture would mean the string potentially could not be consumed by another server/PC. For example, if you used BCMax in Dubai it would have a different culture to the StrataMax server running here.

So if it is an internal string not for display or to be interpreted by software anywhere consider doing this:

receiptNumber.ToString("#", CultureInfo.InvariantCulture);

Instead of this:


Thursday, March 6, 2008

Exception handling in ASP.Net with Anthem and Web Services

Dorian, our CIO, has been busily hammering the VB.NET based shopping cart selected for a large client into shape.

Anthem.NET is a free, cross-browser AJAX toolkit for the ASP.NET development environment that works with both ASP.NET 1.1 and 2.0.

Please ignore lack of indenting ... blogger keeps eating my directives. Kent Bolton

Before Anthem it was enough to put an error handler in the Global.asax on the Application_Error event to log the error and use the tag in the web.config to redirect errors to a common error page.

Anthem complicates things.

In Anthem it is possible to have Ajax call backs to the web page, controls or even custom methods decorated. Exceptions could be raised on the methods called or even on methods not directly called by these methods such as load events for controls that Anthem causes to load dynamically.

If an error occurs during an Anthem Callback the exception will not be caught by Application_Error and won't follow instructions. On the server side the only thing you can do to catch an Anthem Error is catch it on the page using a Page_Error method. This method will also catch regular page exceptions thus preventing Application_Error from firing. It may look something like this:

Private Sub Page_Error(ByVal sender As Object, ByVal e As EventArgs) Handles MyBase.Error
End Sub

In order to avoid putting this method on every page it must be placed on the base page class for the entire website. There is a small downside to this which is a page can no longer define its own Page_Error method because control would be lost in the event execution chain when a Response.Redirect is started (it aborts the thread). This is however a necessary evil as there doesn’t seem to be another way to catch Anthem exceptions.

Because we are on the topic of Anthem and error handling here is a couple more useful facts. You can catch errors in Anthem call backs on the client by adding a JavaScript method to pages calls Anthem_Error. If a server side error occurs in an Anthem callback any previously registered JavaScript to execute will still be executed. For example if you had an Anthem button which looked like this:

Protected Sub btnNext_Click(ByVal sender As Object, ByVal e As System.Web.UI.ImageClickEventArgs) Handles btnNext.Click

SomeHiddenPanel.Visible = True

Anthem.Manager.AddScriptForClientSideEval("if (typeof document.someform != ""undefined"") { documentsomeform.submit(); }")

End Sub

And after this code executed a server side error occurred (perhaps in rendering SomeHiddenPanel) the JavaScript added would still be executed. It is important to write such JavaScript to be tolerate of an error occurring. The code above checks for the existence of the form which SomeHiddenPanel would make visible before it calls submit().

Web services are another nasty for exception handling. Basically, you need to try catch every web service method and handle all exceptions. The same error logging routine could be use by web services and page errors if it was tolerant of information that may not be present on web service requests. View state is one example. Don’t expect to find that in a web service.