在Windows服务器上维护多个Web站点时，应用池管理和站点发布几乎占据日常运维一半以上的时间。手工点击IIS管理器虽然直观，但一旦站点数量变多，批量建池、改回收策略、更新代码目录这类重复性操作就非常耗时。通过C#调用Microsoft.Web.Administration程序集，可以直接读写IIS配置系统，把应用池创建、停止、回收和站点发布全部写成自动化流程，既能减少人为遗漏，也方便集成到持续集成或一键部署脚本中。

环境准备与程序集引用

操作IIS应用池的核心程序集是Microsoft.Web.Administration，它随IIS管理功能一起安装，默认位于C:\Windows\System32\inetsrv\Microsoft.Web.Administration.dll。在Visual Studio项目中，右键引用选择浏览，定位到该路径即可。如果服务器上没有这个文件，说明IIS管理服务或管理工具没有安装完整，需要先在服务器管理器中勾选IIS管理控制台和IIS管理脚本和工具。

需要特别注意的是，调用IIS管理接口当前进程必须拥有管理员权限。因为所有配置最终都会写入C:\Windows\System32\inetsrv\config\applicationHost.config，普通用户没有写权限。在开发调试时，请右键Visual Studio选择以管理员身份运行；部署到生产环境时，也要确保执行程序的计划任务或服务账户具有本地管理员权限。

除了管理员权限，还应当确认目标机器上的IIS版本至少为7.0以上，因为Microsoft.Web.Administration是从IIS 7开始提供的托管管理接口。旧版IIS 6使用ADSI或WMI方式，代码模型完全不同。本文所有示例均基于IIS 7及之后的版本，Windows Server 2008 R2、2012、2016、2019以及Windows 10/11自带IIS均可适用。

using System;
using Microsoft.Web.Administration;
class Program
{
    static void Main()
    {
        using (ServerManager serverManager = new ServerManager())
        {
            foreach (var pool in serverManager.ApplicationPools)
            {
                Console.WriteLine($"应用池名称：{pool.Name}，状态：{pool.State}");
            }
        }
    }
}

上面的代码展示了最简单的枚举操作。ServerManager对象相当于IIS配置的入口，调用构造函数时会加载applicationHost.config内容，操作完成后调用CommitChanges才会持久化。枚举应用池不会修改配置，因此不需要提交。但在创建、修改或删除操作后，忘记提交是最常见的无效操作原因之一。

创建与配置应用程序池

应用程序池是IIS中隔离Web应用的运行边界，每个池对应一个或多个工作进程。通过ServerManager.ApplicationPools集合可以新增池，并设置.NET运行时版本、托管管道模式、回收策略和空闲超时等属性。下面这段代码演示了如何新建一个名为MyAppPool的应用池，并把它配置成使用集成管道和.NET Framework 4.x。

using (ServerManager serverManager = new ServerManager())
{
    string poolName = "MyAppPool";
    ApplicationPool pool = serverManager.ApplicationPools[poolName];
    if (pool == null)
    {
        pool = serverManager.ApplicationPools.Add(poolName);
    }
    pool.ManagedRuntimeVersion = "v4.0";
    pool.ManagedPipelineMode = ManagedPipelineMode.Integrated;
    pool.Recycling.PeriodicRestart.Time = TimeSpan.FromMinutes(120);
    pool.ProcessModel.IdleTimeout = TimeSpan.FromMinutes(20);
    pool.StartMode = StartMode.AlwaysRunning;
    serverManager.CommitChanges();
}

这段代码首先通过索引器判断池是否已存在，避免重复创建导致异常。ManagedRuntimeVersion用来指定CLR版本，v4.0对应.NET Framework 4.x或.NET 5及以后在IIS上运行时的兼容配置，v2.0对应.NET Framework 2.0/3.5。如果需要运行.NET Core或.NET 5+的站点，通常保持应用池为无托管代码即可，但使用Microsoft.Web.Administration时这些属性同样可以设置。

回收策略是生产环境中非常关键的配置。Recycling.PeriodicRestart.Time控制固定时间间隔回收，超过设定时间后工作进程会重新启动，释放内存碎片。对于内存泄漏风险较高的老旧应用，可以缩短到60分钟；对于健康的应用则可以延长或禁用。此外ProcessModel.IdleTimeout表示空闲超时，默认值为20分钟，若长时间没有请求，工作进程会自动关闭以节省资源。StartMode.AlwaysRunning需要应用池的启动模式支持，配合站点预加载可以避免首次访问慢的问题，但需要IIS 8.0以上版本。

停止、启动和手动回收是日常发布中经常用到的操作。停止应用池会强制结束工作进程，通常用于更新文件前避免文件被占用；启动则是恢复服务；回收则是让当前请求处理完后重启新的工作进程，对在线业务更加平滑。下面是基本操作示例。

using (ServerManager serverManager = new ServerManager())
{
    ApplicationPool pool = serverManager.ApplicationPools["MyAppPool"];
    if (pool != null)
    {
        if (pool.State == ObjectState.Started)
        {
            pool.Stop();
        }
        else
        {
            pool.Start();
        }
        serverManager.CommitChanges();
    }
}

需要注意的是，Stop和Start方法在执行时会立即改变运行状态，但配置文件中关于应用池的启动状态可能不会自动更新，因此仍然建议调用CommitChanges保持一致性。手动回收可以直接调用pool.Recycle()，它不会终止所有连接，而是等待旧进程处理完成后启动新进程。不过对于存在长连接的WebSocket应用，回收也可能造成瞬时断开，需要结合具体场景选择方案。

自动化部署Web站点的完整流程

有了应用池操作基础，下一步就是把站点发布自动化。创建站点的核心是ServerManager.Sites.Add方法，它需要站点名称、协议、绑定信息和物理路径。绑定信息通常写作*:端口号:或带域名的形式，例如*:8080:表示监听所有IP地址的8080端口。如果站点已经存在，通常只需要更新物理路径和应用池名称，避免重复创建造成冲突。

using (ServerManager serverManager = new ServerManager())
{
    string siteName = "MyWebSite";
    string physicalPath = @"C:\inetpub\wwwroot\MyApp";
    int port = 8080;
    Site site = serverManager.Sites[siteName];
    if (site == null)
    {
        site = serverManager.Sites.Add(siteName, "http", $"*:{port}:", physicalPath);
    }
    else
    {
        site.Applications["/"].VirtualDirectories["/"].PhysicalPath = physicalPath;
    }
    ApplicationPool pool = serverManager.ApplicationPools["MyAppPool"];
    if (pool == null)
    {
        pool = serverManager.ApplicationPools.Add("MyAppPool");
    }
    site.Applications["/"].ApplicationPoolName = pool.Name;
    serverManager.CommitChanges();
}

上述代码中，site.Applications["/"]代表站点的根应用程序，VirtualDirectories["/"]则对应根虚拟目录，物理路径就存储在该对象的PhysicalPath属性里。创建站点时如果指定的端口已经被其他站点占用，CommitChanges会抛出COMException，提示绑定冲突。实际部署脚本中应当先检查现有绑定，或者使用serverManager.Sites.FirstOrDefault(s => s.Bindings.Any(b => b.EndPoint.Port == port))来检测端口占用情况。

发布文件是自动化部署的另一半。使用System.IO编写递归复制目录的方法，将编译后的发布包从暂存目录复制到IIS站点物理路径。复制前建议先停止目标应用池，避免某些DLL被工作进程锁定导致覆盖失败。完整流程可以拆为四步：停止应用池、复制文件、启动应用池、可选回收。下面给出递归复制目录的通用实现。

using System.IO;
public static void CopyDirectory(string sourceDir, string targetDir, bool overwrite = true)
{
    DirectoryInfo source = new DirectoryInfo(sourceDir);
    DirectoryInfo target = new DirectoryInfo(targetDir);
    if (!source.Exists)
        throw new DirectoryNotFoundException($"源目录不存在：{sourceDir}");
    if (!target.Exists)
        target.Create();
    foreach (FileInfo file in source.GetFiles())
    {
        string destPath = Path.Combine(target.FullName, file.Name);
        file.CopyTo(destPath, overwrite);
    }
    foreach (DirectoryInfo subDir in source.GetDirectories())
    {
        string nextTarget = Path.Combine(target.FullName, subDir.Name);
        CopyDirectory(subDir.FullName, nextTarget, overwrite);
    }
}

这个方法会覆盖目标目录中的同名文件，但不会删除目标目录中多余的旧文件。如果希望实现严格一致的发布，可以在复制前清空目标目录，或者使用robocopy命令的镜像模式。不过对于大多数Web应用，增量覆盖已经足够，且能保留日志或运行时生成的文件。文件复制完成后，再调用前面提到的应用池启动和回收操作，整个部署过程即可全部由C#代码完成。

权限异常与常见问题排查

实际对接生产环境时，最容易遇到的是权限不足。ServerManager在内部调用COM接口访问IIS配置，如果进程没有管理员权限，会在构造函数或CommitChanges阶段抛出UnauthorizedAccessException。解决方式只有提升运行权限，例如在应用清单中嵌入requestedExecutionLevel为requireAdministrator，或者使用管理员账户创建计划任务。

另一个高频问题是缺少IIS管理组件。即使服务器上已安装IIS站点服务，如果没有安装管理工具，Microsoft.Web.Administration可能无法正常工作，表现为System.Runtime.InteropServices.COMException，错误码8007007E或80040154。检查服务器管理器中的Web服务器角色，确保包含IIS管理控制台以及IIS管理脚本和工具。添加组件后通常需要重启目标程序或相关服务。

应用池标识配置错误也会导致站点无法启动。默认应用池标识为ApplicationPoolIdentity，具有对站点目录的最低权限。如果站点物理路径位于C:\inetpub\wwwroot之外的自定义目录，需要给该标识或自定义账户授予读取和执行权限。否则会出现HTTP 500.19或503错误。通过以下异常捕获可以帮助定位问题类型。

try
{
    using (ServerManager serverManager = new ServerManager())
    {
        serverManager.CommitChanges();
    }
}
catch (UnauthorizedAccessException ex)
{
    Console.WriteLine("需要以管理员身份运行程序，错误：" + ex.Message);
}
catch (System.Runtime.InteropServices.COMException ex)
{
    Console.WriteLine("IIS管理接口调用失败，请确认IIS管理服务已安装，错误码：" + ex.ErrorCode);
}

总结来说，C#操作IIS应用池和自动化部署并不复杂，核心在于熟悉ServerManager、ApplicationPool和Site三个对象模型。权限和组件准备是前提，代码本身只需要按配置、提交、运行时控制三个层次组织。把常用的建池、升降版本、目录复制和站点绑定封装成类库后，就能很方便地集成到CI/CD流水线中，大幅减少手工操作带来的不稳定因素。