Software is not Jewellery

Note: This problem is resolved in Visual Studio 2005 SP1 and Visual Web Developer 2005 Express Edition SP1. Try installing the service packs to get around this problem. Or you could just download Visual Web Developer 2008 Express!

Using .NET 2.0 TableAdapters wizard and ASP.NET 2.0 DetailsView data source configuration causes many problems including a runtime error during update or a failure to update the data. Many users have reported this error. A little bit of Googling helped me find out that this error is because a mismatch in the parameters generated by the TableAdapter and the DetailsView for the update command. Here is a way that I used to solve this. I did not find anyone writing about this technique. So I thought I might as well write it here.

How to Reproduce the error?

You should be using Visual Studio 2005(ASP.NET 2.0) and SQL Express. I don’t know if this problem exists with SQL Server as well. I haven’t tried it.

1. Create a table in SQL Express or SQL Server. The table should have an Identity field.

2. Add a Dataset to the Project.

3. Drag and drop the table from VS 2005’s Server Explorer to the Dataset. This creates a DataTable along with a TableAdapter. Note the TableAdapter has a Fill Query, and Delete, Insert, Select and Update Command. The Update Command is not generated if the table does not contain an Identity field. Alternatively you can add a TableAdapter to the dataset and configure the table adapter using the TableAdapter Wizard.

4. Add an ASPX file to the project. Add a DetailsView to this file. From the DetailsView Tasks (that shows up on clicking the arrow mark on the right top of the details view in the designer mode) select the TableAdapter as the datasource. Enable Paging, Inserting, Editing and Deleting.

5. Run the Page. Try Updating. You should either get a runtime error or the update just doesn’t work.

If you are getting either of these, read on.

How to fix the problem?

1. Create a Table in the SQL Express. Make sure it has and Identity field and all other field have “allow nulls” as true. You may change it later but you need to have it enabled while generating the TableAdapter. Here I have used three fields id, Name, Type

2. Create a dataset. Drag and drop the table from the server explorer to the xsd file.

3. Right click on the TableAdapter and go to properties. Expand UpdateCommand click on the Paratemetrs. Remove all ISNull_and Original except Original_ID.

4. Open CommandText and remove text after WHERE (id=@Original_id). Save the XSD file.

5. Create a DetailsView in an ASPX file and slect the TableAdapter as datasource. Enable Paging, Inserting, Editing and Deleting.

6. Click on the edit fields of the DetailsView and Make the ReadOnly property of Id field as False. You can change it to ReadOnly = True later.

7. Run the aspx file. Things work just fine.

Hopefully this helps.

A great thing about web applications is that there is no application setup required at the client end. Plus updates are automatically available as soon as they are deployed on the server. Windows applications however are not so fortunate in this area. Many a times we need to send software updates to windows applications. This could be a new feature that one has added to the application or a bug fix that was written after the software was released. Most windows based applications are distributed by MSI installers. But it would be really irritating for the user to uninstall and install new version every time a bug fix is released. There is however a new internet based approach to windows application updates. This post examines and explains the same.

Most applications distribute a separate application to along with the main app to check for updates. For the sake of reference we can call it an Update Manager or Just UM. Here is how a Mozilla Firefox also uses one called Software Updater (updater.exe) that can be accessed by clicking on Help->Check For updates.

Here is how it looks.

In reality an Update Manager will need to control the client environment. Here is the minimum set of requirements for an update manager.

Requirements

Check for Updates. The software publisher will have to maintain an updates file on a web site. This file will keep the filenames and latest version numbers of all files that are to be deployed in the client system to install the update completely. An XML file is most convenient for this purpose. Also a similar XML file needs to be placed in the client system that contains file names and version numbers of the files currently installed on the client machine. Updates will be checked by comparing the two XML files.

Replace files in the installed path. Most updates are just bug fixes or minor features that can be made available to the user by replacing the main executable in the application’s root directory. Wether a file is to be replaced or not is decided based on version number of the files.

Add new files to the install path. Some features or bug fixes need more than just one new executable file. For example the new build will depend on an XML file or a DLL.

Download and run patch files. Finally there could some changes required in the registry or elsewhere in the client environment as well. This is typically done by running patch files. Patch files will contain the word “patch” (or any other keyword) in the file names so the UM knows that it has to run these files after downloading them.

Automatically close and restart the main application. Most updates are deployed by replacing files; mostly the main exe file. So the UM will have to close the main application before replacing and restart the app after updates are downloaded.

Create back up of all files before replacing. There is no guarantee that the app’s new features are bug free. In fact the user may not want them at all. So the user should be able to “roll back” to his previous set up. This can be done if the UM creates back up of all files that are to be replaced.

Working

All application updates will be placed in a website location along with the Updates XML file. The UM will first download the updates XML file from a pre-define URL. The URL for the Updates file could be kept in a configuration file or hard coded in the application (I prefer the later). The Updates file contains three columns for each file namely File Name, Version Number, URL location.

UM will then compare the update files on the sever and files on the local machine and prepare of list of files to be downloaded. This list will contain

1. Newer versions of existing files 2. New files 3. Patch files

UM will then create new “temp” folder and download the files to this folder. It will then check the files that are to be replaced and create a back up of these files. Finally the UM will kill the main app, copy the downloaded files to the application path, delete the temp folder, run patch files if any and restart the main app.

Updates installed!

This method of publishing windows application updates is almost as hassle free as deploying web applications.