Смотрю что в core процесс компиляции стал более хитрым чем был в .net fw.
собрал консольный проект в bin две результирующие dll в корне и в папке ref
как пишут в ref сборке находится заглушка.
Получается хост сначала грузит ref и только потом вызывается настоящая dll с исполняемым кодом?
напрямую её уже нельзя использовать?
что еще в ref? определение платформы при вызове какую конкретно либу надо подгрузить?
Здравствуйте, vaa, Вы писали:
Всё для чего служат реф-асм это удовлетворение МС-ного воркфлоу с in-place апдейтами для 4.x фреймворками (оттуда оно и выросло), сохраняя обратную совместимость (возможность таргетироваться назад). Более ни для чего оно не нужно, более того, то что они сделали и как оно работает (розлин) — то это не оптимизация, это признание собственной импотенции, под видом стратегической оптмизации
и только это. Ничего хорошего в этой ахинеи нет.
Чисто теоретически, ref-сборка помогает, когда вы потребляете пакеты. Но воистинну, на типичных размерах пакетах — это абсолютно не важно, и скорее вызывает деградацию (т.к. вам нужно читать в 2 раза больше файлов, чем стоит). Вот и всё. [Тут ещё вам расскажут про блокировку файлов, но компилятору не надо держать ссылки — ему нужно делать ровно то, что его просят, а не то, что делает вся эта малоуправляемая махина, порождая неконтроллируемое кол-во процессов которые висят которых вы — непросили.]
При этом, я вынужден добавить, что вместо того, что бы купить нюгет или как они там договорились ещё тогда давно и выкинуть .ps1 и прочее говно — они пошли по пути только придумывания костылей над костылями. Теперь вот всё продолжают и продолжают выдумать новые костыли. Вместе с тем, для решения *практических* задач — оно не годиться. Точнее говоря, они не гарантируют этого. В частности: мета-пакетов — нет. Точнее не так, они есть и работают и в дотнете и у меня. Но, они официально не поддерживаются. Библиотеку установить на системном уровне (на подобии asp.net) — ну это тоже несколько для избранных. Зарезолвить путь к такому пакету в райнтайме — собственно охереете. Я уже не говорю, что нюгет пакеты не умеет восстанавливать, так, как оно должно было быть изначально, и что указание версии 1.2.3 это не совсем то же что и [1.2.3] как видится большинством людей. ADD: (Самый трэш с транзитивными зависимостями, но суть то не в том: есть старое решение на уровне мсбилда и уже пилят новую фичу про центральное управление и она уже дебильна, т.к. идет путем спец поддержки. Как так? Ведь работающий исходник не основывается на несуществующих фичах, да и фича — то по сути не может быть фича: это уже базовый функционал...) Есть еще много проблем в этом русле, типа транзитивный флоу проектов или пакетов, и надо руками писать когда ты этого не хочешь. И если думают, что реф-файлы помогут в скорости... тьфу на них трижды, т.к. проблема в том, что это как раз не важно: будете бороться с проектами внутри солюшна. Конечно мсбилд тьюринг полный и это же его слабость: билд процесс охеренно неронятный. В сравнении с C++ где непонятности обычно больше в купе с сторонними тупыми тулзами-генераторами (cmake) тди сторонними внятными языками-генераторами (gn) — msbuild проще в типичном использовании и в целом интересен, но проблема doible-writes вот специфична для него (не только для него на самом деле), но они так и подталкивают что бы сделать всё вместо них. При этом это непрактично.
В некоторых вопросах, — они просто нагло врут сказки, как они сделали в прошлом году про PGO, которое они действительно прикрутили, но только для своих библиотек, не дав нормального доступа до тулчейна, при этом не забыли жирно похватиться.
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, vaa, Вы писали:
MA> Всё для чего служат реф-асм это удовлетворение МС-ного воркфлоу с in-place апдейтами для 4.x фреймворками (оттуда оно и выросло), сохраняя обратную совместимость (возможность таргетироваться назад). Более ни для чего оно не нужно, более того, то что они сделали и как оно работает (розлин) — то это не оптимизация, это признание собственной импотенции, под видом стратегической оптмизации и только это. Ничего хорошего в этой ахинеи нет.
Хм. У меня возникло впечатление, что реф-асм — это способ описывать зависимости, не заботясь о том, в скольки физических сборках приезжает нужный код под конкретной платформой.
Про оптимизации речи вроде бы не было, так что её отсутствие — не недостаток.
MA> Чисто теоретически, ref-сборка помогает, когда вы потребляете пакеты. Но воистинну, на типичных размерах пакетах — это абсолютно не важно, и скорее вызывает деградацию (т.к. вам нужно читать в 2 раза больше файлов, чем стоит). Вот и всё. [Тут ещё вам расскажут про блокировку файлов, но компилятору не надо держать ссылки — ему нужно делать ровно то, что его просят, а не то, что делает вся эта малоуправляемая махина, порождая неконтроллируемое кол-во процессов которые висят которых вы — непросили.]
MA> При этом, я вынужден добавить, что вместо того, что бы купить нюгет или как они там договорились ещё тогда давно и выкинуть .ps1 и прочее говно — они пошли по пути только придумывания костылей над костылями. Теперь вот всё продолжают и продолжают выдумать новые костыли. Вместе с тем, для решения *практических* задач — оно не годиться. Точнее говоря, они не гарантируют этого. В частности: мета-пакетов — нет. Точнее не так, они есть и работают и в дотнете и у меня. Но, они официально не поддерживаются.
Можно подробнее — что вы имеете в виду? Ну, то есть как оно "должно" работать, и что не так с тем, как оно "на самом деле"?
MA>Библиотеку установить на системном уровне (на подобии asp.net) — ну это тоже несколько для избранных.
Я так понял, что "установка библиотеки на системном уровне" — это в целом хреновая идея. Так что да, несколько для избранных.
MA>Зарезолвить путь к такому пакету в райнтайме — собственно охереете. Я уже не говорю, что нюгет пакеты не умеет восстанавливать, так, как оно должно было быть изначально, и что указание версии 1.2.3 это не совсем то же что и [1.2.3] как видится большинством людей.
Можно подробнее — что вы имеете в виду? Ну, то есть как оно "должно" работать, и что не так с тем, как оно "на самом деле"?
MA>ADD: (Самый трэш с транзитивными зависимостями, но суть то не в том: есть старое решение на уровне мсбилда и уже пилят новую фичу про центральное управление и она уже дебильна, т.к. идет путем спец поддержки. Как так?
Можно подробнее — что вы имеете в виду? Ну, то есть как оно "должно" работать, и что не так с тем, как оно "на самом деле"?
MA>Ведь работающий исходник не основывается на несуществующих фичах, да и фича — то по сути не может быть фича: это уже базовый функционал...) Есть еще много проблем в этом русле, типа транзитивный флоу проектов или пакетов, и надо руками писать когда ты этого не хочешь. И если думают, что реф-файлы помогут в скорости... тьфу на них трижды, т.к. проблема в том, что это как раз не важно: будете бороться с проектами внутри солюшна. Конечно мсбилд тьюринг полный и это же его слабость: билд процесс охеренно неронятный. В сравнении с C++ где непонятности обычно больше в купе с сторонними тупыми тулзами-генераторами (cmake) тди сторонними внятными языками-генераторами (gn) — msbuild проще в типичном использовании и в целом интересен, но проблема doible-writes вот специфична для него (не только для него на самом деле), но они так и подталкивают что бы сделать всё вместо них. При этом это непрактично.
Можно подробнее — что вы имеете в виду? Ну, то есть как оно "должно" работать, и что не так с тем, как оно "на самом деле"?
MA>В некоторых вопросах, — они просто нагло врут сказки, как они сделали в прошлом году про PGO, которое они действительно прикрутили, но только для своих библиотек, не дав нормального доступа до тулчейна, при этом не забыли жирно похватиться.
Вот на это хотелось бы ссылку — я что-то пропустил? Вроде же для дотнета была только tiered compilation, без PGO?
Здравствуйте, Sinclair, Вы писали:
Я извинияюсь, я пропустил ответ.
MA>> Всё для чего служат реф-асм это удовлетворение МС-ного воркфлоу с in-place апдейтами для 4.x фреймворками (оттуда оно и выросло), сохраняя обратную совместимость (возможность таргетироваться назад). Более ни для чего оно не нужно, более того, то что они сделали и как оно работает (розлин) — то это не оптимизация, это признание собственной импотенции, под видом стратегической оптмизации и только это. Ничего хорошего в этой ахинеи нет.
S>Хм. У меня возникло впечатление, что реф-асм — это способ описывать зависимости, не заботясь о том, в скольки физических сборках приезжает нужный код под конкретной платформой.
S>Про оптимизации речи вроде бы не было, так что её отсутствие — не недостаток.
Генерация ref-asm включена по умолчанию. Но она осязаемо никому не нужна. Это служит именно оптимизации. А для того, что бы описывать зависимости, как ты
правильно говоришь — то извини, воркфлоу — кардинально меняется с текущего на непредставимый (без сторонних тулзов). Тебе прийдётся научиться генерировать ref-asm и паковать их руками ручками и заворачивать всё остальное вручную.
MA> При этом, я вынужден добавить, что вместо того, что бы купить нюгет или как они там договорились ещё тогда давно и выкинуть .ps1 и прочее говно — они пошли по пути только придумывания костылей над костылями. Теперь вот всё продолжают и продолжают выдумать новые костыли. Вместе с тем, для решения *практических* задач — оно не годиться. Точнее говоря, они не гарантируют этого. В частности: мета-пакетов — нет. Точнее не так, они есть и работают и в дотнете и у меня. Но, они официально не поддерживаются.
S>Можно подробнее — что вы имеете в виду? Ну, то есть как оно "должно" работать, и что не так с тем, как оно "на самом деле"?
Нюгет, судя по всему нарисовал человек кто вообще не был знаком с пакетным менеджментом. С тех пор нюгет наступил на каждую из грабель, уже пройденные 10 лет ранее, относительно года выпуска. Т.е. скрипты vs декларативность. Транзитивные зависимости и "лок" версий — оно и сейчас толком не умеет это. Вездесущая циферная нумерация, сначала обычная, потом semver, потом semver2, и при этом — оно, извините просто по дефолту считает что 1.0.0 — это >=1.0.0. Мета-пакеты? Мета-пакеты — работают, я уже говорил. Они используются самим фреймворком (только надо приседать вокруг и это не документировано). Почему пакеты пытаются внутрь себя впихнуть всё и сразу, вместо того, что бы, наоборот сделать срезы любого необходимого набора плоскостей (tfm/rid и т.п.)?! Зачем мне 1 пакет с поддержкой 100-500 платформ внутри себя, если у меня один таргет? Это удобно?! Кому? Всех разработчиков спросили? Тикеты висят висяками уже сильно больше 3 лет, и будут висеть и дальше. Это — есть "должно". Если окунуться в прекрасный мир других пакетных систем, то внезапно окажется, что debian с родословной из прошлого тысячелетия — гораздо гибче просто на уровне версионирования. Вы думаете, что версия это 3 цифры?! (Это вопрос в зал) Если вы реально так считаете, то вы нихера не знаете о версионировании продуктов, простите, обижать никого не имею цели. Я заебался повторять фразу: фреймворки должны давать возможности. Они не должны их забирать. У нас — эта херня, максимально интегрирована в процесс билда, отбирая вообще какие-то шансы на кастомизацию, если, вы не готовы рыть носом этот грёбанный SDK. Я это делал много лет, у меня всё меньше и меньше желания продолжать это делать. Я постоянно смотрю, как такие же задачи решаются в других экосистемах — и на этом основании я и говорю — должно. Так, как в дотнете — быть не должно. Оно чудовищно.
Вот ещё одна модная мелочь по поводу фреймворков: кто-то считает xunit — хорошим фреймворком?! Да? А это один из самых отвратительных, ровно по одной причине — он видит мир в чёрно-белом свете, где тест либо успешен (pass), либо падает (fail). Автор хоть и является автором порта JUnit в NUnit, так и не понял разницы между Pass, Fail и Error.
И эти люди, потом учат нас как надо писать код? Тьфу. И уже не связанное — к vstest — у меня личные счеты, но я промолчу. На кой это всё так сложно, кто-нибудь понимает? Да хотя хер с ним. Сейчас это даже не удобно. Сделайте быстро и удобно.
Я уже вообще скромно промолчу, о том, что nuget страдал какими-то детскими болячками с параметрами, не воспринимал он минусики (бараны, чтоли? ну парсите системной функцией виндовс если лень — она умеет же), банально путался в дисках (
C:/D:) и т.п. Это можно понять и простить, но его использование просто чудовищно, по сравнению с тем же npm. И каждый год nuget усиленно пилят. Он каждый год всё лучше и лучше, лучше и лучше. Только он не делает и не работает как надо и как должен.
Впрочем, сильно серьезно это не стоит воспринимать — да, я токсичен. Мне, не приятно, что платформа — очень
MA>>Библиотеку установить на системном уровне (на подобии asp.net) — ну это тоже несколько для избранных.
S>Я так понял, что "установка библиотеки на системном уровне" — это в целом хреновая идея. Так что да, несколько для избранных.
Я имел ввиду shared framework, на вроде Microsoft.AspNetCore.App, Microsoft.NETCore.App и Microsoft.WindowsDesktop.App. Лежит оно в dotnet/shared. И это не хреновая идея, иначе бы такой папочки не существовало бы.
MA>>Зарезолвить путь к такому пакету в райнтайме — собственно охереете. Я уже не говорю, что нюгет пакеты не умеет восстанавливать, так, как оно должно было быть изначально, и что указание версии 1.2.3 это не совсем то же что и [1.2.3] как видится большинством людей.
S>Можно подробнее — что вы имеете в виду? Ну, то есть как оно "должно" работать, и что не так с тем, как оно "на самом деле"?
Я, думаю, что наверное, имел ввиду вот что: если у меня в пакете есть нативные зависимости, которые я хочу загрузить в рантайме из пакета, будучи в обычном пакете, будучи в виде shared framework или будучи рядом с приложением — то прийдётся попрыгать. Я напомню, если, что, что в dotnet core изначально ничего в каталог приложения из зависимостей не копировалось по умолчанию, но механизм "probing" отключили по умочанию в пользу копирования, т.к. это работает типа быстрее (зависит от сценария). Поэтому мои придирки, стоит рассматривать именно с этой стороны. И то это не придирка, это просто не проработанный вопрос. А вопросы — такие в тикете ессно есть, ещё задолго до меня.
MA>>ADD: (Самый трэш с транзитивными зависимостями, но суть то не в том: есть старое решение на уровне мсбилда и уже пилят новую фичу про центральное управление и она уже дебильна, т.к. идет путем спец поддержки. Как так?
S>Можно подробнее — что вы имеете в виду? Ну, то есть как оно "должно" работать, и что не так с тем, как оно "на самом деле"?
Транзитивная зависимость сейчас никак и ничем не контроллируется. Репродуцируемые билды — это пока миф. Лок файлы — они уже есть, оно как-то работает, но оно не работает в полном объеме. В добавок — оно как минимум неудобно, по сравнению с другими.
MA>>(gn) — msbuild проще в типичном использовании и в целом интересен, но проблема doible-writes вот специфична для него (не только для него на самом деле), но они так и подталкивают что бы сделать всё вместо них. При этом это непрактично.
S>Можно подробнее — что вы имеете в виду? Ну, то есть как оно "должно" работать, и что не так с тем, как оно "на самом деле"?
Double Writes — это когда билд система перезаписывает один и тот же файл (потенциально разный). Не так уж и сложно заставить dotnet/msbuild сваливать вывод проекта в одну директорию, там всё для этого есть. Проблема дургая: результат — будет зависеть исключительно от нашего внимания, ну и периодического костыляния. SDK сейчас даёт такую возможность в том виде, что зависимости (например из нюгет пакетов) — не будут копироваться в выходную директорию. Это легко "победить" через включение 3.1-style probing, но прийдёт время, и с double writes прийдётся разобраться, ровно как и с runtime deps -> на этом пути, фактически мы одиноки и должны заворачивать мир руками.
А "на самом деле", проект не должен / не должен мочь один и тот же файл сгенерировать 2 раза.
MA>>В некоторых вопросах, — они просто нагло врут сказки, как они сделали в прошлом году про PGO, которое они действительно прикрутили, но только для своих библиотек, не дав нормального доступа до тулчейна, при этом не забыли жирно похватиться.
S>Вот на это хотелось бы ссылку — я что-то пропустил? Вроде же для дотнета была только tiered compilation, без PGO?
Если не принимать во внимание, что об этом поют с 2017-го года, то да, пропустил.
Ну, во первых:
https://devblogs.microsoft.com/dotnet/announcing-net-6/ — это по большей части про маркетинг, но там про PGO есть (немного).
Суть во том, что:
.NET умеет во все виды PGO: т.е. динамическое вкупе с tiered compilation, но и статическое. Т.е. ты (они) собирают профиль, и его дают на компиляцию, формируют сборку, в которую встроен и профиль и R2R код, который им должен +/- соответствовать. Вот, всё что оно делает в динамике — ну, мне это не особо интересно (это интересно, но я именно имел ввиду — про статику, когда я руками натренирую профиль). Вот, эти статические профиля — они часть фреймворка (в смысле BCL — использует их). Но, захоти сделать это сам — информации можно тупо не найти. Тулзов можно не найти. Возможно на сейчас что-то изменилось, но на момент выхода .NET 6 — они, просто отрабатывают технологию на кошечках.
Сам тикет, я не могу найти. Был вроде бы тикет-roadmap для .NET 7. Его контент почти весь прилетел из .NET 6 (с сделанным так процентов на 10-20%). Я искал, что-то не могу никак найти. Ну, т.к. уже .NET 7 и всё таки время прошло — возможно они его уже и разобрали по запчастям, я в этом смысле в них нисколечко не сомневаюсь.
На самом деле очень радует вот это:
https://github.com/dotnet/runtime/issues/61231 — при чём, оно реально работает, хотя тикет и выглядит "пустым", и оно элементарно подключается. Правда в тестировании тут не всё так просто. Ну, эта древняя тема, но они вроде бы настроились это зарелизить в семерке.
