Windows Azure Improvements since last year:

SQL Azure Improvements since last year:

1. Not just RESTful consumption of services anymore
2. Works with standard TDS based tools (SQL management studio)

Microsoft has a vision of "Three screens and a Cloud".

The screens include:

1. Mobile devices
2. Desktop computers
3. Internet connected TVs

   They can all be united by data and services in the cloud.

Public Data in the Cloud (Codename "Dallas").

Repository for public data sets that can be consumed in any number of ways (and easily by Azure)

Accessed through Microsoft PinPoint

Sign up for a CTP key

Some data includes NASA mars photos, GIS data, AP News articles

PinPoint:

Centralized marketplace for partner providers, Azure ISVs and implementers, and gateway to "Dallas" public Data.

"System Center" will plugin to Azure to monitor your Azure instances, check to meet SLAs, and enable you to scale up the Azure instances directly.

2010 will include ability to have the Azure cloud be able to establish a network connection to on-premise resources (i.e. self hosted SQL Server)

WordPress is moving to Windows Azure

Assembly plugin = System.Reflection.Assembly.LoadFrom(pluginFileName);

object pluginClass = Activator.CreateInstance(plugin.GetType("Plugin.PluginClass"));

This kind of architecture is pretty standard, and is one of the few ways to accomplish this plugin model in .NET (other than some cutting-edge things like MEF). It works for the most part, but has some obvious limitations, such as:

• Once a DLL is loaded in this manner, it cannot be unloaded from memory (unless you mess around with AppDomains for each plugin)
• If your plugins want to talk to one another, they pretty much have to go through a lot of plumbing code in the main app

Where it really starts to have problems is when your plugin DLL needs to reference other DLLs used by the main application, or other plugin DLLs, and you find yourself in .NET Plugin DLL Hell.

Here is the crux of the problem:

When you add a reference to a DLL via Visual Studio, the framework will always try to load an exact matching version of that assembly, and will fail if it can’t find it. So, good luck if that DLL you depend on ever gets upgraded to a new version.

You can usually control this with a standalone application, because when you upgrade the app, you upgrade all the dependencies at the same time. In a plugin model, you can’t control when other dependencies are upgraded, and so your plugin will simply fail to load when this happens.

There is no way in the .NET framework to tell it to use a particular version of a DLL or any newer version it finds.

Here’s a scenario to demonstrate this:

• You have a WinForms application, that loads plugin DLLs when the app starts.
• The main application uses a third-party control library.
• You write a plugin that also needs the controls, so you add a reference to the version that the main app uses.
• At some point, someone working on the main app upgrades it to use a newer controls DLL, recompiles the app, and distributes it along with the newer controls DLL.
• Since no work was actually done on your plugin, no one has recompiled it against the newer controls DLL.
• When the upgraded application starts and loads your plugin, your plugin goes BOOM!

Another scenario:

• Your plugin references another plugin
• The other plugin gets upgraded without your plugin getting recompiled
• Your plugin now goes BOOM!

When I say “BOOM!”, I mean you’ll probably see something like this from the Fusion log:

"System.IO.FileNotFoundException: Could not load file or assembly ‘YourDependentAssemblyNameHere’ or one of its dependencies. The system cannot find the file specified.” 

I am having a similar problem with my Windows LiveWriter plugin, xPollinate. Every time Microsoft releases a new version of LiveWriter, all of its DLLs that I reference have new version numbers, and so my plugin will fail to load unless I recompile my plugin against the latest versions of the DLLs.

Well, so what are our options to deal with this?

• You can simply not add any references in your plugin project via Visual Studio, and just use reflection for everything (yuck). This is probably a little easier now with the dynamic keyword in C#, but not much.
• You can try to get the main application to put in assembly binding redirects in its config file for any common DLLs that might be referenced by plugins.

That’s all I can see at this point. Here’s to hoping a future version of the framework will make this easier for us.