Asp.Net MVC Dynamic Assembly Resolve

Background

In my scenario, I required 3 things for my application system (in fact, only the first one is mandatory):

1. A set of library (framework) in which can be referenced by other applications
2. Updating the version of the library to know deployment strategy or bug discovery. This means that minor, macro and micro version are updated regularly between publishing.
3. The updated library should apply to all deployed systems

Up until now, in order to accomplish those three requirements, I had spent around 10 - 16 worth of working hours. A little waste I say. And to be honest, I still do not get the correct way to fulfill my needs.

The difficulty here in fact is the complexity of referencing the assembly, black box process of assembly resolving and inconsistency in application to resolve the assembly. Fortunately (and also unfortunately), this assembly complexity is only happen in web application (Asp.Net), and not winform (don't know about WPF though).

So what are the ways to resolve assembly that I had discovered up until now? N.B: the cons I stated below may be caused by insufficient of my knowledge and experience.

AppDomain.AssemblyResolve

One of the very first solution that I think will perfectly match my need is registering the AppDomain.AssemblyResolve event to reference the correct directory. It has some benefits:

• You don't need to state assembly version. You just need to state the public key token and assembly name.
• You can specify the location of the library.
• Unlike GAC, no installation required for the shared library. You just need to dump the file in the folder.
• The logic to resolve the assembly can be tracked by code, making debugging easier and new developer can know the assembly library location from code.

It really beneficial. You don't need any more effort in order to deploy a new installation, and the library can be separated from physical operating system. Moreover the version can be ignored, meaning that if you consistent in deploying only one version of library, then you are good.

However it also has several cons:

• Intermittently the dll file can be copied into bin folder, rendering update useless.
• Razor view engine does not call AppDomain.AssemblyResolve to resolving the assembly.
• Web config compliation assembly reference don't call AppDomain.AssemblyResolve.
• It must be signed with strong name.
• Not consistent. Assembly update trigger cannot be determined.

Both of the cons make this solution cannot fulfill my needs, because I need every new deployment with updated version to be applied in all application. However even though if I can hack the version (not updating the assembly version), I still cannot overcome the second cons, that the assembly reference by razor view engine.

Installing the Assembly in GAC

Well, let's go to the point here, the benefit of using GAC:

• Many experienced developer know how to use the GAC (it is standard).
• It can be referenced by razor view engine.
• The reference resolve is faster (not a big deal though).
• It is consistent. The assembly update is triggered and can be known.

Then, what is the cons?

• Assembly version need to be specified.
• It needs to be installed with gacutil or predefined installer (not a big deal though).
• The GAC location is locked and cannot be changed.
• It must be signed with strong name.

Well, despite of it's cons, this solution can be used to meet my needs though. I just need to prevent the assembly version to be updated, and just updating only the file version. Multiple version assembly can also be used with this way to prevent breaking change, but my experience say that multiple version assembly can lead to headache at debugging.

I have yet not trying to use assembly policy things though. However it will still a bothersome to create a binding redirect policy for every assembly increment though.

Copying dll at Application_Start global.asax

Well, I found this solution to be interesting if it can be applied, because of these benefits:

• The assembly does not need to be signed.
• The directory can be specified.
• The logic can be tracked by code.
• It can be referenced by razor view engine.
• The version does not need to be specified.

Then what is the cons?

• Huge performance impact.
• I still cannot get the correct logic to validate the flag to copy or not copy the dll, forcing the app to be compiled every request and rendering inproc session useless.
• Not consistent. Assembly update trigger cannot be determined.

Ehem, the unstable and huge impact in performance makes this solution not implementable. Even though it has several benefits.

Copy dll Every Publishing

I had not yet trying this approach yet. This approach will use a custom tool to deploy the assembly to any registered applications. This approach has several benefits:

• The base repository of dll can be specified. Does not need to use system location.
• It can be referenced by razor view engine as well as compile assembly at web config.
• It is consistent. The assembly update is triggered and can be known.
• The assembly version does not need to be specified.
• Does not need to be signed.
• The manual copy dll via ftp can also be used to hosted application.

The cons:

• Needs extra effort to make the tools for publishing. Do it manually and you will find yourself spending too much time.
• The deployment can break due to several reasons, such as access limitation or file is locked.
• You need to maintain the references.

Um well, this solution need a bit effort to establish. But it is possible. Moreover, I think that manual copy dll can also be used at hosted application.

Conlcusion

Well, I cannot make any conclusion here. I still do many experiment to solve this issue though. Up until now, copy dll every deployment is the best solution so far. It has several benefit and it can leverage the benefit from existing established automatic deployment. The solution is followed by installing GAC at the second place, with custom tool to automate generate assembly policy and install it in GAC.