【发布时间】：2017-06-04 09:54:39
【问题描述】：
我正在开发一个 Service Fabric 应用程序，该应用程序包含许多无状态服务和一个有状态服务。当我第一次发布时，一切都很好，它已部署到我的本地集群。在此之后，如果我尝试打包或发布应用程序而不先明确停止它，我会收到以下错误：
CSC : error CS2012: Cannot open 'C:...\ProjectFolder\obj\x64\Debug\ProjectName.pdb' for writing -- '进程无法访问文件'C:...\ProjectFolder\obj \x64\Debug\ProjectName.pdb'，因为它正被另一个进程使用。'
根据process explorer，PDB被我自己的ProjectName.exe锁定。这是我的应用程序中的单一有状态服务。
-
为什么我的 exe 会锁定自己的 PDB？ 如果是 Visual Studio 做的，我可以理解。
- 我在我自己的代码中看不到任何应该导致这种情况的东西，所以我假设这是我正在调用的 Fabric 代码中的某些东西。
- PDB 与应用程序一起部署，但锁定的是原始源目录中的文件 - 为什么不是与运行代码相邻的 PDB？
- 为什么我只看到与有状态服务有关的错误，而没有看到与无状态服务有关的错误？
- 我怀疑这与有状态服务在启动时产生大量错误有关，Fabric 可能需要符号才能正确显示。
- 我如何才能阻止它发生 - 要么使用正确的 PDB，要么根本不使用它们，除非我通过 Visual Studio 进行调试？
编辑：在github 提出。当前workaround为此：
目前的解决方法是限制网络服务访问构建文件夹 (obj\x64\Debug) 中的 pdb。
【问题讨论】：
-
它是有状态服务 asp.net 核心吗？您的解决方案中有任何类库项目吗？
-
我避免使用任何 asp.net 核心或 .net 核心。我在使用 Fabric 获得适合他们的平台和配置时遇到了太多问题。来自结构的直接部门是仅限 64 位的服务。其中的一两个，包括有状态服务，在任何 cpu 中构建的解决方案中引用一个类库。这可能会导致问题吗？
-
我看到一个问题，在更改类库的构建配置后会发生这种情况。在这种情况下，它通过辅助构建来解决。你是卡在构建中还是可以再做一个构建，这很好？
-
我可以通过第二次发布来解决，因为我认为它会停止 Fabric 应用程序的运行。但是两次构建或打包仍然失败。不过，我会在周一回到办公桌前确认这一点。
-
会是堆栈跟踪解析吗？当您抛出异常或以其他方式请求堆栈跟踪时，.NET 是否不会自动查找 PDB 以查看它是否可以将行号插入堆栈帧？
标签： c# visual-studio-2015 azure-service-fabric pdb-files