a collection of technical fixes and other randon stuff

Spodworld

  • Join Us on Facebook!
  • Follow Us on Twitter!
  • LinkedIn
  • Subcribe to Our RSS Feed

ASP,net Compiled DLLs and simplifying builds

Recently i've needed to understand more about the methods and naming of compiled dlls in an ASP.net website.

I'd come across a problem in a system that auto updates it's self, and the fact that we wanted to do controlled partial updates to the system.

What i had noticed in testing is that some developers code produced lots of .compiled files and strangely named dlls , whereas others had just one or two files when the site was published.

This was a big problem when looking at the update process because if a customers site has a mixture of the two release methods, then it was pretty much guaranteed to fall over with error messages like 

"The file has not been precompiled".

 Two options

 In Visual Studio 2008, you get an option when publishing a web site to "Allow this precompiled site to be updatable".

When not selected, each asmx asn aspx page gets compiled to it's own dll and a .compiled file is created for each page also. To cut a long story short, this makes the client side content of your pages uneditable and more secure. The ".compiled" files reference the relavant dlls and provide checksums to ensure they are valid.

When selected, the file list becomes much simpler with fewer dlls and ".compiled" files.

Facing future updates and testing of code releases, the latter option sounds the most promising and most managable but there are still a few files that cause cause a bit of head scratching.

App_Code.dll

App_Web_xxxx.dll (sometimes several of these)

App_global.asax.dll

 App_Web_xxxx.dll

These little guys offer the most confusion for our planned auto update service because the name of these files changes with each build and are pretty randomised. This can pose a big headache when trying to know which dlls to replace, add or delete. Without a solution, the only alternative is to do updated of the whole bin director.

Luckily there is, but first, an explanation of the files and what you can do to reduce them.

  •  App_Code.dll - Is where all your classes reside. Basically everything that has come from your App_Code folder in Visual Studio gets compiled into here.
  • App_Web_xxx.dl -This contains all "CodeBehind" code. Typically the c# or VB classes that are in files outside of the  App_Code folder. (aspx pages etc...). I've found that you are more likely to have more of these if web pages have the same class definitions in them. "public partial class _default" was a classic example in some of my files. You can reduce the number of dlls byreducing this duplication.
  • App_global.asax.dll - ??????????????????????????

A Nicer Way

There is a nice tool called "Web Deployment Projects for VS 2008." A walkthrough and download is available here.

Oncedownloaded and installed you get an extra option in the build menu and whe nright clicking on your solution. This allows you to ass a deployment project. 

Like publishing,setting properties and for the new project will allow you to choose  "Allow this precompiled site to be updatable". But also allows you to merge the nasty dlls into one and ensure the dll always has the same name.

Basically, App_Code.dll, App_Web dllls and App_global dlls merge into one so, you dont have to remember which dll is required for your fixes or updates later on.