XPO and ASP.NET - Where to put your persistent classes

If you have been working with XPO in ASP.NET applications, you may have noticed that the standard XPO Persistent Object X.X (and also the new Persistent Classes X.X) template is not available when the current project is an ASP.NET project. We recently re-evaluated the decision to leave the templates out from that location, and while we found the original reason to be invalid by now, there are still some things to be aware of when working with persistent classes in ASP.NET projects.

Back in the days of beta testing for VS 2005, we first discovered a problem that appeared when persistent class hierarchies were used in ASP.NET projects. The reason for this issue was that XPO stores certain information about classes inside the database, among those the name of the assembly from which the class was originally read. A lot of the time this information is not used, but when persistent classes are derived from other persistent classes and instances of those derived classes are created and saved, XPO looks up the assembly name information and tries to demand-load the correct assembly.

In ASP.NET 2.0/VS 2005, a project is built (by default) into several assemblies, and the names of these assemblies include a "key" part that changes regularly after rebuilding. So when XPO stores away the assembly name of a certain class in a first application run, then that information is likely going to be invalid on a later run because by now the name of the assembly has changed.

When we discovered this issue originally, we found two workarounds. The first workaround is to enable a project level option in VS 2005, called Use fixed naming and single page assemblies (you can find it on the MSBuild Options page). While this makes sure that the assemblies have reliable static names, it has the major disadvantage of creating lots of little assemblies, because every single (web) page now gets its own. Well.

The second workaround is still our current recommendation, which is to use a separate assembly for your persistent classes -- a standard "class library" project type will do for this. Not only did this solve the issue above, it is also generally a good practice because it allows you to easily create other applications that use the same classes as your web application. Think of admin frontends running on Windows Forms, database update utilities and so on...

Now, in our recent re-evaluation we found something that was news to us: there is special magic implemented in the .NET framework, so that assemblies with a name that starts with App_Code will be found even if the rest of their name doesn't equal the search string. In other words, a call to Assembly.Load("App_Code.myRandomPostfix") will load the actual App_Code assembly when used from a web application, never mind the fact that the actual assembly obviously uses a different postfix. This magic handling seems to be in place for .NET 2.0 and above. We're not quite sure why we didn't see it earlier, but probably it was added before the final 2.0 release.

This discovery means that technically your persistent classes are safe when stored inside the App_Code subfolder of your ASP.NET project. We will therefore make the templates available for use in those projects in the next minor update. I would still recommend you use a separate assembly, but at least we can get rid of a somewhat arbitrary restriction now.

Free DevExpress Products - Get Your Copy Today