The Devil's In The Details: It's The Little Things That Make Customers Happy
Details matter. Especially in building solutions people pay for. You've heard of the term WYSIWYG? Well why isn't the term YGWYPF more prevalent? It stands for You Get What You Pay For, and it's more true in today's economy than most people realize. So where are the little details in server controls? What are the mundane, time-consuming details that set apart a proof-of-concept from a true solution? Over the next few posts, I'll address them.
Registering in the “Add References” Dialog.
Hopefully someday Microsoft will give control developers a programmatic way to accomplish this. IMHO controls in the GAC should be automatically referenced here, but they're not. To show up in this dialog, your assembly has to be referenced in a very specific registry key. That key is: HKLM\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders. From there, each assembly needs to have a key, using the format AssemblyName.MajorVersion.MinorVersion.Build.Revision. So, for GenX.NET 3.0, you'll see the following entries:
Each new key has to have a default string value equal to the location of the assembly. This brings up an interesting problem: how can you be sure where your assemblies are going to be upon installation? Well, some people have custom actions they add to their installers to handle this, but I'm not smart like that. I take the simple approach, which it to always install a second copy of my assembly in the Program Files\Common Files folder, like this (corresponding folder locations highlighted in yellow):
Like I said, this is not necessarily the best way, just the most predictable. Kind of a pain in the butt, huh? Just to get some assemblies listed in the “Add References” dialog. Well, here is the end result:
Now, as you may have noticed, this system follows very closely with my previous discussions on versioning and compatibility. The point of all this is not to tell you that my way is the only right way of doing things, or that I think I'm a genius or the smartest guy in the world for coming up with it. The point instead is to come up with a complete system and follow through with it. Experiment, improve, refine. Remember, you're not writing server controls to just improve your own existence, but ease the stresses on others as well.
Next time, I'll discuss easing usability through thorough and consistent documentation, which is probably the most time consuming part of any decent API or control. This is also one of the main reasons why GenX.NET 3.0 took so long to complete.