The thing that I enjoy the most about working on projects run with agile principles and practices is that it is really effective. I’m constantly impressed by how quickly things change and adapt in such a short time frame, though I know that this can be a little disorienting to people not used to it. I just got back from a week of skiing in Andorra (the snow was very nice for us despite their worst season ever) and in that time, five developers have completely changed the way an entire application looks as well as adding a whole heap of functionality that wasn’t there when I left seven days ago. Great stuff!
Tag: Development
On my current project we’ve been having a pretty good experience leveraging the NUnitASP library for automated testing of our website. In our second week of development, we noticed like many other people, that it is yet fully compatible with .Net 2.0 because of the way that ASP.Net now generates its javascript postback functions.
In the previous .Net version, ASP.Net seemed to generate a very simple function of the form of __doPostBack([targetId], [targetArguments]) that would effectively set two hidden variables (__EVENTTARGET and __EVENTARGUMENT respectively). In the current version, ASP.Net generates a much more complex javascript function (called WebForm_DoPostBackWithOptions) that I think is caused with use of any of the ASP validator components.
One work around that one person (Lance Ahlberg) found was to turn the “CausesValidation” property off for controls but this may or may not suit the way that you are developing your website. Looking at what the javascript generated does, I think that there must have been a better solution so I spent some time delving into the depths of NUnit ASP to find one.
The result is a patch to ControlTester.cs that allows the __EVENTTARGET and __EVENTARGUMENT to still be set by extracting out the appropriate values from the new WebForm_DoPostBackWithOptions javascript function. You can download the patch here but you have to build your own NUnit ASP, or wait until this is integrated with the next release. The ticket for my submission can be found here.
I know this is old, but I’m putting up here as a note to myself… the installation order of IIS and .Net 2.0 matters. If you try running .Net 2.0 code on IIS that thinks it’s running a prior version of .Net (see the bottom part of the IIS error page to see what it is running), run the aspnet_regiis.exe /i command that sits deep in the bowels of the %windir%\Microsoft.NET\Framework\v2.0.50727 folder to make it run fine again.
Starting new projects always carries great responsibility but also offers a great opportunity to improve it by applying learnings from previous projects. Fortunately I’m currently in this position as one of the early developers on a greenfields project that’s been running for the last two weeks.
What I’m attempting to do this time is that instead of defining and/or enforcing a set of coding standards and patterns used throughout the project, I’m hoping to capture the thinking that goes along side the decisions as we make them, distilling them into a set of core principles we’re striving for. By capturing these core principles I hope it makes it easier for new people to come on board, provide a better context for analysing the code artefacts we create and still leaves an open discussion for newcomers to suggest better ways of achieving these same principles.
Recent Comments