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" как упоминалось здесь , но это не сработало.

608   1  

1 ответ:

Добавление:

/p:VisualStudioVersion=12.0

Чтобы команда работала.

На машине B также была установлена Visual Studio 2008, в то время как на машине а ее не было. установка версии 12.0 или даже 11.0 работает. Установка значения 10.0 игнорирует профиль публикации и просто выполняет установку пакета.

Удивительно, но по умолчанию он равен 10.0.

Эта проблема не возникала до обновления до Azure SDK 2.3 , в котором были внесены некоторые изменения в веб-публикацию, так что это вполне могло привести к этому вопросу.

Comments

    Ничего не найдено.