为什么 Log4Net 不在我的单独线程中记录日志语句？
我的所有 log4net 附加程序都在我的 Web 应用程序中设置完毕并正常工作，但是当我启动不同的线程来启动数据同步过程时，该单独线程中的所有日志语句都会进入空的深渊；我的附加器都没有被解雇。有人知道为什么会这样吗？
private static readonly ILog Log = LogManager.GetLogger("mylog");
public static string SomeValue
{
get
{
Log.Debug("This WILL be appended to the log");
var thread = new Thread(SyncData);
thread.Start();
return "the value";
}
}
private static void SyncData()
{
Log.Debug("This will NOT be appended to log");
var newLog = LogManager.GetLogger("mylog");
newLog.Debug("This will also NOT be appended to the log");
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该启用 Log4net 内部调试并查看 log4net 是否报告出现问题。
查看“如何启用 log4net 内部调试？” 此链接中的部分。
You should enable Log4net internal debugging and see if log4net is reporting something going wrong.
Check out the "How do I enable log4net internal debugging?" section in this link.
一种可能的解决方案是使用创建者的身份模拟所有手动创建的线程，如本文所示：部署到 IIS 时，线程在 AspNet 中无法工作
我希望这对我来说非常有用！
亚历杭德罗.
A possible solution, could be impersonate all the manualy created threads using the creator's identity as shown in this post: Thread Not Working in AspNet when deployed to IIS
I hope this be very useful like it was to me!
Alejandro.
当您在 ASP.Net 应用程序中生成新线程时，它将在应用程序池的用户名下运行（新线程与正在运行 Web 应用程序的进程（即 AppPool）具有相同的安全上下文）。而当前正在处理您的页面的 webApp 线程可能正在不同的用户帐户下运行；您正在模拟的帐户或您定义为在匿名访问下运行的帐户。 IIS 为您提供的线程与您创建的任何线程之间存在这种安全差异的原因是：
我们有一个应用程序池（在单个帐户下运行），它可能通过所有在不同帐户下运行的单独线程处理多个 Web 请求。当您从线程内部创建线程时，它.'。采取父进程而不是父线程的安全性。
您有两种选择，您需要向设置为运行应用程序池的用户帐户授予额外的权限，以便您对需要登录的任何内容都具有写入权限：
ASP.NET 中的线程权限
或者理论上您可以在每个生成的线程上使用模拟，以便它具有与其起源的线程相同的安全上下文从。
http://www.justskins.com/forums/impersonation- in-a-sub-34034.html
When you Spawn a new a new Thread in an ASP.Net application it will run under the username of the App Pool (New threads have the same security context as the process that is running your web app, ie the AppPool). Whereas the the webApp Thread that is currently processing your page may be is running under a different user account; the one that you are impersonating or the account that you defined to run under anonymous access. The reason for this security difference between the thread IIS gives you and any threads you create is:
We have a single app pool (running under a single account) that is may be processing a number of web requests via separate threads all running under different accounts. When you create a thread from from within a thread it .'. takes the security of the parent process not the parent thread.
You have two choices, you will either need to give additional permissions to the user account that is set to run the app pool, so you have write permissions to anything you need to log to:
Thread permissions in ASP.NET
or in theory you could use impersonation on each spawned thread so it has the same security context of the thread it originated from.
http://www.justskins.com/forums/impersonation-in-a-sub-34034.html