为什么我的 Service Fabric 代码会锁定它自己的 PDB？
Why does my Service Fabric code lock its own PDBs?
我正在开发一个包含多个无状态服务和一个有状态服务的 Service Fabric 应用程序。当我第一次发布时，一切正常，并且已部署到我的本地集群。在此之后，如果我尝试打包或发布应用程序而不先明确停止它，我会收到以下错误：
CSC : error CS2012: Cannot open 'C:...\ProjectFolder\obj\x64\Debug\ProjectName.pdb' for writing -- 'The process cannot access the file 'C:...\ProjectFolder\obj\x64\Debug\ProjectName.pdb' because it is being used by another process.'
根据process explorer，PDB被我自己锁定ProjectName.exe。这是我的应用程序中的单一有状态服务。
- 为什么我的 exe 会锁定自己的 PDB？ 如果是 Visual Studio 我能理解。
- 我在我自己的代码中没有看到任何应该导致此问题的东西，所以我假设它是我正在调用的 Fabric 代码中的东西。
- PDB 随应用程序一起部署，但锁定的是原始源目录中的文件 - 为什么不锁定与 运行 代码相邻的 PDB？
- 为什么我只看到与有状态服务相关的错误，而不是与无状态服务相关的错误？
- 我怀疑这与有状态服务在启动时产生大量错误有关，Fabric 可能需要符号才能正确显示。
- 我怎样才能阻止它发生 - 使用正确的 PDB 或根本不使用它们，除非我通过 Visual Studio 进行调试？
编辑：在 github. Current workaround 上提出：
A current workaround at this point in time would be to restrict the Network Service access to the pdb in the build folder (obj\x64\Debug).
根据提出的issue，现在看来这个问题已经解决了。
"Going to close the issue as we believe both issues have now been addressed by the 5.6 runtime and the 1.6 tooling."
看来升级现在是第 4 点的答案。如果有人能回答 1-3，我会很乐意移动大绿色对勾。
我正在开发一个包含多个无状态服务和一个有状态服务的 Service Fabric 应用程序。当我第一次发布时，一切正常，并且已部署到我的本地集群。在此之后，如果我尝试打包或发布应用程序而不先明确停止它，我会收到以下错误：
CSC : error CS2012: Cannot open 'C:...\ProjectFolder\obj\x64\Debug\ProjectName.pdb' for writing -- 'The process cannot access the file 'C:...\ProjectFolder\obj\x64\Debug\ProjectName.pdb' because it is being used by another process.'
根据process explorer，PDB被我自己锁定ProjectName.exe。这是我的应用程序中的单一有状态服务。
- 为什么我的 exe 会锁定自己的 PDB？ 如果是 Visual Studio 我能理解。
- 我在我自己的代码中没有看到任何应该导致此问题的东西，所以我假设它是我正在调用的 Fabric 代码中的东西。
- PDB 随应用程序一起部署，但锁定的是原始源目录中的文件 - 为什么不锁定与 运行 代码相邻的 PDB？
- 为什么我只看到与有状态服务相关的错误，而不是与无状态服务相关的错误？
- 我怀疑这与有状态服务在启动时产生大量错误有关，Fabric 可能需要符号才能正确显示。
- 我怎样才能阻止它发生 - 使用正确的 PDB 或根本不使用它们，除非我通过 Visual Studio 进行调试？
编辑：在 github. Current workaround 上提出：
A current workaround at this point in time would be to restrict the Network Service access to the pdb in the build folder (obj\x64\Debug).
根据提出的issue，现在看来这个问题已经解决了。
"Going to close the issue as we believe both issues have now been addressed by the 5.6 runtime and the 1.6 tooling."
看来升级现在是第 4 点的答案。如果有人能回答 1-3，我会很乐意移动大绿色对勾。