8

Web配置を使用してホストにWebアプリケーションを配置しています。公開コマンドを使用してVisualStudioから実行すると、正常に機能します。MSBuildからWebデプロイを使用してデプロイしようとすると、Webサイトにアクセスできなくなり、WebホストのWebコントロールパネルでさえWebサイトにアクセスできなくなります。Webサイトフォルダのアクセス許可と思われるものまで追跡しました。

Visual Studioから公開すると、ACLが更新され、Webサイトが正しく機能し、Webホストのコントロールパネルが機能します（以前のMSBuildからの展開によって壊れた場合でも）。

VisualStudioから実行した場合の出力は次のとおりです。

------ Publish started: Project: mywebapp, Configuration: Release Any CPU ------
Transformed Web.config using Web.Release.config into obj\Release\TransformWebConfig\transformed\Web.config.
Auto ConnectionString Transformed Views\Web.config into obj\Release\CSAutoParameterize\transformed\Views\Web.config.
Auto ConnectionString Transformed obj\Release\TransformWebConfig\transformed\Web.config into obj\Release\CSAutoParameterize\transformed\Web.config.
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Start Web Deploy Publish the Application/package to https://myhost.net:8172/MsDeploy.axd?site=mywebapp.com ...
Updating setAcl (mywebapp.com).
Updating setAcl (mywebapp.com).
Updating filePath (mywebapp.com\bin\mywebapp.Core.dll).
Updating filePath (mywebapp.com\bin\mywebapp.Core.pdb).
Updating filePath (mywebapp.com\bin\mywebapp.dll).
Updating filePath (mywebapp.com\bin\mywebapp.pdb).
Updating filePath (mywebapp.com\Views\Web.config).
Updating filePath (mywebapp.com\web.config).
Updating setAcl (mywebapp.com).
Updating setAcl (mywebapp.com).
Publish is successfully deployed.
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========

デプロイ中にVisualStudioが使用していると思われるACL情報を含むファイルを見つけました。これはmyapp.SourceManifest.xmlと呼ばれ、C：\ Projects \ mywebapp \ obj \ Release\Packageフォルダーにありました。

<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
  <contentPath path="C:\Projects\mywebapp\obj\Release\Package\PackageTmp" />
  <setAcl path="C:\Projects\mywebapp\obj\Release\Package\PackageTmp" setAclResourceType="Directory" />
  <setAcl path="C:\Projects\mywebapp\obj\Release\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>

私のMSBuildファイルには、展開を実行するための次のものが含まれています。

<Exec Command='"$(ProgramFiles)\IIS\Microsoft Web Deploy v2\msdeploy.exe" -verb:sync -source:package="mywebapp\obj\test\package\mywebapp.zip" -dest:auto,computername="https://myhost.net:8172/MsDeploy.axd?site=mywebapp.com",username=XXXX,password=XXXX,authtype=basic -allowuntrusted:true -setparam:name="IIS Web Application Name",value="mywebapp.com"' />

MSBuildを実行して展開すると、ファイルが更新されているのを確認できますが、ACLは更新されません。

構成が異なるため（リリースではなくテスト）、MSBuildの展開が別のフォルダーから行われ、mywebapp.SourceManifest.xmlファイルが異なります。

<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
  <IisApp path="C:\Projects\mywebapp\obj\Test\Package\PackageTmp" managedRuntimeVersion="v4.0" />
</sitemanifest>

異なるmywebapp.SourceManifest.xmlファイルはおそらくそれと関係がありますか？ACLを更新するにはどうすればよいですか？

アップデート

mywebapp.SourceManifest.xmlファイルの違いは、テスト構成の.csprojファイルに次のものが含まれていることが原因であることがわかりました。

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

これをTrueに変更し、マニフェストファイルはテスト構成とリリース構成で同じになりました。

また、Visual Studioから発行を使用すると、リリースでは機能しますが、テストでは失敗することがわかりました。そこで、デプロイの成功または失敗の原因となる2つの構成の違いを理解しようとしています。

4

1 に答える 1

5

私はなんとかそれを機能させることができました。私のウェブホストによると、彼らがマイクロソフトのウェブデプロイとIISチームと協力しているウェブデプロイにいくつかの問題があり、彼らはサーバーにいくつかの一時的な修正を適用しなければなりませんでした。奇妙なことに、それはすべて数ヶ月前に機能していたからです。

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>Web DeployがACLにアクセスしないように、プロジェクトファイルの設定を復元することになりました。私のウェブホストは、アプリプールIDの権限を削除し、ウェブコントロールパネルがウェブサイトフォルダーにアクセスできないようにしていると述べました。

また<_MSDeployVersionsToTry Condition="'$(_MSDeployVersionsToTry)'==''">7.1;8.0;9.0</_MSDeployVersionsToTry>、プロジェクトファイルに追加するように言われました。違いがあったかどうかはわかりませんが、追加しました。

于 2011-06-25T18:19:33.877 に答える