如何缩短 Spring.NET DLL 加载时间
我正在使用 Spring.NET 并遇到了 Ioc 容器加载时间过长的问题。应用程序上下文配置只有几个（例如 10 个对象），但有时需要长达 20 秒的时间来加载容器。我可以在调试器中看到这次似乎归因于加载大量具有奇怪名称的（DDL？）。最终结果是 Windows 服务需要很长时间才能启动，并且 IT 操作员认为它已挂起。
我可以做什么来避免这种情况。我尝试过“只是我的代码”。有什么想法吗？
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded '0xclmvcv'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'rpuvyhdh'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'sq10jbae'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'tmpk4bvl'
I'm using Spring.NET and running into problematically long Ioc Container load times. The app context config only has a few (like 10 objects), yet it takes sometimes up to 20 seconds to load the container. I can see in the debugger this time appears to be attributed to loading lots of (DDLs?) with odd names. The end result is the Windows Service takes to long to start and the IT operators think it's hung.
What can I do to avoid this. I've tried "Just My Code". Any ideas?
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded '0xclmvcv'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'rpuvyhdh'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'sq10jbae'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'tmpk4bvl'
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我被要求分享上面的评论作为其他人发现有用的答案。
缓慢是在 .NET c# Reflect.Emit 中显式使用的。我们使用它来生成实现 ServiceContract 单向操作的代理，以便它们通过 NMS+ActiveMQ 而不是 WCF 支持的传输流。请求/响应的区别仅在于具有返回类型而不是 void，对于这些，每种方法都有 200-400 毫秒的成本。因此，我将单向方式拆分为单独的接口，这样它们就不会被代理。也就是说，如果 Spring AOP 遇到相同的性能问题，我不会感到惊讶..但也许仅适用于 DataContract arge/return 类型
I was asked to share the comment above as an Answer for others to find useful.
The slowness was in .NET c# Reflect.Emit used explicitly. We use it to generate proxies that implement our ServiceContract one-way operations so they flow over NMS+ActiveMQ instead of the transports supported by WCF. The request/response only differs by having a return type instead of void, and for those, there was a 200-400ms cost for each method. So I split out the one-ways to separate interfaces so they don't get proxied. That said, I would not be surprised if spring AOP suffers from the same performance issues .. but perhaps only for DataContract arge/return types