Хм. Не задумывался над этим… Посмотрел у себя, действительно оно показывает зависимости генератора как анализаторы в netstandard 2.0 библиотеке. Однако для uwp, ios и андроид нет. Возможно технология сыровата и разработчики студии не сделали её корректную поддержку в студии.
Возможно мой подход подходит мне, а не, например, вам. Тот код, который у меня получается в генераторе, отладки не требует, а требует синтаксической проверки на отсутствие ошибок сборки и на корректность генерации (генератор и компилятор отработали успешно но сгенерировалось что-то не то). Как-то не было надобности ставить бряки внутрь сгенерированного кода, поэтому возможно я несколько неправильно понял, что конкретно имелось в виду.
В любом случае наличие выбора лучше чем его отсутствие. Для кого-то это будет полезно, для кого-то бесполезно, но возможно интересно.
Меньше костыльности. Всё происходит внутри одного экземпляра студии. Если в результате генерации получается сложный код, то его можно и, на мой взгляд нужно, вынести в библиотеку поддержки. В этой библиотеке можно ставить брейкпоинты. Остальное становится более или менее тривиальным.
Про сборку. Важна не сборка, а исходный код, который получается и то как он работает. Исходный код всегда можно добыть по брейкпоинту в точке, где он добавляется в текущую компиляцию, в генераторе. Он детерминирован, если генератор и источник для него не менялись. То же самое для прогона тестов на получившейся сборке. Сборка может каждый раз и меняется, но вот результат нет.
Также можно тестировать юнитами, например параметры, ошибки и предупреждения генератора.
Генератор тоже надо отлаживать, конечно же. Разница тут в том в каком контексте будет выполнятся генератор. В контексте компилятора/студии или в контексте юнит теста. Я предпочитаю второй вариант. На мой взгляд так проще отлаживать генератор.
Если я правильно понял проблему, то чтобы пакет не вылез зависимостью к проекту куда анализатор добавляется, нужно устанавливать PrivateAssets="all". Пример:
То, что учёные друг с другом срутся, это нормально. Порой это выглядит излишне эмоционально и может затрагивать небольшие различия, с позиции обывателя, в точке зрения на изучаемый предмет.
Поверхностным поиском не нашёл причины возмущения Дробышевского. Думаю, если было-бы что-то существенное, то он накатал бы статью.
В прошлом году открыл для себя замечательную книгу французского антрополога Паскаля Буайе «Объясняя религию. Природа религиозного мышления». Верования не ограничены авраамическими религиями и само христианство под воздействием окружающей среды и культуры может измениться до неузнаваемости. Поэтому корректные ответы в одном месте/времени могут в другом потерять актуальность.
Чёрных меньше в разы, проявлений нетерпимости к ним, количественно, больше, дешёвая связь и соц сети последний десяток лет. Спасибо. Теперь мне лучше понятен статистический механизм работы «угнетённых меньшинств». Также понятно, что расовый конфликт, при сохранении текущих трендов, в штатах в ближайшее время решить не получится.
Сюда нужны графики: удельное количество преступлений на почве расовой нетерпимости на миллион расы жертвы преступления. После приведённых цифр, я подозреваю, что чёрные чаще видят нетерпимость к себе со стороны белых просто потому, что их меньше в количественном отношении.
Просто мы прошли это в прошлом веке. Обращение «товарищ» не на пустом месте появилось. Тогда же, емнип, форсились женщины в руководстве. Потом пришла война, когда мужики массово ушли на фронт. Потом девяностые. Ну а сейчас наплевать, поскольку пройденный этап в развитии общества. Как это и не странно звучит.
Всё это интересно, но всё сводится к надёжности определения сигналов. Уровни нуля и единицы всегда разделены некоторой «разницой», в которой нельзя определить сигнал. То есть получается: ноль, неопределённость, единица. В троичной системе получается: ноль, неопределённость, единица, неопределённость, два. То есть система становится менее надёжной. Однако, если надёжность достаточно высока, то ничего не мешает в эту схему запихнуть дополнительные уровни сигнала или комбинировать несколько источников сигнала, доводя до привычной степени двойки.
Главное в этой схеме — это информация для таможни и деньги в бюджет. Никто не мешает объединять несколько компетенций в одном юрике, точнее из схемы и статьи это непонятно. Стоит либо дождаться финального решения, либо убедиться, что игроки на схеме, действительно, «прибиты гвоздями» и уже тогда возмущаться.
Хм. Не задумывался над этим… Посмотрел у себя, действительно оно показывает зависимости генератора как анализаторы в netstandard 2.0 библиотеке. Однако для uwp, ios и андроид нет. Возможно технология сыровата и разработчики студии не сделали её корректную поддержку в студии.
Возможно мой подход подходит мне, а не, например, вам. Тот код, который у меня получается в генераторе, отладки не требует, а требует синтаксической проверки на отсутствие ошибок сборки и на корректность генерации (генератор и компилятор отработали успешно но сгенерировалось что-то не то). Как-то не было надобности ставить бряки внутрь сгенерированного кода, поэтому возможно я несколько неправильно понял, что конкретно имелось в виду.
В любом случае наличие выбора лучше чем его отсутствие. Для кого-то это будет полезно, для кого-то бесполезно, но возможно интересно.
Меньше костыльности. Всё происходит внутри одного экземпляра студии. Если в результате генерации получается сложный код, то его можно и, на мой взгляд нужно, вынести в библиотеку поддержки. В этой библиотеке можно ставить брейкпоинты. Остальное становится более или менее тривиальным.
Про сборку. Важна не сборка, а исходный код, который получается и то как он работает. Исходный код всегда можно добыть по брейкпоинту в точке, где он добавляется в текущую компиляцию, в генераторе. Он детерминирован, если генератор и источник для него не менялись. То же самое для прогона тестов на получившейся сборке. Сборка может каждый раз и меняется, но вот результат нет.
Также можно тестировать юнитами, например параметры, ошибки и предупреждения генератора.
Генератор тоже надо отлаживать, конечно же. Разница тут в том в каком контексте будет выполнятся генератор. В контексте компилятора/студии или в контексте юнит теста. Я предпочитаю второй вариант. На мой взгляд так проще отлаживать генератор.
Если я правильно понял проблему, то чтобы пакет не вылез зависимостью к проекту куда анализатор добавляется, нужно устанавливать
PrivateAssets="all". Пример:В вышеприведённом примере LightMock будет добавлен в проект зависимостью, а остальные пакеты нет. То же самое со ссылками на проекты в решении.
Поверхностным поиском не нашёл причины возмущения Дробышевского. Думаю, если было-бы что-то существенное, то он накатал бы статью.
Жду продолжения.