Реализация на C# интерфейс за отстраняване на грешки, намираща се в пакет nuget

Имам 3 проекта:

  • Проект A е основният проект (уеб приложение .NET Core)
  • Проект 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 в режим Release, но опитвали ли сте да ги създавате в режим dev? Поне бих го тествал, за да видя дали има някаква разлика.   -  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 един до друг, тъй като protocoll не включва конфигурационния режим и 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. Радвам се да чуя, че незабавният ви проблем е решен. Ако правите пишете публикация в блог или нещо друго за това изживяване, можете да помислите за свързване към него или във вашата OP, или като коментар под него. Може да помогне на някой друг по-късно. Ps: ако това е решило проблема ви, моля, обмислете проверката като приет отговор на въпроса ви. ;) - person Kjartan; 07.05.2019
comment
Има повече проблеми със структурирането на средата за кодиране по отношение на nugets, отколкото .NET Core като цяло. :-) Е, започнах с 6 органично отгледани споделени проекта, които се препращат един към друг и днес завърших с 25+ nuget пакетни проекта, всеки от които има 2 .csproj файла (един за сървъра за изграждане, препращащ към nugets, един за разработка, препращащ проектите директно ). Нека да видим как работи това :-) Поне кодирането и отстраняването на грешки изглежда отново се чувстват страхотно. Разбира се, ще приема отговора ви и благодаря за помощта. - person monty; 07.05.2019