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!
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 (
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 “
The result is a patch to
ControlTester.cs that allows the
__EVENTARGUMENT to still be set by extracting out the appropriate values from the new
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.