Dynamic Data Changes - EnableQueryStringSelection

With the release of .Net 3.5 Framework SP1, the Dynamic Data tools have changed slightly. If you setup a site with a pre-SP1 version of Dynamic Data then this issue may have bitten you.

Runtime error - "Type 'System.Web.DynamicData.DynamicDataManager' does not have a public property named 'EnableQueryStringSelection'."

This flag on the DynamicDataManager enabled that manager to ensure that when a control such as GridView is associated with another control such as DetailsView that one would update when the other changed and vice-versa. One of the downsides of this behaviour is that your associated control had to be supported by the DynamicDataManager to be able to participate in the synchronisation - so many 3rd party controls missed out. Also all registered controls participated in the synchronisation from the Url.

To reenable this behaviour in SP1 use the DynamicDataManager.RegisterControl(Control control, Boolean setSelectionFromUrl) overload when registering the controls. When true is specified that control will get its selection from the Url. So there is now a lot more flexibility in defining which control is managed from the url, instead of all registered controls being managed.

VS2008 and .Net 3.5 SP1 released

Today Microsoft released the RTM of Visual Studio 2008 and .Net Framework 3.5 Service Pack 1.

What a great milestone! Hopefully this signals a new level of maturity and stability in these two technologies. Some organisations that I have associated with have been somewhat reticent to embrace .Net 3.5 as it is still perceived as too bleeding edge.

That aside, .Net Framework 3.5 has a great uptake in developer participation due to the exciting new framework and language features that it introduces. There is great buzz in the development community around MVC, Linq-To-Sql, Dynamic Data, Lamba expressions, ASP.Net AJAX, support for Astoria, ASP.Net Entity Framework, partial methods and so on. The speed at which these new technologies and frameworks are appearing is very rapid. What's more is that these features have led to whole new areas of application and platform design options that are easier to implement, reuse and maintain.

I believe this is a really exciting time to be involved in using these tools to develop applications. It reinvigorates the community.

What changes in SP1 do you think will be most beneficial to you?

.Net 3.5 SP1 Overview
ASP.Net Debugging

Combined Visual Studio 2008 and .Net Framework 3.5 Service Pack 1
.Net Framework 3.5 Service Pack 1 (no VS2008 SP1)

When RAD is just cool

Problem:
Recently faced with an application that is deep in maintenance I was asked to de-identify some demographic data for a new training environment. One aspect of the data in the database is stored in a decent sized XML blob of ~10Kb. The XML blob had some of the data that needed to be modified - names, addresses, phone numbers etc. This data is also spread out to other reaches of the database in relatively harmless tables.

Solution 1
Do data manipulation at the data store with SQL scripts. To be honest, 90% of the work is done in SQL scripts to remove unwanted data, shuffle names and addresses, randomly change DOBs etc. When doing bulk deletes and manipulations the flexiblity to easily disable indexes and triggers lends itself to TSQL and intimate database relations. However when facing the data in the XML blob and things became a little cumbersome in TSQL. So I looked to finish the job with...

Solution 2
The current application has a data model and data access, surely that can be reused. The option of taking the XSD and load/save methods of this old (Vb.Net 1.1, 1 assembly (!) ), monolithic ASP.Net website and wedge it into a console app to manipulate the data seems good on first glance. It really only took about 5 minutes of going down this path to feel a pain that really shouldn't be felt. (Think Datasets, SqlCommand, SqlDataReader and friends). Spaghetti code like this just can't be plied apart from the in-tree custom framework that it lives with. So in comes...

Solution 3

Enter RAD. I opened up VS2008 and took the following steps - new console project, register database in Server Explorer, new Linq-to-SQL designer, drag the database table to the designer. Then it was a simple case of creating a database context, iterating the rows, using XPath to manipulate the Xml and submitting the changes to the database. The end solution was less than 30 lines of code and took less than 15 minutes.


So what was cool about this? Well, I didn't write a single line of 'grunt work' - no database access, domain objects, readers or mappers - it was all done for me. I distanced myself from the mechanics of the task at hand and focused on the heart of the problem, which was updating the data.

What I learned came back to the old adage of 'using the right tools for the job'. RAD tools don't fit every application or architecture, but in my mind for throw away utilities like I was writing they provide the perfect solution.

LinqDataSource error on Update or Insert

Here is a reminder for myself about a problem that happens, and I always end up having to search to remember the solution. When performing an update or insert on a LinqDataSource, say from a GridView you get the error "Could not find a row that matches the given keys in the original values stored in ViewState. Ensure that the 'keys' dictionary contains unique key values that correspond to a row returned from the previous Select operation."... Sounds complicated.

Well it isn't. Check that you have set the DataKeyNames property on the GridView with the column name of the primary key(s) of the LinqDataSource table. But that doesn't make sense, you say.

It does if you have a look at the stack trace. For example,
System.Web.UI.WebControls.LinqDataSourceView.GetOriginalValues(IDictionary keys) +926 System.Web.UI.WebControls.LinqDataSourceView.BuildUpdateDataObjects(Object table, IDictionary keys, IDictionary values, IDictionary oldValues) +102 System.Web.UI.WebControls.LinqDataSourceView.ExecuteUpdate(IDictionary keys, IDictionary values, IDictionary oldValues) +87 System.Web.UI.DataSourceView.Update(IDictionary keys, IDictionary values, IDictionary oldValues, DataSourceViewOperationCallback callback) +78

The LinqDataSource is just like the old SqlDataSource - it needs to know how to lookup the row in the database table to work out what you have changed. If you don't tell it the keys to lookup in the table, how will it ever know which row you were editing? Once the DataKeyNames are specified those columns are used to find the original row in the database, compare and merge your update changes and commit them back to the row. Simple. Now I just have to remember "Set the DataKeyNames property"...

Windows Workflow still immature

I have been spending the last couple of weeks looking at how to integrate Microsoft Windows Workflows into my ASP.Net website. It is a basic usage of workflow - implement a state machine, do some processing on state initialisation, maybe fire an email or reminder here and there. It all sounds great on the surface and it basically works. But there are a few things that will just mean that it isn't workable in my site.

You see I have long running workflows, let's say longer than a week. They might hang around waiting for user input, a client to phone back, fill in a web form or something of that nature. However I am taking an agile approach to this particular development - releasing little functionality increments for the client. The problem is that workflows are tied to assembly versions, and my assembly versions are changing all the time. Not to mention that the workflow structure is also changing all the time.

So what do I do? Something like Ruurd Boeke suggests could pass, but hell that is a lot of work, considering I'll be doing this every two weeks or so. I don't have a good solution, so for the moment it is shelved. I'll just implement a basic state flag on my object and then provide a generic mechanism for faking the state flow. If things are designed right then I should be able to reuse any code in workflow activities once it all gets running. I'll try to use workflows for some of the short tasks that are required, just to make sure I am still getting my feet wet with the technology.

This seems like a typical trend for Microsoft to release something that is really, really beta (nay, alpha?) to gauge public opinion and then develop it a production standard later on. Windows workflows seem to me like they are nowhere near ready for production systems.

Do you have an opinion??

ASP.Net Event Validation

OdeToCode.com has a great post from K. Scott Allen about the ASP.Net event validation. He describes the mechanism that the ASP.Net controls use to validate that the values being submitted from the controls are valid. The second part of the post gives a couple of workarounds. I hate the suggestion of disabling event validation across my whole site. What a cop out!

Of course it doesn't help with my current problem of the event validation on the AJAX controls, but it is a good bit of background for understanding the problem.