How do I report a bug in Windows Server Service Bus?

Question

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:

1. Microsoft.Cloud.ServiceBus.dll has a reference to Microsoft.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.
2. 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.
3. 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.
4. 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, - in System.Attribute.InternalGetCustomAttributes(PropertyInfo,Type,bool), more precisely, this line. That line did not exist in the previous version of mscorlib, 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.
5. 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

1. 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.
2. Provide a fake DLL with the needed type. Can't do that, because everything is strongly named.
3. 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.

Answer 1

I know it's a late answer to the question and it is actually not the answer to the question asked, but today, after installing VS 2015 RC on a PC with Windows Service Bus 1.1 and restarting the PC, my service bus gateway service stopped working and I went through all the pain described in this question but finally could make a solution out of the fake assembly scenario. Here's the solution:

1. Created the fake assembly Microsoft.Cloud.Common.AzureStorage.dll with version 2.1.0.0 and signed it with a new key file.
2. Disassembled it using: ildasm /all /out=azurestorage.il Microsoft.Cloud.Common.AzureStorage.dll
3. Extracted the public key and public key token from another Microsoft.Cloud.* assembly located in service bus folder by ildasm /Tp Microsoft.Cloud.Common.Diagnostics.dll
4. Opened azurestorage.il in a text editor and changed the public-key token and public key with the ones extracted in the last step
5. Reassembled the il file: ilasm /dll azurestorage.il /out=Microsoft.Cloud.Common.AzureStorage.dll
6. Registered the assembly for signature verification skipping using: sn -Vr Microsoft.Cloud.Common.AzureStorage.dll
7. Installed the resulting assembly to GAC: gacutil /i Microsoft.Cloud.Common.AzureStorage.dll

and it finally worked. Hope this helps anyone who got stuck in this problem.

Answer 2

As given in this answer by Jafin there is fortunately an official fix from Microsoft release 10/23/2015 that solves the issue with .NET 4.6.

Download here: Update for Service Bus Server 1.1 (KB3086798)