我已经为此苦苦挣扎了一段时间，而且我发现我并不是唯一遇到这个问题的人（请参阅这个 和 那个）。
我已经设法进行了一些调试，并找到了解决方案，尽管我很确定这不是“正确”的方式。
第一个调试会话（在启用开发服务器之前）显示 ProfiledDbConnectionFactory 和 ProfiledDbConnection 类提供了所需的数据，但在创建连接后，静态 ProfiledDbProviderFactory 上的 >Instance 属性已初始化（通过调用默认构造函数），并且显然 CreateConnection() 在该实例上运行导致空引用异常（尾部为空）。
我已经通过
ProfiledDbProviderFactory.Instance.InitProfiledDbProviderFactory(_profiler, ripInnerProvider(_conn));
在 ProfiledDbConnection(DbConnection 连接，IDbProfiler profiler) 末尾运行来解决这个问题。
这允许我查看 sql 分析，但正如我所写，我有一种感觉，这不是正确的解决方案。
这是示例 。
不确定我的环境或我的代码是否有问题，因为我感觉这应该可以开箱即用。有什么意见/建议吗？
萨姆？
I've been struggling with this for a while now, and I see that I'm not the only one with the problem (see this and that).
I've managed to debug for a bit, and found a solution, though I'm pretty sure that this is not the 'right' way.
The first debug session (before the dev server was enabled) showed that the ProfiledDbConnectionFactory and ProfiledDbConnection classes provide the required data, but then AFTER the connection is created, the static Instance property on ProfiledDbProviderFactory is initialized (by calling the default constructor) and apparently CreateConnection() is run on that instance resulting with a null reference exception (tail is null).
I've managed to solve this by running
ProfiledDbProviderFactory.Instance.InitProfiledDbProviderFactory(_profiler, ripInnerProvider(_conn));
at the end of ProfiledDbConnection(DbConnection connection, IDbProfiler profiler).
This allows me to view the sql profiling, but as I wrote, I have a feeling that this isn't the correct fix.
Here's the sample code I used.
Not sure if there is something wrong with my environment, or my code, as I have a feeling that this should work out of the box. Any comments/suggestions?
Sam?
发布评论
评论（2）
使用 ProfiledDbConnectionFactory 实体框架没有任何问题，旨在支持无知，我通常只是使用调试器工具并创建一个断点来查看生成的 sql 语句，因为代码优先框架随时提供 sql 语句，
我会坚持使用分析连接您在单元测试中描述的方式而不是在生产代码中使用它，因为分析可能会影响性能，您还想考虑使用 sql server 中包含的 sql 探查器，并且还有一个 sql 探查器可作为 Visual Studio 扩展使用，但我不确定它是否支持代码优先
there is nothing wrong with using ProfiledDbConnectionFactory entity framework is designed to support ignorance i generally just use the debugger tools and create a breakpoint to view my generated sql statements as the code first framework provides the sql statement readily there
i would stick to using profiled connections the way you described in your unit testing as opposed to using it in production code as the profiling may be a performance hit you way also want to consider using the sql profiler included in sql server and there is also an sql profiler available as a visual studio extension however i am not sure if it supports code first as of yet
此问题已在 MiniProfiler.EF 版本 1.9.1 中得到解决
This problem has been resolved in version 1.9.1 of MiniProfiler.EF