Ich arbeite an einer Service Fabric-Anwendung, die eine Reihe von zustandslosen Diensten und einen einzigen Stateful-Service enthält. Wenn ich das erste Mal veröffentliche, ist alles in Ordnung und es wird in meinem lokalen Cluster bereitgestellt. wenn ich nach diesem, versuchen, die App zu verpacken oder zu veröffentlichen, ohne explizit es zunächst zu stoppen, erhalte ich folgende Fehlermeldung:Warum sperrt mein Service Fabric-Code seine eigenen PDBs?
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.'
Nach process explorer wird die PDB gesperrt durch meine eigenen ProjectName.exe. Dies ist der einzelne Statusdienst in meiner Anwendung.
- Warum sollte meine Exe ihre eigenen PDBs sperren? Ich könnte verstehen, wenn es Visual Studio ist.
- Ich sehe nichts in meinem eigenen Code, der das verursachen sollte, also nehme ich an, dass es etwas im Fabric-Code ist, den ich rufe.
- Die PDBs werden mit der Anwendung bereitgestellt, aber es sind die Dateien im ursprünglichen Quellverzeichnis, die gesperrt sind - warum nicht die PDBs neben dem laufenden Code?
- Warum sehe ich nur diesen Fehler in Bezug auf den Stateful-Service und nicht die statuslosen Services?
- Ich vermute, dass dies etwas mit dem Stateful Service zu tun hat, der beim Start viele Fehler generiert, die Fabric möglicherweise Symbole richtig anzeigen müssen.
- Wie kann ich verhindern, dass es passiert - entweder mit den richtigen PDBs oder überhaupt nicht, es sei denn ich bin über Visual Studio Debuggen?
Bearbeiten: ausgelöst am github. Aktuelle workaround hierfür:
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).
Es ist der Stateful Service asp.net Kern? Haben Sie Klassenbibliotheksprojekte in Ihrer Lösung? –
Ich habe jeden asp.net-Kern oder .net-Kern vermieden. Ich hatte zu viele Probleme, die Plattform und Konfiguration für sie mit Stoff zu bekommen. Die direkten Abstufungen von Fabric sind nur 64-Bit-Dienste. Ein oder zwei davon, einschließlich des Stateful-Service, verweisen auf eine Klassenbibliothek in der Lösung, die in einer beliebigen CPU erstellt wurde. Kann das zu Problemen führen? – Andyrooger
Ich habe ein Problem festgestellt, bei dem dies passiert, nachdem die Build-Konfiguration der Klassenbibliothek geändert wurde. In diesem Fall wird es durch einen sekundären Build aufgelöst. Bist du im Build fest oder kannst du einfach einen anderen Build machen und es ist gut? –