Tuesday 15 February 2011

How to reference a user control deployed to the GAC

Warning: I don't consider myself a control developer in the classic sense (although I frequently write web parts for deployment within a SharePoint environment, the scope of that deployment is fairly small by default).

A lot of the functionality I build these days runs client-side, powered by my all-time best friend jQuery. Because of this, I find I'm most productive when I first establish the HTML structure in a static HTML file before moving the mark-up to a control. In the bad old days of complete ignorance, I would have had refactor this HTML and build it programmatically within a custom control—an approach I despise (HTML belongs in mark-up).

To overcome many of the drawbacks to custom control development, I prefer migrating my prototype to a user control (which has a front-end .ascx file) and then loading that control in my web part code-behind or custom field control. Check out the LoadControl documentation for information about how load a user control programmatically.

This works beautifully when the control's code behind is compiled to an assembly destined for deployment to the private bin directory. The user control can be built in isolation with the ascx file and code behind remaining wired up for easy access to Intellisense, etc. At build time, the .ascx file is copied somewhere and deployed somewhere useful (the CONTROLTEMPLATES virtual directory, if you like).

Things get trickier when that assembly is to be deployed to the global assembly cache (aka the GAC). In my case I wanted to do this for a custom field control; although most of the code for that control was already being deployed to the GAC, it made sense to keep these artefacts together in the same project. For my non-SharePoint readers, any assembly going into the GAC has to be strong named and signed (via the project's properties sheet > Signing tab); to add the assembly to the GAC, call gacutil:

gacutil –i "MyAsemblyName.dll"

With that out of the way, assume we've got two projects: the first (MyControls) is a class library outputting a signed assembly intended for the GAC; the second is a simple web site (Web).

GAC_User_Control_sln

The MyControls project contains our user control (for information about how to set this up, refer to my post How to add a web project item to a class library). The MyControls assembly is deployed to the GAC.

The web site project contains a copy of the .ascx user control file from the MyControls project and a web page with a @ Register directive pointing to the project-local .ascx file. The Web project doesn't reference the MyControls project because we want it to load the assembly it depends on from the GAC. The .ascx copy can be done manually but you'll likely want to automate this as a pre-build task.

While the MyControls project will now compile, the Web site project will fail to compile with the error: Could not load type 'MyControls.MyUserControl'. If you're in a SharePoint environment, you'll likely see get this as a parser error when the page is dynamically compiled at first request.

To fix this, you need to add an @ Assembly directive to the top of the .ascx file to reference the MyControls assembly deployed to the GAC. You'll need the assembly name and public key token to flesh out this directive. The assembly name can be retrieved from the project properties sheet (normally it's the same as the project anyway). Then extract the public key token using the strong name application (it's the short value):

sn –Tp "MyControls.dll"

If your AssemblyInfo.cs specifies a version number of 1.0.0.0, your @ Assembly directive should look something like this:

<%@ Assembly Name="MyControls, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=b3de351d91c5d4d2"%>

If you version numbers are automatically updated by some kind of policy or build event, beware you'll also need to update this directive as well, which may prove cumbersome.

This directive can be added to both copies of the .ascx file without impacting the MyControls build or edit-time experience.

Both projects will now compile and run, successfully loading the user control base type (i.e. the code behind) from the GAC.

You can download this solution here.

If you found this post helpful, please support my advertisers.

Wednesday 9 February 2011

Cannot open a TFS query in Excel

After successfully upgrading from VS2008/TFS2008 to VS2010/TFS2010 in the last few months, I today realised my machine still had an outstanding issue opening TFS queries from Visual Studio in Excel . After running the query in VS and clicking Open in Microsoft Office –> Open Query in Microsoft Excel, I was the reluctant recipient of this error message and no Excel openage:

Team Foundation Error

TF80012: The document cannot be opened because there is a problem with the installation of the Microsoft Visual Studio v10.0 Team Foundation Office integration components.  Please see the Team Foundation Installation Guide for more information.

While a number of solutions were offered, what follows is the complete set of steps I followed to fix the problem in my workstation environment (Windows Server 2008 R2 x64 with Office 2010 x86 and VS2010 RTM + TFS bits):

1. I first repaired Microsoft Visual Studio 2010 Ultimate from Control Panel. This took a while and required a restart of my workstation. All of my extensions and settings were retained (I think). On its own, this didn't fix the problem but others have reported is did for them.

2. From a command prompt running as administrator (I'm in the local administrators on my machine but that's not good enough), I re-registered the TFSOfficeAdd-in.dll. I only ran the x86 command because VS2010 is a 32-bit app and I'm running the 32-bit version of Office on Windows x64; while the same assembly exists in the 64-bit Program Files directory, I'm assuming it's for the 64-bit version of Office 2010 (just guessing):

regsvr32 "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\TFSOfficeAdd-in.dll"

3. Starting Excel from that same command window to ensure Excel started as an admin, I removed the v9.0 Team Foundation Add-In since I noticed it was showing alongside the v10.0 add-in and I wasn't sure if it was wreaking havoc. At this point, the Team menu was visible in Excel when running as admin but not when running as myself. In Excel 2010, you can manage add-ins from the File –> Options menu; click the Add-Ins tab and then choose COM Add-Ins from the Manage drop down.

4. I finally opened Excel again as myself and enabled the Team Foundation Add-In (v10.0). The Team menu now appeared in Excel.

At this point I can now open a TFS query in Excel.

Note, others have suggested deleting their Windows profile solved the problem for them, at the cost of deleting all of their settings, My Documents, etc. If you go down that path, be careful!

If you found this post helpful, please support my advertisers.

Tuesday 8 February 2011

Windows Server 2003 x64 on Hyper-V Driver Issues

Installing the 64-bit version of Windows Server 2003 requires service pack 2 and installation of the Hyper-V Integration Services.

Before upgrading RTM and installing the integration services, one of guys was having a bear of a time getting the network  card to appear in the guest.

If you found this post helpful, please support my advertisers.

Inspecting video and audio files

I've been using a handy little tool called MediaInfo to inspect some of the .flv files we display in the westernaustralia.com banner space and diagnose encoding differences.

The free tool displays all sorts of information about the audio and video streams:

MediaInfo

If you found this post helpful, please support my advertisers.