如何报告 Windows Server 服务总线中的错误? [英] How do I report a bug in Windows Server Service Bus?

问题描述

我试着用谷歌搜索.Microsoft Connect 不接受服务总线的错误.Azure 门户发送到 MS 论坛或 StackOverflow - 所以我在这里.

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.

问题确实在标题中:如何报告 Service Bus 的错误?
(不是 Azure 版本，而是您在本地安装的版本)

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)

1. Microsoft.Cloud.ServiceBus.dll 引用了 Microsoft.Cloud.Common.AzureStorage.dll.它使用该程序集中的一种类型 - 即 StorageAccountInfo.它是配置部分(即 NamespacePolicyDataStoreFactorySection.Parameters.BlobStorageAccountInfo)的一部分，但显然只在 Azure 环境中有意义，从未在内部部署场景中使用.
2. 但这里有一个问题:Microsoft.Cloud.Common.AzureStorage.dll 实际上并未随 Service Bus 1.1 一起提供.我试图在各种 SDK 和 Azure 工具包、示例和诸如此类(其中我有很多)以及在线找到它 - 并找到了有关该 DLL 的 zippo 信息或从何处获取它.这个 是我发现提到它的唯一地方.
3. 尽管本身就是一个 WTF，但 DLL 的缺失并没有真正阻止任何工作:在内部部署场景中，该类型实际上并未被任何代码触及，因此无需抱怨.
4. 但这里有第二个问题:mscorlib.dll v4.6.7.0(VS2015 CTP5 附带)与之前的版本 4.0.30319.34014 相比有细微的变化， - 在 System.Attribute.InternalGetCustomAttributes(PropertyInfo,Type,bool)，更准确地说，这一行.该行在以前版本的 mscorlib 中不存在，一切都很好.但现在它确实存在，导致属性类型被touched，导致加载DLL失败，因为DLL不存在.
5. 所以整个过程从加载配置部分NamespacePolicyDataStoreFactorySection开始，工作方式如下:

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)

一些(徒劳的)尝试解决方法

1. 从配置中删除配置部分.不幸的是，服务总线在这方面不是很容错:当部分不存在时，会因 NRE 失败.也不可能提供替代的配置部分handler"，因为在 .NET 配置系统中，handler"和data"是一回事.
2. 提供具有所需类型的假 DLL.不能这样做，因为一切都是强命名的.
3. 在某处找到丢失的 DLL.试过了，失败了.网络上没有提到 DLL，更不用说比特了.

细心的读者可能会问:哇，等一下！VS2015 CTP5?！你是说你在一台工作机器上安装了预发布软件?！那么，当然不行，你还指望什么?这会教你成为尝鲜者！
细心的读者绝对正确:完全是我的错，我知道潜在的危险，我还是做了，对我有好处.

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.

但这不是重点.我安装的预发布软件不会减少引用 DLL 的 WTF，但不会减少它的发布.虽然我个人会没事，但我只是想确保这不会在 .NET 5 发布并点击 Windows 更新时突然停止工作.

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.

推荐答案

我知道这是对这个问题的一个迟到的答案，它实际上不是对所提出问题的答案，但是今天，在 PC 上安装了 VS 2015 RC 之后，Windows 服务总线 1.1 并重新启动 PC，我的服务总线网关服务停止工作，我经历了这个问题中描述的所有痛苦，但最终可以从虚假组装场景中找到解决方案.解决方法如下:

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. 使用版本 2.1.0.0 创建假程序集 Microsoft.Cloud.Common.AzureStorage.dll 并使用新的密钥文件对其进行签名.
2. 使用以下命令对其进行反汇编:ildasm/all/out=azurestorage.il Microsoft.Cloud.Common.AzureStorage.dll
3. 通过 ildasm/Tp Microsoft.Cloud.Common.Diagnostics.dll 从位于服务总线文件夹中的另一个 Microsoft.Cloud.* 程序集中提取公钥和公钥令牌
4. 在文本编辑器中打开 azurestorage.il 并将公钥令牌和公钥更改为上一步提取的令牌
5. 重新组装 il 文件:ilasm/dll azurestorage.il/out=Microsoft.Cloud.Common.AzureStorage.dll
6. 使用以下命令注册用于签名验证跳过的程序集:sn -Vr Microsoft.Cloud.Common.AzureStorage.dll
7. 将生成的程序集安装到 GAC:gacutil/i Microsoft.Cloud.Common.AzureStorage.dll

它终于奏效了.希望这可以帮助任何陷入此问题的人.

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

这篇关于如何报告 Windows Server 服务总线中的错误?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！