Я попробовал Google. Microsoft Connect не принимает ошибки для служебной шины. Azure Portal отправляется на форумы MS или в StackOverflow, поэтому я здесь.
Вопрос действительно в заголовке: как сообщить об ошибке с Service Bus?
(а не версию Azure, но тот, который вы устанавливаете в помещениях)
И вот проблема:
-
Microsoft.Cloud.ServiceBus.dllимеет ссылку наMicrosoft.Cloud.Common.AzureStorage.dll. Он использует один тип из этой сборки, а именноStorageAccountInfo. Это часть раздела конфигурации (а именно,NamespacePolicyDataStoreFactorySection.Parameters.BlobStorageAccountInfo), но, по-видимому, имеет смысл только в среде Azure и никогда не используется в сценарии на локальном уровне. - Но вот catch:
Microsoft.Cloud.Common.AzureStorage.dllна самом деле не поставляется с Service Bus 1.1. Я попытался найти его в различных пакетах SDK и Azure, образцах и много чего (из которых у меня много), а также в Интернете - и нашел информацию об этой библиотеке zippo или где ее можно получить. Это... это единственное место, где я нашел упоминание об этом. - Несмотря на то, что WTF сам по себе, отсутствие DLL действительно не мешает чему-либо работать: тип на самом деле не затрагивается каким-либо кодом в локальном сценарии, поэтому никаких жалоб.
- Но вот второй улов:
mscorlib.dllv4.6.7.0 (который поставляется с VS2015 CTP5) имеет небольшое изменение по сравнению с предыдущей версией, 4.0.30319.34014, - вSystem.Attribute.InternalGetCustomAttributes(PropertyInfo,Type,bool), точнее, эта строка. Эта строка не существовала в предыдущей версииmscorlib, и все было в порядке. Но теперь он существует, что приводит к касанию типа свойства, что приводит к загрузке DLL, которая терпит неудачу, поскольку DLL не существует. - Итак, весь процесс начинается с загрузки раздела конфигурации
NamespacePolicyDataStoreFactorySectionи работает следующим образом:
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)
Некоторые (бесполезные) попытки обходного пути
- Удалите раздел конфигурации из config. К сожалению, служебная шина не очень устойчива к ошибкам в этом отношении: сбой в NRE, когда раздел отсутствует. Также невозможно предоставить альтернативный раздел конфигурации "обработчик", поскольку в системе конфигурации .NET "обработчик" и "данные" - это одно и то же.
- Предоставьте поддельную DLL с нужным типом. Не могу этого сделать, потому что все сильно названо.
- Найти отсутствующую DLL где-нибудь. Пробовал это и потерпел неудачу. В библиотеке нет упоминаний о DLL, не говоря уже о битах.
Тщательный читатель может спросить: аа, подожди минутку! VS2015 CTP5?! Вы говорите, что вы установили программное обеспечение до выпуска на рабочую машину?! Ну, тогда, конечно, это не сработает, чего вы ожидали? Это научит вас быть ранним усыновителем!
И внимательный читатель был бы абсолютно прав: полностью моя вина, я знал о потенциальных опасностях, я все равно делал это правильно.
Но это не так. Моя установка предварительного выпуска программного обеспечения не уменьшает WTFness ссылки на DLL, но не отправляет ее. Хотя я лично буду в порядке, я просто хочу убедиться, что это не перестанет работать, когда .NET 5 выпущен и попадает в Центр обновления Windows.
