Соответствующие зависимости (DLL) не копируются при развертывании с помощью Visual Studio 2013

В одном из веб-заданий, которые я развертываю, я ссылаюсь на одну из моих библиотек классов (Core), которая отвечает за запуск какого-то процесса (в данном случае отправка электронной почты с помощью SendGrid).

Когда я развернул свои веб-задания вручную (загрузив файл .zip), все работало нормально. Я очистил развертывание и повторно развернул его с помощью Visual Studio 2013, и у веб-задания начались проблемы. Основная проблема здесь заключается в том, что он ищет dll SendGrid, на который ссылается моя основная библиотека классов, а не мое консольное приложение, и он не завершает работу, выдавая следующую ошибку:

«Необработанное исключение: System.IO.FileLoadException: не удалось загрузить файл или сборку «SendGrid…. Версия = 4.5.0.0, культура = нейтральная, PublicKeyToken = 30ad4fe6b2a6aeed» или одна из ее зависимостей. Определение манифеста расположенной сборки не соответствует ссылка на сборку. (Исключение из HRESULT: 0x80131040)"

Я зашел на веб-сайт по FTP и обнаружил, что сборка SendGrid фактически находится не там, где находится мое веб-задание.

Мой вопрос: есть ли способ заставить эти зависимости копироваться в правильный каталог при развертывании с использованием VS 2013?

Спасибо,


person lopezbertoni    schedule 16.09.2014    source источник


Ответы (3)


Я являюсь членом команды, которая внедрила инструментарий веб-заданий в летнем обновлении 2013 г., и могу сообщить вам, что мы знаем об этой проблеме и проверили ее исправление для следующего обновления, которое выходит скоро. Тем временем обходной путь состоит в том, чтобы установить ссылки на сборки, которые вам нужны (только пакеты NuGet решат эту проблему), и повторно опубликовать. На самом деле мы используем пакет NuGet для выполнения логики развертывания веб-заданий внутри ПРОТИВ. Как только мы выпустим обновление, мы также выпустим NuGet (который сейчас проходит окончательное тестирование), чтобы у клиентов, использующих летние и обновления, эта проблема была устранена.

person brady gaster    schedule 16.09.2014
comment
Спасибо за информацию Брэди. Есть ли какое-то конкретное место, куда я могу сообщить о проблемах? У меня возникла проблема с неработающими папками решений (stackoverflow.com/questions/25810050/), а также при развертывании на веб-сайте мне приходится вручную добавлять строку подключения AzureJobsDashboard в Azure, а не помещать их в мое решение строку подключения и опубликуйте ее. Спасибо еще раз. - person lopezbertoni; 16.09.2014
comment
У нас есть несколько различных форумов, которые вы можете использовать, а также наши онлайн-инструменты MS Connect, которые позволяют вам сообщать нам о проблемах. Connect — это лучший способ, поскольку мы передаем проблемы клиентов прямо в соответствующие группы. - person brady gaster; 18.09.2014
comment
Спасибо, я зарегистрирую проблемы, которые я обнаружил с помощью предложенного инструмента. - person lopezbertoni; 18.09.2014
comment
@bradygaster Есть ли что-то особенное в пакетах nuget в этом сценарии, или я могу просто добавить скучные старые ссылки на обычные сборки (с копией local = true)? - person Howiecamp; 22.09.2014
comment
@bradygaster решает ли RC 1.0 эту проблему? Я только что попробовал, и это не сработало для меня, поэтому я спрашиваю. Но может я что-то не так делаю. - person lopezbertoni; 24.09.2014
comment
Решит ли это ту же проблему, если в выходной папке потребуются другие файлы, например представления Razor для Postal? - person Dave Van den Eynde; 04.01.2015
comment
Есть новости о том, когда будет доступно это следующее обновление? У меня возникла та же проблема с текущим развертыванием WebJob. - person Ozzy; 27.03.2015
comment
Во время публикации у меня возникла проблема, связанная с тем, что целевой ResolveWebJobFiles не существует в проекте, а еще одна — о конфликте версий в Microsoft.Azure.Storage.dll, полученном от NuGet. Ваш ответ просто напоминает мне, что я удалил Microsoft.Web.WebJobs.Publish. Исправлено переустановкой пакета публикации. - person Yang C; 31.03.2015

Похоже, это известная ошибка из Microsoft и, к сожалению, они не очень хотят это исправлять. Возможные решения:

  1. Вы можете вручную скопировать его
  2. Создайте событие сборки, чтобы скопировать его
  3. Кажется, некоторым людям посчастливилось добавить что-то вроде этого var t = typeof(ThirdParty.SomeClass);
person Nicolas    schedule 03.03.2016

Решил мою проблему, выполнив следующие действия.

  1. Установите указанные сборки «Копировать локально -> True»
  2. Установите для конфигурации решения значение «Выпуск».
person francorobles    schedule 30.04.2015