2016-07-14 1 views
3

Использование libsodium-net для всей своей безопасности в Azure Service Fabric Reliable Service, в моем локальном кластере dev все работает нормально (хотя мне пришлось установить libsodium-64.dll для копирования в выходной каталог).libsodium-64.dll не найден на производстве Azure Service Fabric cluster

К сожалению, при развертывании на реальном кластере в лазури он выдает следующее сообщение об ошибке:

Unable to load DLL 'libsodium-64.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Я проверил на удаленный рабочий стол-ки в одном из узлов и DLL копируется через в тот же каталог, что и служба, точно так же, как и в моем dev-кластере. Не могу понять, почему его нельзя найти в производстве.

Я пробовал установить переменную среды PATH, как это предложено в this answer, и подтвердил, что он действительно установлен - к сожалению, это не помогает.

Есть ли что-то особенное, что мне нужно сделать, чтобы получить ASF, чтобы забрать DLL?

Редактировать: также пытались добавить DLL к System32 на всех узлах, также не решили.

+0

Здесь действительно не должно быть ничего особенного. Можете ли вы изменить сервис, чтобы распечатать то, что, по его мнению, находится в рабочем каталоге, а также проверить путь? – masnider

+0

Да, не думал, что должно быть, logging 'Directory.GetFiles (AppDomain.CurrentDomain.BaseDirectory)' показывает "D: \ SvcFab \ _App \ ... \ ... Pkg.Code.1.0.0 \ libsodium-64 .dll "как находящийся там. Путь показывает C: \ Windows \ system32, Windows и обычные местоположения. –

+0

@TomDavies и что такое 'Environment.CurrentDirectory'? Не могли бы вы предоставить эти пути как для производства, так и для вашего местного сообщества. – cassandrad

ответ

6

Оказывается, libsodium-64.dll зависит от Visual C++ Runtime, который, похоже, не присутствует на Azure VM. Ran Process Monitor, как упоминалось, here и увидел, что он собирал «libsodium-64.dll», но не смог выполнить «vcruntime140.dll» - только сообщение об исключении делает это практически невозможным для разработки.

Установил Visual C++, распространяемый на виртуальных машинах, и все, что кажется, чтобы работать нормально сейчас.

Если кто-то сталкивается с той же проблемой, вы можете решить эту проблему, добавив следующее расширение к профилю виртуальной машины шкалы, установленной в шаблоне развертывания ARM (VMSS -> properties -> virtualMachineProfile -> extensionProfile -> расширения):

{ 
    "name": "InstallVCRuntime", 
    "properties": { 
     "publisher": "Microsoft.Compute", 
     "type": "CustomScriptExtension", 
     "typeHandlerVersion": "1.7", 
     "autoUpgradeMinorVersion": true, 
     "settings": { 
      "fileUris": [ 
       "https://some.blob.storage.url/vc_redist.x64.exe" 
      ], 
      "commandToExecute": "vc_redist.x64.exe /q /norestart" 
     } 
    } 
} 

Все, что он делает, это захватить установщик и запустить его тихо. По-видимому, не было общедоступной ссылки на распространяемое, поэтому я просто загрузил ее и поместил в хранилище blob.

+0

Работала для меня после перезагрузки компьютеров, а также упаковала сборку релизов, чтобы отлаживать DLL-файлы. Благодаря! – Dagrooms

+0

Извините за то, что вы так невежественны, но где найти этот шаблон развертывания ARM, если кластер создан через Azure Portal? –

+0

@JohannesHeesterman, без проблем. Вы можете экспортировать его с портала.Найдите свой кластер, затем перейдите в раздел «Настройки»> «Автоматизация», и он предоставит вам шаблон вместе с различными способами его развертывания. –