Развертывание GIT на веб-сайте Azure: .DLL, скомпилированная на сервере, отличается от локальной .DLL

У меня есть проект MVC4 + EF4.0 .NET 4.5 (скажем, MyProject). Я прекрасно могу запустить проект локально. Когда я развертываю по FTP его на веб-сайтах Azure (не в облачной службе), он тоже работает нормально. Однако, если я выполняю развертывание GIT, сайт по большей части «работает» до тех пор, пока он не выполнит некоторые операции с базой данных EF5.0. Я получаю исключение Unable to load the specified metadata resource.

После отладки я заметил, что если я:

  • GIT развернет весь проект MVC4 (как и раньше)
  • FTP, а затем замените bin\MyProject.dll файлом bin\MyProject.dll, который я только что создал локально (Windows 8 x64, VS2012, инструменты Azure Oct'12) после нажатия GIT (т. Е. Тот же источник)

тогда веб-сайт, размещенный в Azure, работает нормально (даже функциональная часть базы данных EF5.0).

Локально созданная .dll примерно на 5 КБ больше, чем созданная для публикации в Azure GIT, и обе находятся в режиме «Release». Очевидно, что проект, созданный после нажатия на GIT (внутри Azure), строится иначе, чем на моем собственном ПК. Я проверил портал, он установлен на .NET 4.5. Я также GIT подталкивает всю папку решения (всего с одним проектом), а не только мелкие кусочки.

Когда я загружаю как локально созданные, так и удаленно созданные файлы MyProject.dll, я заметил следующее различие (FrameworkDisplayName)

  • местный: System.Runtime.Versioning.TargetFrameworkAttribute(".NETFramework,Version=v4.5", FrameworkDisplayName = ".NET Framework 4.5"),

  • удаленный: System.Runtime.Versioning.TargetFrameworkAttribute(".NETFramework,Version=v4.5", FrameworkDisplayName = ""),

Кто-нибудь знает, почему это происходит и что можно исправить?


person DeepSpace101    schedule 14.01.2013    source источник


Ответы (2)


Да, это ошибка, которая будет исправлена ​​в следующем выпуске. Хорошая новость в том, что это можно обойти сегодня:

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

Затем вам нужно изменить командную строку MSBuild в настраиваемом скрипте в соответствии с этой проблемой.

person David Ebbo    schedule 14.01.2013
comment
Спасибо, но изменение пользовательского скрипта в соответствии с вашими комментариями в заявке приводит к этой ошибке: remote: Creating directory "c:\output". remote: D:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(3083,5): error MSB3191: Unable to create directory "c:\output". Access to the path 'c:\output' is denied. [C:\DWASFiles\Sites\MyProject\VirtualDirectory0\site\repository\MyProject\MyProject.csproj]. Думаю, мне нужно исправить имя выходной папки. Какая конвенция? - person DeepSpace101; 15.01.2013
comment
Неважно, исправил. Выложил исправление ниже. Не обошлось бы без указателей, спасибо! - person DeepSpace101; 15.01.2013

Благодарим Дэвида за указатели и подсказки. Я проголосовал за него, но я также опубликую здесь точное решение проблемы. Я отредактировал свой исходный пост, потому что обнаружил серьезную ошибку, которую не заметил, пока не начал с нуля (переместил серверы GIT). Итак, вот весь процесс, который у меня сработал.

  • Загрузить Node.JS (он необходим даже для проектов .NET, поскольку его используют инструменты развертывания GIT)
  • Установите инструмент azure-cli (откройте обычную командную строку => npm install azure-cli -g)
  • В командной строке cd в корень вашего репозитория (cd \projects\MyRepoRoot)
  • Там введите azure site deploymentscript --aspWAP PathToMyProject\MyProject.csproj -s PathToMySolution.sln (очевидно, отрегулируйте пути по мере необходимости)
  • Это создаст файлы .deployment и deploy.cmd
  • Теперь отредактируйте файл deploy.cmd, найдите строку, начинающуюся с %MSBUILD_PATH% (будет только одна)
  • Insert the /t:Build parameter. For example:
    • [Before] %MSBUILD_PATH% <blah blah> /verbosity:m /t:pipelinePreDeployCopyAllFilesToOneFolder
    • [После] %MSBUILD_PATH% <blah blah> /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder)
  • Нажмите на GIT (проверьте вывод GIT, если все прошло хорошо)
  • Зайдите на свой сайт и убедитесь, что он работает!

Я буду рад, когда это исправят в следующей ревизии, поэтому мы не будем поддерживать скрипт сборки

person DeepSpace101    schedule 14.01.2013