Shared assemblies, without the GAC

cjmos — Tue, 28 Oct 2008 22:08:00 GMT

One of the projects I've been working on recently required each of our web applications to have their own IIS websites and bespoke files (master pages, images, styles etc.) but also each have access to a shared code library which would reside in a central location on the server. Dealing with the shared UI layer (pages, controls etc) was easy, we could just set up a virtual directory in IIS 'SharedCode' and point it to the central location. Dealing with the assemblies generated from our shared code library (C#) projects and having them reside in a central location, outside of each application however, was not so straight forward.

The usual way to achieve this would be to put these shared assemblies into the global assembly cache (GAC). However, for this particular project, the GAC wasn't such a viable option. There are many benefits in using the GAC (proper version control is an absolute must in some cases) but there are also a number of reasons why adding assemblies to the GAC may not be viable or sensible for your particular project, the main reasons that affected us were:

Some of the assemblies referenced other third-party, closed-source assemblies which were not signed with a strong name. - In order to add any assembly to the GAC, the assembly itself AND all assemblies it references must be signed. Unless you have access to the source of these third party assembly, there is no way to sign it.
The project and the shared code in your assemblies will be constantly being developed by a team of developers – It's advisable that your development platforms mirror the set-up of your live server. If you plan on putting your shared assemblies in the GAC on the live server, then ideally they will also be in the GAC on your development platforms. If you have a team of developers working on a shared code library, it would get extremely difficult and time consuming to make sure every developer has the correct version of the code in their GAC. In our case, the shared code library wouldn't be incremented in versions but rather always have a single current version.

However, we still needed a way of centralising the assemblies and allowing each separate application to find and use them. We already had a shared directory that contained the common UI layer of my application, this had been set up as a virtual directory on each website. Ideally I needed to structure my web application like this:

WebRoot
    Bin
    SharedCode
        Bin
        Templates
        .. .
    Styles
    etc..

Luckily, there is a way to tell your application to look for it's assemblies in locations other the the 'bin' directory.

If you put your assemblies in the root 'bin' directory of your web app, you don't need to tell the ASP.Net CLR to reference them or where to look for them, this is all done automatically. If you put your assemblies in the GAC, you don't need to tell ASP.Net where to look for them but you do need to register them. If you you put your assemblies anywhere else, you need to both register them and tell ASP.Net where to find them. Both of these tasks can be achieved in the web.config.

Registering the assemblies

You might already recognise this step. Whenever your reference an assembly in the GAC or one that's part of the CLR, you also use this method. However, in this case, since our shared assemblies aren't strongly named, we don't have to fully qualify our assembly reference (with a text name, version, culture, and public key token). To register the assemblies (tell the app to look for them), add this line for each assembly:

Telling ASP.Net where to look with a probing path

To tell ASP.Net where to look for these assemblies, you need to create a probing path in your web.config. ASP.Net will add this path to it's list of places to look for it's assemblies.

*note: if you need to add multiple probing paths, you can delimit them with a semicolon e.g. <probing privatePath="SharedCode\Bin;ThirdParty\Bin" />

Creating a NTFS Junction Point for your shared code

As mentioned above, originally, all of our applications had access the the 'SharedCode' folder via a Virtual Directory set up in IIS. Unfortunately (but probably for good reason), you can't load assemblies from virtual directories. You also cannot tell a web application to look for assemblies outside of the scope of the application (e.g <probing privatePath=”C:\Bin”> will not work). To get around this problem I created an NTFS junction point in the root of the applications that pointed to the shared code directory. NTFS junction points are basically direct links to other directories on the local machine. For more information on NTFS junction points see:

http://support.microsoft.com/kb/205524

*Note: pay special attention to the section 'Usage Recommendations'. Using NTFS Junction points can be dangerous because what you do to the junction point will also affect the target directory.

*Also note: For some reason Windows Server 2003 has problems recognising Junction points created by some third party applications. For this reason, it's easier to use linkd.exe which can be found in the Microsoft Windows Server 2003 Resource Kit.

FileUpload controls don't do ajax!

cjmos — Wed, 03 Oct 2007 19:23:00 GMT

A guy I work with mentioned this tip to me today so I thought I'd share it (not the ground-breaking first article I was hoping for but don't worry that's coming!):

FileUpload controls don't work with ajax, so its probably best not using them with ajax!

If you feel you must then the way to do it is to make your file upload submit button a postback trigger, and set the UpdateMode of your update panel to conditional. This allows you to do your ajax stuff as usual, but when you come to do the file upload you will have a full page refresh: -

<asp:UpdatePanel ID="AjaxUploader" runat="server" UpdateMode="Conditional">
<Triggers>
    <asp:PostBackTrigger ControlID="UploadButton"/>
</Triggers>
<ContentTemplate>
    <asp:FileUpload ID="FileUpload1" runat="server" EnableViewState="true" /> 
    <asp:Button ID="UploadButton" runat="server" Text="Upload File" OnClick="SomeFunction" />
</ContentTemplate>
</asp:UpdatePanel>

One thing that really caught me out was a lovely little gotcha with asp:placeholders and their 'Visibility' property, I was toggling a form in and out of view and this caused the image upload to fail first time it was used, although it would then be fine after that. One quick solution is to use a div and play with it's style property instead: -

<div id="layerToToggle" runat="server" style="display:none">
<p>Content to toggle</p>
</div>

Then in code behind:

layerToToggle.Style.Add("display", ""); // show
layerToToggle.Style.Add("display", "none"); // hide

Chris Moseley on Web Development

Shared assemblies, without the GAC

FileUpload controls don't do ajax!