引言
Microsoft Web Deploy 是一项自动化部署技术，通过这项技术开发或是维护人员可以只用“一次点击”便完成向一台或者多台远程服务器发布网站程序的工作，省去了手工部署的繁琐操作，也能降低因为手工操作失误而导致网站程序工作异常的风险。
由于目前网络上关于 Web Deploy 的入门文章已经有很多了，这次就省略掉了安装和基本操作的讲解。
关于 Web Deploy 的使用入门，这里推荐 上的《》。
问题的发现
如果你已经尝试过使用 Web Deploy 来发布简单的网站程序，你可能接着会尝试发布一些复杂的网站程序。
不过，如果你尝试通过 Web Deploy 来发布包含文件上传功能，或者因为其它原因需要向网站目录进行写操作的网站程序，你就会发现一般情况下 Web Deploy 并不会给应用程序池指派写操作的权限，甚至还有可能把已经设置的写操作权限给消除掉！
这并不是 bug，其实微软的很多文章在介绍 Web Deploy 的时候没有说清楚，Web Deploy 技术可以做到“发布网站时自动应用相关设置”，但是如果在 Visual Studio (Express) 中使用 Web Deploy 来发布网站程序时，Web Deploy 并不会自动收集相关的配置信息——实际上由于可能涉及到的范畴相当广泛，通过程序也很难区分哪些信息在发布网站时有用，哪些没用。
而 Web Deploy 技术在设置 ACL 的时候也采取了一种较为严格的策略，即只保留必要的权限——默认情况下 Web Deploy 认为一个网站程序只需要读操作的权限，因而会删除掉已经为匿名访问者和应用程序池指派的写操作权限。
解决问题
像是这样的问题，网络上也已经有了很多讨论，比较常见的解决办法有这样两种：
- 生成部署包以后手动编辑部署包的配置文件，删掉 setAcl 规则。
- 使用 MSBuild 指令控制 ACL。
手动编辑配置文件
采用这种办法，就不能通过 Visual Studio (Express) 进行一键发布，因为发布时 setAcl 规则会重置，而使用一键发布时也不该去手工修改 *.SourceManifest.xml。
从另一个角度说，如果每次发布的时候都手动编辑 *.SourceManifest.xml，也实在是太麻烦了，和 Web Deploy 的初衷不符，因此这个办法是极端不推荐的，这里也不讲解了。
使用 MSBuild 指令
如果希望通过 Visual Studio (Express) 一键发布时不改变 ACL，使用 MSBuild 指令就是个不错的主意。
有些人可能通过相关的关键字搜索到建议编辑网站程序的项目文件，添加<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>，但是这样做存损坏项目文件、导致项目不能正常打开的风险，所以我一般不推荐直接去编辑项目文件，而是采取另一种方式。
如果用文本编辑器打开项目文件，将会看到其中包含了几个 Import 指令，而进一步调查这些指令所指向的文件，最终会发现这样的内容（由于原代码过长破坏了页面排版，所以这里添加了一些换行）：
$(WebPublishPipelineProjectDirectory)\$(WebPublishPipelineProjectName).wpp.targets
这段 MSBuild 指令表示，如果在网站项目的目录中创建一个文件名为“<项目名称>.wpp.targets”的文件，MSBuild 就会自动使用其中设置的指令。
所以我们就可以这样做：
- 先创建一个XML文件，命名为“<项目名称>.wpp.targets”（例如你的项目文件是MyProject.csproj，新建的文件就应该命名为“MyProject.wpp.targets”）；
- 编辑其内容，使编辑后的内容变成下面这样：
False - 然后在 Solution Explorer 中重新加载网站项目文件（否则 Visual Studio 会缓存项目设置，这也是使用 *.wpp.targets 文件的主要弊端），重新生成/发布时就不会再重置网站目录的 ACL了。
更高级的用法？
到目前为止所有的努力都只是让已经设置好的 ACL 不会被重置，而不是根据我们的需要自动设置 ACL，还不能真正算作一键发布。
难道说想要设置 ACL 就必须要有手动操作吗？
当然不是这样，在下一篇文章中就会讲解实现发布时自动设置 ACL 的办法。