MSBuild опубликовать веб-проект из командной строки делает пакет вместо файловой системы
У меня есть веб-проект, который я публикую из командной строки, используя профиль публикации, который выполняет несколько дополнительных задач (исключает некоторые файлы и папки, grunt, публикует другой проект в свою очередь).
Одна из двух машин (A и B), она прекрасно работает с правой кнопкой мыши > опубликовать... в Visual Studio и выбор правильного профиля публикации.
Исторически на обеих машинах он также работал со следующей командной строкой:
msbuild MyProject.csproj /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=myProfile /v:n
Однако теперь машина B является неправильно публикуется.
Профиль публикации настроен с <WebPublishMethod>FileSystem</WebPublishMethod в верхней части, однако из журналов, он пытается опубликовать Тип Package вместо этого, без видимой причины.
Вот полный профиль публикации:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>..Production</publishUrl>
<DeleteExistingFiles>False</DeleteExistingFiles>
<ExcludeFoldersFromDeployment>Content;Scripts;Pages</ExcludeFoldersFromDeployment>
<ExcludeFilesFromDeployment>index-dev.html;index.html;debug.html;JSLintNet.json;Gruntfile.js;package.json;packages.config;publishall.bat;publishapi.bat</ExcludeFilesFromDeployment>
<BuildDependsOn>
$(BuildDependsOn);
RunGrunt;
PublishApi;
</BuildDependsOn>
</PropertyGroup>
<Target Name="RunGrunt">
<Message Text="Running grunt production..." />
<Exec Command="grunt production" />
</Target>
<Target Name="PublishApi">
<Message Text="Publishing API..." />
<Exec Command="publishapi" />
</Target>
</Project>
Как и следовало ожидать, поскольку он просто выполняет Package, в каталоге publishUrl никогда не появляются файлы. Опять же, профиль публикации отлично работает с VS2013, используя Правой Кнопкой Мыши опубликовать.
В журнале на машине а я получаю это отрывок:
**ValidatePublishProfileSettings**:
Validating PublishProfile(myProfile) settings.
Но в машине B он не появляется.
Далее в журнале на машине а он содержит:
**WebFileSystemPublish**:
Creating directory "..Production".
Copying objReleasePackagePackageTmpcache.manifest to C:SVNTrunksrcWeb SitesMyProject..Productioncache.manifest.
Copying objReleasePackagePackageTmpGlobal.asax to C:SVNTrunksrcWeb SitesMyProject..ProductionGlobal.asax.
Copying objReleasePackagePackageTmpWeb.config to C:SVNTrunksrcWeb SitesMyProject..ProductionWeb.config.
Copying objReleasePackagePackageTmpbinMyProject.dll to C:SVNTrunksrcWeb SitesMyProject..ProductionBlithe.Web.Collect.dll.
Но позже в журнале на машине B, вместо вышеизложенного, он содержит:
**Package**:
Invoking Web Deploy to generate the package with the following settings:
$(LocalIisVersion) is 7
$(DestinationIisVersion) is 7
$(UseIis) is True
$(IisUrl) is <<<some url>>>
$(IncludeIisSettings) is False
$(_DeploymentUseIis) is False
$(DestinationUseIis) is False
Единственное различие, которое я могу придумать между этими двумя машинами, заключается в том, что я установил обновление на машине B (проблемная машина) для "Windows Azure SDK for .NET (VS2013) - 2.3". Есть идеи, как и почему это могло сломать его?
Я попытался добавить /p:PublishProfileRootFolder="PropertiesPublishProfiles" как упоминалось здесь , но это не сработало.
1 ответ:
Добавление:
/p:VisualStudioVersion=12.0Чтобы команда работала.
На машине B также была установлена Visual Studio 2008, в то время как на машине а ее не было. установка версии 12.0 или даже 11.0 работает. Установка значения 10.0 игнорирует профиль публикации и просто выполняет установку пакета.
Удивительно, но по умолчанию он равен 10.0.
Эта проблема не возникала до обновления до Azure SDK 2.3 , в котором были внесены некоторые изменения в веб-публикацию, так что это вполне могло привести к этому вопросу.
Comments