针对你遇到的问题——在新的Windows Server 2007服务器部署ASP.NET 4.5.2应用后出现临时ASP.NET文件夹的编译权限错误，且已尝试aspnet_regiis.exe -I、授予IISUSRS和NETWORK SERVICE完全控制权限仍未解决——我整理了几个更深入的排查和解决步骤：

• 确认临时ASP.NET文件夹的完整路径及权限继承
  默认的临时文件夹路径是C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files（注意4.5.2是基于4.0运行时的增量更新，工具和临时目录仍在v4.0路径下），但你的应用可能因为配置（比如<compilation tempDirectory="..." />）使用了自定义路径。请先确认实际路径，然后在权限设置中勾选“替换子容器和对象的权限项”，确保权限递归应用到所有子文件夹和文件——只给根文件夹加权限可能没用，因为编译生成的文件都在子目录里。

• 检查应用程序池的运行身份
  很多时候问题出在应用程序池的身份上：如果你的应用池用的是自定义账户（而非默认的NETWORK SERVICE或ApplicationPoolIdentity），那你需要把这个自定义账户也添加到临时文件夹的权限列表中，授予完全控制权限。可以在IIS管理器的应用程序池高级设置里查看“标识”项确认身份。

• 重新验证ASP.NET注册的准确性
  确保你运行的aspnet_regiis.exe是.NET 4.5.2对应的版本，路径应该是C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe。运行时建议以管理员身份打开命令提示符，执行aspnet_regiis.exe -ir（修复注册）代替-I，修复模式往往能解决注册不彻底的潜在问题。

• 手动清理临时ASP.NET文件并重启IIS
  先停止对应的应用程序池，然后删除临时文件夹下对应应用的所有文件（如果找不到对应目录，可以全删，重启后会重新生成），之后执行iisreset命令重启IIS服务。残留的旧编译文件可能导致权限冲突或文件锁定。

• 检查IIS应用程序的.NET版本设置
  在IIS管理器中，找到你的网站应用程序，右键选择“编辑应用程序设置”，确认“.NET Framework版本”设置为v4.0.30319（对应4.5.2），如果误设为v2.0会导致编译时使用错误的临时文件夹和权限配置。

• 查看Windows事件日志定位具体权限问题
  打开事件查看器，查看“Windows日志 -> 系统”和“应用程序”日志，找到编译错误对应的事件记录，里面会明确显示哪个账户在访问哪个文件时被拒绝，这能帮你精准定位需要授权的账户，而不是盲目添加权限。

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