Reputation: 170569
An Azure role will likely need a set of Azure-specific .NET assemblies like Microsoft.WindowsAzure.ServiceRuntime
and Microsoft.WindowsAzure.StorageClient
. Turns out the latter is not in the GAC on Azure instances and so I have to set "Copy Local" to "True" in the Visual Studio project so that it gets into the service package and deployed to Azure. If I don't do that the assembly is not there and the missing dependency will prevent my role from starting.
This doesn't make any sense to me. Either it's just a bug or I don't get the big picture.
Is there a good reason why the key assemblies would not be present in Azure instances GAC and I have to carry them with my service package?
Upvotes: 3
Views: 1107
Reputation: 2116
Is there a good reason why the key assemblies would not be present in Azure instances GAC and I have to carry them with my service package?
I would like to point out that not every project needs to work with storage, so it makes sense the storage assembly is not pre-installed. One less assembly to load, a tiny performance improvement you get. But every project need to be integrated with Windows Azure runtime. So runtime assemblies are pre-installed. From my experience, by default when we create a Windows Azure web/worker role, the storage assembly reference automatically has copy local set to true. Thus, we don’t need to do extra tasks to make it work.
Best Regards,
Ming Xu.
Upvotes: 0
Reputation: 31651
These key Azure assemblies aren't a part of the .NET Framework - that's why they are not in the GAC. Maybe in the future they will be added to the .NET Framework.
Azure is not dedicated to running only .NET code. People use it for other platforms such as Java, PHP, node.js, python, etc. It wouldn't make sense to add assemblies that are specific to .NET Azure implementations in the VM Role Instances.
Yes - this was also an annoyance when I first started on Azure, but the same is true if you would have published this on-premise to a machine without the Azure SDK.
Upvotes: 3