IIS默认应用池WebApi项目HttpPost写日志报路径访问被拒绝，HttpGet正常如何解决？

问题根本原因 #

• 首先观察报错路径里的文件名是wooOrders.log，和你Reporting.Report方法的第一个参数完全匹配，说明你使用的Reporting组件内部存在路径拼接逻辑，它没有正确复用你传入的绝对路径，而是将分类名作为文件名、结合当前进程工作目录生成最终写入路径。
• IIS工作进程的默认工作目录就是c:\windows\system32\inetsrv\，你在HttpGet请求中触发逻辑时，组件刚好正确识别了传入的绝对路径，但是POST请求的上下文下，组件内部逻辑误将最终路径解析为相对路径，就会拼到系统默认工作目录下，而IIS应用池默认标识对这个系统目录没有写入权限，就抛出了权限报错。

修复方案 #

你按以下步骤排查修复即可：

步骤1：确认BaseDirectory取值正确性 #

在Post方法的catch块里临时增加路径输出，确认POST请求下AppDomain.CurrentDomain.BaseDirectory是不是你预期的D盘应用路径：

catch (Exception ex)
{
    // 临时加这行看返回结果，确认path是否正确
    return $"path: {path}, error: {ex.Message}";
}

如果输出的path确实是正确的D盘路径，即可确定是Reporting组件的内部路径处理存在问题。

步骤2：修复路径解析问题 #

优先选前两种方案即可：

• 方案一：直接传入完整绝对路径给Reporting组件，避免组件自行拼接。你要生成WooOrders.log的话，就把PrepareChannel的第二个参数改成完整路径：

// 用Path.Combine拼接，避免手动拼接路径的格式错误
string fullLogPath = Path.Combine(path, "WooOrders.log");
Reporting.PrepareChannel("log", fullLogPath);

• 方案二：显式设置当前进程的工作目录为应用根目录，在POST方法逻辑最开头加一行：

Environment.CurrentDirectory = AppDomain.CurrentDomain.BaseDirectory;

• 方案三：给IIS默认应用池的标识授予c:\windows\system32\inetsrv\的写入权限（不推荐，有安全风险，仅用于临时验证问题）

步骤3：目录权限检查 #

如果确认路径正确后还是有权限报错，右键点击你的应用物理根目录，在安全选项中添加IIS AppPool\DefaultAppPool用户的修改、写入权限即可。

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