ASP.NET Update Panel Trigger after site upgrade

Error Encountered

System.Web.UI.UpdatePanelTriggerCollection must have items of type 'System.Web.UI.UpdatePanelTrigger'. 'asp:AsyncPostBackTrigger' is of type 'System.Web.UI.AsyncPostBackTrigger'.

I scratched my head for a little thinking this was something more complicated that it was.


After upgrading a ASP.NET site from ASP.NET 2.0 to the 3.5 framework where the site used a derived AJAX update panel in a separate referenced class library.

<asp:AsyncPostBackTrigger ControlID="albViewMoreCategories" EventName="Click" />
- was the line causing the compilation error.


The website project updated to 3.5 fine and changed the reference to the system.web.extensions class to a 3.5 version. However the associated class library still clung onto the previous 1.0 version of the class.


Removing the system.web.extensions 1.0 and relacing with it with the 3.5 version got rid of the conflict between the two projects.

I hope this helps some one.

Using WCF to publish Pindar CMS content to ASP.NET


Technologies used

Windows Communications Framework (WCF), VB.NET windows forms, SQL server, Oracle, Pindar Catalogue Management System (CMS)


Pindar produce a Catalogue Management System (CMS), that is used by many large catalogue companies to manage, traditionally printed catalogues. Companies such as the large electronic components catalogues and clothes directories.

From a technical perspective, CMS is an Oracle database that holds all the items, prices, page content, layout, pictures, paragraphs, sections, pages, publications and other resources linked to those entities. It handles work flow of the activities that are required to generate catalogue content with authorisation and release concepts, handles multi-lingual translations and the workflow involved in getting that content translated. As you can tell this is an expensive and powerful publication system for the larger catalogue companies.

The Oracle database if fronted by a number of optional components, the most important to us are the CMS manager this is the forms front end to the system and the Quark extensions that allow the pages to be built in Quark and ultimately sent to the printers in postscript files. Essentially the Quark extensions allow the Quark to understand and build the pages from all the elements held in the database, very cool to see. Oh and it works on both Mac and PC, obviously with the publishing heritage.


Many years ago I wrote an application in Delphi in my own time that took content exported from CMS tables into excel and then built HTML pages using this information. It read the page layouts and essentially built the page in HMTL in a similar same way that the Quark extension does it in Quark (all be it the subsection of functions that we utilised). One of the major problems was handling the Quark and Stibo (previous catalogue management system) tags that littered the text returned from CMS.
Things turned direction and I never actually used this application and the folder got stuffed on my shelf for another time.


Getting the text of the catalogue onto our web pages as text rather than PDFs suddenly went to the top of the list when we bought our Google Mini, and the need to feed it with rich content came along. I dusted down the Delphi project stripped out the bits I needed and started on a adventure to build an application that would allow the publication of item groups from CMS to our internet site. This was also was the prefect project to add to my experience of WCF.

The application had to allow the CMS user to see which item group texts had been updated since they were last published to the web and preview those groups then publishing the new version to the internet.

Follow how I used MD5 check sums and last modified dates, and schema validations to ensure the content had changed and was valid by following the project.

Publishing Catalogue Management System to ASPNET

WaitOne while I introduce multithreading

For some time I've been meaning to do some multi threading in the Dynamics SOP Fulfilment software I wrote. I have always thought that I could make things run a little more slickly. At fulfilment the following processes occur;

  • Credit/debit card debited if one is attached to the order
  • Order lines are fulfilled by quantities on the pick list being fulfilled
  • receipt printed (optional depending on carriage option- customer collect etc)
  • despatch note printed (optional)
  • invoice printed (optional)
  • thermal parcel label(s) printed one for each parcel entered
  • consignment details are exported via XML to UPS / Business Post / TNT depending on carriage routing algorithm
  • UI is constantly updated with progress bar and messages about progress

Spinning the fulfilment thread off on to its own thread using a background worker control was straight forward and is something I did when VS2005 was released. However some of the above processes take quite a few seconds to run, the fulfilment computers are quite recent hardware and thus should be able to perform better.
Thanks to good object orientated design, it turned out to be fairly trivial to get each of these processes to run on their own thread and synchronise them using wait handles. I had to use wait handles as some tasks depend on the successful completion of others. More...