A friend of Rex's saw that we post "Walking 'round in Women's Underwear" every year and suggested that Rex might like to delve a little deeper into the comedian who created this little gem.
And, so we present another item from Bob Rivers (audio only - no video. Sorry, we know it sucks but is still, no less amusing).
Rex and I have searched the web trying to find a way to compile user controls into a library in Visual Studio, much the same way that one can compile web controls into a library using a class library. What we found was, in our opinions, unsatisfactory.
Originally using the techniques highlighted here we have, we think, come up with a pretty cool solution. This is for VS 2005 and higher - if you're using an older version then this might work or it might not. We simply don't know.
To Create:
Step 1: Create a new web site (not a web application, although we toyed with that for a while). Delete everything in the site that can be deleted (we're going to be starting from scratch) or select "Empty Web Site" from the project screen.
Step 2: Import any user controls you want in your library (any file with a .ascx extension) or create new ones.
Step 3: Give each control a namespace (this is necessary for calling it up later). You can do this in the ascx file (rather than the codefile which one would do if one were making a class library). In the control registration block, add:
classname='[your namespace and class name]'
For example:
<%@ control language='vb' codefile='rexscontrol.ascx.vb' classname='rexthestrange.rexscontrol' inherits='rexscontrol' %>
Your namespaces, of course, can vary - they're just for reference on the other end.
Step 4: Publish. On the publish dialog screen uncheck all options. The exception is that you might want to publish each control as a separate assembly, in which case check "use fixed naming and single page assemblies." At any rate, it is imperative to uncheck "allow this precompiled site to be updatable" as this will put the XML code in a separate file and we don't want this. We want it all to be in one nice neat little package.
Step 5: Open a DOS window (yes, a DOS window - or a console window if you want to call it that) and navigate to where you published the site. Go to the "bin" directory and get a listing. If you selected "use fixed naming and single page assemblies" then you will find a listing of one dll per control that you made. If you didn't there should just be one dll - for the whole site (or, soon to be, library).
Step 6: Now here's the cool part. When you publish a .net web site the dlls are named not, as one would expect, to the name of the project (or site) - that would be too easy and, besides, as the guy in the article I mentioned earlier pointed out, if you have two controls with the same name then confusion will ensue. So Visual Studio prefixes the name with "app_web_" and affixes the name with a hash that is created from the directory path. If you don't select "use fixed naming and single page assemblies" then you get one dll with the "app_web_" prefix and the hash code affix (with no name in between).
Either way that's really messy and not good for our library as that will cause confusion. This was causing us many headaches. Rex tried renaming the file, but this renders it useless (Visual Studio doesn't like that).
And then we stumbled on a post where someone mentioned ILMerge. ILMerge is a tool that takes several assemblies (dlls) and merges them into one. What is really cool about this is that it can take a single assembly and create a replica of it with a new name. You can download ILMerge here.
Once you have downloaded it (and added the location of the exe to your windows path) then, from your console (you are still in the console window, aren't you? and still in the web site's bin folder?) you simply type:
ilmerge /out:newdllname.dll olddllname.dll
And hit enter. Bingo. A new user control library has been born.
Step 7: In your project where you intend to use the controls simply add a reference to the dll and add the control as you would a web control (ie: add a "reference" directive to the page or add it to your web.config).
Step 6 - Revisited: But wait, there's more. If you did create multiple assemblies then you can still merge them all by using ILMerge, like so:
It's probably a good idea to create a batch file for this and keep it somewhere away from the publishing directory (remember that directory gets emptied on each publish) and make file references by full path names. Then, whenever you want to make a change to your library you can simply republish the site, run the batch file and you're done.
Step 7 - Revisited: Whenever you make a change to your library, any applications that you have that reference it will also need to be updated (because when you add a reference to a dll Visual Studio makes a copy of it. We've updated the original in Step 6 - Revisited, but not the copy.
But this is so simple. Open the "bin" branch of the tree in the Solution Explorer, right-click the dll in question and hit "Update Reference." A new copy of the dll will be copied over and you're back in business.
Pretty cool, huh?
Rex and I have tested this using Visual Basic and it works like a dream. It probably works in other languages like C# but we wouldn't know because C languages are, of course, for idiots.
This photograph doesn't highlight how it looks in real life, but this is the Strange Family tree this year. Rex decided to exchange some of his old incandescent pagan festival lights for some of those new LED models that they have out now.
And this is the result. What immediately came to my mind was that it looked like a scene from Blade Runner. Remember in Blade Runner that all of the lights (with a few ambient exceptions) were all fluorescent - and that's what Rex's tree looks like this year.
Those LED lights may seem cool, but they lack the warmth and coziness of the old fashioned version. Happy Pagan Festival (time to die).
