Wix Web应用程序：如何在不替换所有现有映射的情况下添加扩展？(Wix Webapplication: How do I add an extension without replacing al

Wix Web应用程序：如何在不替换所有现有映射的情况下添加扩展？(Wix Webapplication: How do I add an extension without replacing all existing mappings?)

我正在尝试通过WiX将.plan扩展名添加到我们的IIS 6.0网站。 我在用着

<iis:WebApplicationExtension CheckPath="no" Script="yes" Executable="[FRAMEWORKROOT]v4.0.30319\aspnet_isapi.dll" Verbs="GET,HEAD,POST,DEBUG" Extension="plan"/>

虽然这正在取代所有现有的应用程序扩展，但这不是我们想要的行为。 有没有办法简单地添加.plan？ 我们希望尽可能避免使用通配符，因为我们不确定它将如何影响网站的其余部分。 我认为APPCMD在我们的2003服务器上也不可用。

任何建议将不胜感激 ：）

I'm trying to add a .plan extension to our IIS 6.0 website through WiX. I'm using

<iis:WebApplicationExtension CheckPath="no" Script="yes" Executable="[FRAMEWORKROOT]v4.0.30319\aspnet_isapi.dll" Verbs="GET,HEAD,POST,DEBUG" Extension="plan"/>

Although this is replacing all of the existing application extensions, which is not the behaviour that we want. Is there a way to simply add .plan? We would like to avoid using the Wildcard if possible as we're not sure how it will affect the rest of the site. I don't think that APPCMD is available on our 2003 server either.

Any suggestions would be greatly appreciated :)

最满意答案

不幸的是，我们没有找到一种方法来使用iis干净利落地完成这项工作：WiX中的WebApplicationExtension。

我们发现这篇文章http://blogs.msdn.com/b/david.wang/archive/2004/12/02/273681.aspx提供了一个用于添加ScriptMaps的VBScript。 我们编辑脚本只执行HandleListOps函数（带有相关的参数），这样我们就不会遇到任何WScript问题。 然后我们从WiX中的CustomAction调用它，将vbs文件添加为二进制文件。

我们知道在安装程序中运行vbscript自定义操作并不理想，但幸运的是我们不会在外部分发应用程序，而只是在内部网站上使用，因此目标服务器环境相当广为人知。

Unfortunately we didn't find a way to do this cleanly using the iis:WebApplicationExtension in WiX.

We found this post http://blogs.msdn.com/b/david.wang/archive/2004/12/02/273681.aspx that provides a VBScript for adding ScriptMaps. We edited the script to only execute the HandleListOps function (with the relevant params) so that we didn't get any issues with WScript. We then call this from a CustomAction in WiX, with the vbs file added as a Binary file.

We're aware that running vbscript custom actions from within an installer isn't ideal, but luckily we're not distributing the application externally and is only going to be used on an internal website, so the target server environment is reasonably well known.