Alternatives to GAC for sharing code between mvc sites

Question

Currently, we have c# object registered in the gac which we use to output a html/string which acts as a common menu for our web applications.

The benefit of the gac registered object is that we can update the gac object and all applications that reference it get the updates very efficiently. The html menu references some js and css resources at a common location.

The c# object does perform some logic based on servers/environments etc.

Are there alternatives other than GAC objects to perform similar functionality.

I had considered reference a mvc view from another project/controller but there was latency issues (i.e. the menu was rendered after the rest of the page). I feel it works best when rendered as part of the page.

other thoughts/ideas/options?

Answer 1

I believe you can use web.config to manually instruct each site to find a particular assembly at a common location:

http://msdn.microsoft.com/en-us/library/4191fzwb(v=vs.90).aspx

From the article:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
       <dependentAssembly>
         <assemblyIdentity name="myAssembly"
                           publicKeyToken="32ab4ba45e0a69a1"
                           culture="en-us" />
         <codeBase version="2.0.0.0"
                   href="http://www.litwareinc.com/myAssembly.dll"/>
       </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Alternatively, you could setup "probing" to search entire directories for your common libraries (also from the article):

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin2\subbin;bin3"/>
      </assemblyBinding>
   </runtime>
</configuration>

Answer 2

In a decade I never used the GAC and although I setup an internal NuGet server via TeamCity and let CI do all the rebuilding when my shared libs are updated, I wouldn't use that here, I don't think.

My gut says to build a little web service for this kind of stuff and have the other servers send up their data/state in an extensible form (JSON/XML) i.e. the data needed for the logic based on servers/environment, and have the web service perform the logic and send back either data in a model to translate into HTML, or HTML itself.

Add some cache-control headers, then I'd update the web service logic when I want to change the behaviour.

Edit

I just remembered that Martin Fowler blogged about this approach.

http://martinfowler.com/articles/microservices.html

So this is how I've worked for several years now. Of course we have programming logic in DLLs, but for business logic, rather than having it in libraries, we place it in many little web APIs and then it also open for other languages and mash-ups, PowerShell etc.

I guess what I'm saying is that a different architectural approach could help.

By-the-way, I first heard of this when I read, in 2008 I think, that Amazon's home page gathers data from >100 small web services.