Building a Better Server Control Experience, Part 2

Building a Better Server Control Experience, Part 2
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.

8 Comments

  • Doesn't gacutil do this?

  • Yuck, gacutil doesn't do it at all.

    gacutil was free, but Studio Cost money, I would expect this to be a feature too.





    You can point the registry key to the actual location in the GAC instead of to your program files location.

    This should make it relatively easy to write some generic code to do the job after gac-ing.

  • Andrew,



    This process has nothing to do with the GAC. It is only for referencing assemblies for Visual Studio .NET. Further, the GAC cannot be referenced for these files... if you look inside Studio you'll see physical locations for all the Framework assemblies as well.



    -Robert

  • Ya, I understand, thanks for the reg key name.



    I think VS should be relying on the contents of the GAC rather than a registry entry but its not out choice ;)



    If you use a dos/cmd window instead of windows explorer, you can see that :\Windows\assemly\gac is a folder with directories and files in it.

  • I think MS did the right thing in not having the GAC show up in this list. the GAC has nothing to do with VS.NET.



    It's also really easy to add the "AssemblyFolders" entry using the [TARGETDIR] property, so that no matter where the user installs the component, it will show up in the references. just let the user install where they want, and use "[TARGETDIR]" as the value of the default item for the AssemblyFolders key.

  • Hey, there is an option too. I think I'll take a look at that and see how much of a pain it would be to modify our stuff to work with that scenario.

  • It worked much better with the [TARGETDIR] property, although you have to be careful because of leading and trailing slashes.

  • Anything to help out the Michigan State government ;).

Comments have been disabled for this content.