我之前帮团队解决过几乎一模一样的痛点——SOA架构下要批量搭建本地IIS开发环境，不想让每个开发者手动去VS里启动每个应用。分享两个亲测有效的方案：

方案1：预复制VSIISExeLauncher相关文件 #

既然VSIISExeLauncher.exe及其依赖文件是VS首次启动应用时生成的，且同版本.NET Core对应的文件是通用的，我们可以把这些文件提前打包，在脚本构建完成后自动复制到项目的bin目录下。

步骤： #

1. 从一台已经配置好的开发机器上，找到某个.NET Core项目的bin\IISSupport文件夹，把它打包成zip或者直接作为脚本的资源文件。
2. 在你的PowerShell脚本中，完成MsBuild构建后，将这个IISSupport文件夹解压/复制到目标项目的bin目录下。
3. 确保web.config中的配置保持不变：

   <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" />
   

这个方案的好处是完全贴合VS默认的调试流程，开发者打开解决方案后直接点击调试就能用，和手动配置的体验完全一致。唯一需要注意的是，不同.NET Core版本对应的IISSupport文件可能有差异，需要针对项目使用的框架版本维护对应的模板文件夹。

方案2：修改web.config直接使用dotnet运行时 #

如果不想依赖VS生成的启动器，我们可以直接让IIS通过dotnet运行时启动应用，这样就完全不需要IISSupport文件夹了。

步骤： #

1. 在脚本构建项目后，修改目标项目的web.config，替换<aspNetCore>节点的配置：

   <aspNetCore processPath="C:\Program Files\dotnet\dotnet.exe" arguments=".\YourAppName.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
   

   • 注意替换YourAppName.dll为实际的项目输出dll文件名
   • hostingModel可以根据项目需求设置为InProcess或OutOfProcess

2. 确保项目的bin目录下已经生成了对应的dll文件（MsBuild构建Debug模式会生成）。

这个方案的优势是不需要额外复制任何文件，脚本逻辑更简洁。开发者在VS中打开解决方案后，只要项目属性里设置了“本地IIS”作为调试服务器，点击调试时VS会自动附加到IIS托管的dotnet进程，同样能正常调试。

额外提示 #

• 对于批量处理多个应用，可以在脚本中维护一个应用列表，循环执行构建、配置IIS、复制文件/修改web.config的操作。
• 记得在脚本中检查dotnet运行时是否已安装，以及IIS的ASP.NET Core模块是否已启用（可以用Install-WindowsFeature Web-Asp-NetCore命令安装）。

内容的提问来源于stack exchange，提问作者madd0