CODEWITHSUNDEEP
c#asp.netwinformsdllazure
INNVTV
INNVTV

Reputation: 3367

Hosting a shared dll in azure

I have a C# Class Library that is being compiled into several applications, all of which are hosted as ASP.NET 4.0 WebForm and/or MVC Cloud Services on Azure. I would like to centralize this library so that any updates to the package does not require compiling and deploying each project every update cycle.

Obviously I have the option to create a WCF service, however that would require that I refactor both the class library as well as each project using it to become consumers of a service, and due to the complexity of the system, this may take several months and is not an option for the short term.

Since all my projects are in the same Affinity Group on Azure, is there an alternative to centralizing this DLL and it's methods for all projects to share? I couldn't find anything online so I am hoping to get some good options and thought starters from the community. Please let me know if I left any details out.

Upvotes: 1

Views: 1609

Answers (3)

Geethanga
Geethanga

Reputation: 1846

I also had a same the kind of problem. My scenario was to keep several plugins which were loaded in the run time depending on some conditions and these plugins should have the ability to update without disturbing the main application.

What I did was to store the dlls in the SQL table and retrieve them when needed, and load them in the run time using reflection. This was done in memory, I didn't have to store the dlls in the app root or somewhere. I think it's not a good practice to refer local paths in Azure.

Upvotes: 0

Sandrino Di Mattia
Sandrino Di Mattia

Reputation: 24895

David did a great job at explaining how you should manage deployment of your library. But besides that you need to make a change in your architecture to support this rather dynamic scenario.

First, instead of working with an implementation, your application should work with an interface. Let's assume your library allows you to calculate taxes and that the implementation of this tax calculator changes every few weeks. You don't want to change your application each time for this, and clearly, a WCF service isn't an option for you.

Now you could implement it as follows:

  • Class Library: TaxCalculator.Contracts containing the ITaxCalculator interface.
  • Class Library: TaxCalculator.ImplementationABC containing the ABCTaxCalculator class which implements the ITaxCalculator interface.
  • Class Library: TaxCalculator.ImplementationDEF containing the DEFTaxCalculator class which implements the ITaxCalculator interface (a few weeks later).
  • etc...

Your ASP.NET MVC website would only work with the ITaxCalculator interface. Using MEF you could scan a folder (LocalResource) for any assembly containing a class which implements the ITaxCalculator interface. As a result you decoupled the web application from the tax calculator library.

Like David already explained, you could store the latest version of the library in blob storage and download it locally (in a LocalResource) before loading the assembly with MEF. This way the original application remains unchanged and you'll still be able to make the necessary changes to your library.

In order to notify each instance that a new version has been released you have a few options. You could have a timer running that checks for changes in the container, you could use Service Bus Topics (each instance would subscribe to the topic), ... But like David already explained, you'll need to manage the rolling upgrade of the application yourself.

The alternative would be to redeploy your application, and instead of having a timer constantly polling for changes in the blob container, you could simply have a startup task that downloads the latest version of the library.

Upvotes: 4

David Makogon
David Makogon

Reputation: 71067

How about storing the shared DLL's in blob storage, in the same data center? On role startup, each instance would download the latest DLL to its local storage (in the app's root or some other folder where it needs to be).

Within the same data center, bandwidth between blob storage and your role instances is free, and 100Mbps x # of cores, so it's very quick. And, to update a DLL, you only need to upload it to one place (the blob container).

Upon updating one of the DLLs, you'd need to signal your role instances to either recycle (the safest method), or update themselves with the latest DLL. You can't have a "blob watcher" like you would have a file watcher (hence the suggestion of sending a signal). Alternatively, you can have some type of background thread checking a "dll" container every few minutes and, when spotting one that's changed, trigger the update locally.

One word of caution: If you update your DLL, and each role instance is polling for changes (or gets signaled to recycle), just be careful not to recycle all instances at the same time. Otherwise you'll be left with a service that's temporarily unavailable.

Upvotes: 3

Related Questions