I tried to google. Microsoft Connect doesn't accept bugs for Service Bus. Azure Portal sends to either MS forums or to StackOverflow - so here I am.
The question is really in the title: how do I report a bug with Service Bus?
(not the Azure version, but the one you install on premises)
And here is the issue:
Microsoft.Cloud.ServiceBus.dll
has a reference toMicrosoft.Cloud.Common.AzureStorage.dll
. It uses one type from that assembly - namely,StorageAccountInfo
. It's part of a configuration section (namely,NamespacePolicyDataStoreFactorySection.Parameters.BlobStorageAccountInfo
), but apparently only makes sense in the Azure environment, and never used in the on-premise scenario.- But here's the catch:
Microsoft.Cloud.Common.AzureStorage.dll
is not actually shipped with Service Bus 1.1. I tried to find it in various SDKs and Azure toolkits, samples and whatnot (of which I have plenty), as well as online - and found zippo information about that DLL or where to get it. This is the only place I found a mention of it. - Despite being a WTF in itself, the absence of DLL does not really prevent anything from working: the type is not actually touched by any code in the on-premise scenario, so no complaints.
- But here's the second catch:
mscorlib.dll
v4.6.7.0 (which came with VS2015 CTP5) has a slight change compared to the previous version, 4.0.30319.34014, - inSystem.Attribute.InternalGetCustomAttributes(PropertyInfo,Type,bool)
, more precisely, this line. That line did not exist in the previous version ofmscorlib
, and everything was fine. But now it does exist, which leads to the property type being touched, which leads to loading the DLL, which fails, because DLL is not there. - So the whole process starts with loading configuration section
NamespacePolicyDataStoreFactorySection
and works like this:
ConfigurationManager.GetSection ->
... ->
BaseConfigurationRecord.GetSectionRecursive ->
... ->
BaseConfigurationRecord.CallCreateSection ->
MgmtConfigurationRecord.CreateSection ->
ConfigurationElement.Reset ->
ConfigurationElement.get_Properties ->
ConfigurationElement.PropertiesFromType ->
ConfigurationElement.CreatePropertyBagFromType ->
Attribute.GetCustomAttribute (for property BlobStorageAccountInfo of type StorageAccountInfo) ->
... ->
Attribute.InternalGetCustomAttributes(PropertyInfo) ->
Attributes.GetIndexParameterTypes ->
RuntimePropertyInfo.GetIndexParameters ->
... ->
RuntimeMethodInfo.GetParameters ->
... ->
kaboom! (touches the return type, tries to load DLL containing it, fails)
Some (futile) attempts at a workaround
- Remove the configuration section from config. Unfortunately, Service Bus is not very fault tolerant in this respect: fails with NRE when section is not present. It is also impossible to provide an alternative config section "handler", because in the .NET config system "handler" and "data" are the same thing.
- Provide a fake DLL with the needed type. Can't do that, because everything is strongly named.
- Find the missing DLL somewhere. Tried that and failed. There are no mentions of the DLL on the web, let alone the bits.
A careful reader may ask: whoa, wait a minute! VS2015 CTP5?! Are you saying you installed pre-release software on a working machine?! Well then, of course it doesn't work, what did you expect? That'll teach you to be the early adopter!
And the careful reader would be absolutely correct: totally my fault, I knew potential dangers, I did it anyway, serves me right.
But that's not the point. My installing pre-release software doesn't diminish the WTFness of referencing a DLL, but not shipping it. While I personally will be fine, I just want to make sure this doesn't suddenly stop working when .NET 5 is released and hits Windows Update.