2017-01-19 2 views
6

Я работаю над приложением Service Fabric, которое содержит несколько служб без состояния и единую службу состояния. Когда я публикую первый раз, все в порядке, и оно развертывается в моем локальном кластере. После этого, если я пытаюсь упаковать или опубликовать приложение без явного остановить его первым, я получаю следующее сообщение об ошибке:Почему мой код Service Fabric блокирует собственные PDB?

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. Это единственное приложение с поддержкой состояния в моем приложении.

  1. Почему мой exe блокирует собственные PDB? Я мог понять, была ли это Visual Studio.
    • Я ничего не вижу в своем собственном коде, который должен вызвать это, поэтому я предполагаю, что это что-то в коде Fabric, который я звоню.
  2. PDB развернуты с приложением, но это файлы в исходном исходном каталоге, которые заблокированы - почему не PDB рядом с запущенным кодом?
  3. Почему я вижу эту ошибку только для службы состояния, а не для служб без состояния?
    • Я подозреваю, что это имеет какое-то отношение к службе состояния, генерирующей множество ошибок при запуске, для чего Fabric может нуждаться в символах для правильного отображения.
  4. Как я могу остановить это: либо использовать правильные PDB, либо вообще не использовать их, если я не отлаживаю Visual Studio?

Редактировать: поднято на github. Текущий 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).

+0

Это состояние службы asp.net? У вас есть какие-либо проекты библиотеки классов в вашем решении? –

+0

Я избегал любого ядра asp.net или ядра .net. У меня было слишком много проблем, чтобы получить платформу и конфигурацию для них с помощью ткани. Прямые отпечатки из ткани - это только 64-битные сервисы. Один или два из них, включая службу состояния, ссылаются на библиотеку классов в решении, которое встроено в любой процессор. Это может вызвать проблемы? – Andyrooger

+0

Я видел проблему, когда это происходит после изменения конфигурации сборки библиотеки классов. В этом случае он разрешается с помощью вторичной сборки. Вы застряли в сборке или можете просто сделать еще одну сборку, и это хорошо? –

ответ

0

Основываясь на 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, я был бы очень рад, чтобы переместить большую зеленую галочку.

Смежные вопросы