Отладка реализации интерфейса C#, расположенная в пакете nuget

У меня есть 3 проекта:

  • Проект A — основной проект (веб-приложение .NET Core).
  • Project B — это библиотека классов в пакете NuGet, содержащая интерфейсы.
  • Project C — это библиотека классов в пакете NuGet, реализующая интерфейс

Мне удалось собрать пакеты NuGet с включенными символами pbd и исходным кодом. Пакеты NuGet создаются в режиме Release (может быть проблема в этом?)

Я настроил свою настройку отладки следующим образом

  • Флажок Только мой код не установлен.
  • Я загружаю символы для двух пакетов NuGet

Я могу перейти ко всем «обычным» методам, таким как включенные методы расширения.

Но когда я достигаю интерфейса, я не могу заставить его войти в класс, реализующий интерфейс. Но я могу войти в код из обычных методов из этого пакета NuGet.

Любые подсказки, если это просто невозможно или я пропустил что-то еще в настройках отладки.


debugging c# nuget visual-studio-debugging
person monty    schedule 07.05.2019    source источник
comment
Это может быть сложно, если случится худшее, просто сошлитесь на них вручную, и к тому времени, когда вы на самом деле заработаете, вы сможете исправить ошибку 20 раз. в любом случае удачи   -  person TheGeneral    schedule 07.05.2019
comment
Да, это с 20 раз верно (пытаюсь получить это сейчас в течение нескольких дней). Но если я ссылаюсь на них, мои файлы .csproj изменяются, что не нравится системе сборки. Есть ли способ иметь 2 файла .csproj рядом и синхронизировать друг с другом (один для сервера сборки и один для разработки)?   -  person monty    schedule 07.05.2019
comment
Вы специально упомянули, что собираете пакеты NuGet в режиме выпуска, но пробовали ли вы создавать их в режиме разработки? Я бы по крайней мере проверил это, чтобы увидеть, есть ли разница.   -  person Kjartan    schedule 07.05.2019

Ответы (1)


arrow_upward
2
arrow_downward

Для вас может быть несколько вариантов:

  • Попробуйте создать отладочные версии пакетов NuGet и посмотрите, поможет ли это.
  • В качестве альтернативы удалите ссылки на пакеты NuGet, а также включите и ссылайтесь на проекты для них напрямую, по крайней мере временно; это должно позволить вам отлаживать их непосредственно.

Если ничего не работает, есть третий вариант: ведение журнала.

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

Многие ошибки, как правило, вызваны отсутствующими значениями, отсутствующими ссылками или какой-либо другой неправильной конфигурацией. Как только вы их найдете, их может быть тривиально исправить, но с реализациями, «спрятанными» за такими интерфейсами, найти их может быть сложно.

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

... Просто не забудьте отключить ведение журнала при переходе в рабочий режим, особенно если есть вероятность, что зарегистрированные данные могут содержать какую-либо конфиденциальную информацию.

person Kjartan    schedule 07.05.2019
comment
Как вы предложили, я попытался собрать их в режиме отладки для тестирования (все еще включая исходный код и все остальное, просто изменил конфигурацию с выпуска на отладку. И, о, эй, я могу перейти к реализации интерфейса. - person monty; 07.05.2019
comment
О господи, эта часть .NET Core и nugets s__k как h__l. Это чистая ирония, что рекомендация ASP.NET Core состоит в том, чтобы поместить все за интерфейсами (для модульного тестирования). Затем введите систему, такую ​​​​как nugets, которую вы не можете отлаживать, потому что вы не можете перейти к реализации интерфейса. Кажется, вы не можете использовать сервер nuget для одновременного развертывания Release и Debug, поскольку протокол не включает режим конфигурации, а VS2017 не позволяет вам определить загрузку Release с сервера X и Debug с сервера Y. Используйте nugets, они сказали . Они сказали, что это .NET Core. Повеселимся, сказали они. - person monty; 07.05.2019
comment
Потратив больше недели на то, чтобы выяснить, как я могу снова начать разработку после переноса SharedProjects на nugets, я думаю, что мог бы написать книгу или, по крайней мере, очень длинный пост в блоге о том, как настроить среду разработки .NET Core при использовании nugets. В результате кажется, что он работает не так гладко, как должен быть. - person monty; 07.05.2019
comment
@monty Жаль, что у тебя проблемы с .NET Core. Рад слышать, что ваша непосредственная проблема была решена. Если вы делаете запись в блоге или что-то еще об этом опыте, вы можете рассмотреть возможность ссылки на нее либо в своем ОП, либо в виде комментария под ней. Это может помочь кому-то еще позже. Ps: если это решило вашу проблему, рассмотрите возможность проверки в качестве принятого ответа на ваш вопрос. ;) - person Kjartan; 07.05.2019
comment
Больше проблем со структурированием среды кодирования в отношении nugets, а не .NET Core в целом. :-) Ну, я начал с 6 органически выращенных общих проектов, ссылающихся друг на друга, и сегодня закончил с 25+ проектами пакетов nuget, каждый из которых имеет 2 файла .csproj (один для сервера сборки, ссылающийся на nugets, один для разработки, ссылающийся на проекты напрямую ). Посмотрим, как это работает :-) По крайней мере, программирование и отладка снова в порядке. Конечно, я приму ваш ответ и спасибо за помощь. - person monty; 07.05.2019