Делает этот класс internal в .NET Framework. При этом, скопировав код себе в проект никаких проблем ни с компляцией, ни с тестами не словил.
И такой фигни там навалом.
Зачем ?!!!
ЗЫ. Простите, пароль на govnokod.ru я давно потерял.
Здравствуйте, Doom100500, Вы писали:
D>Делает этот класс internal в .NET Framework. При этом, скопировав код себе в проект никаких проблем ни с компляцией, ни с тестами не словил.
На самом деле, он делает ровно обратное (и это следует из названия макроса) — он делает ArrayBufferWriter (тот самый ABW) публичным.
Т.е. он всегда был Internal, но потом было решено его открыть, однако, зачем-то и старый вариант в коде оставили.
D>И такой фигни там навалом.
А можно ещё пример?
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, Doom100500, Вы писали:
D>>Делает этот класс internal в .NET Framework. При этом, скопировав код себе в проект никаких проблем ни с компляцией, ни с тестами не словил. МР>На самом деле, он делает ровно обратное (и это следует из названия макроса) — он делает ArrayBufferWriter (тот самый ABW) публичным. МР>Т.е. он всегда был Internal, но потом было решено его открыть, однако, зачем-то и старый вариант в коде оставили.
Для меня это выглядит как "Ищю реализзацию IBufferWritter на byte[]. И нахожу, но она доступна только в .NET, но не в .NET Framework. Без веских на это причин"
D>>И такой фигни там навалом. МР>А можно ещё пример?
Не понял почему, но в здесь наоборот. В тестовой апликации на .NET — класс отсутствует, хотя в Framework есть.
Ладно бы, да только работа с SystemTextJsonFormatter и JsonMessageFormatter (обёртка для Newtonsof Json) Работают, и настраиваются по разному. Также смотрят на другие атрибуты для моделей.
Казалось бы если делаешь обёртки над разными парсерами через один интерфаейс, то почему, блин, интерфейсы всё — таки разные?
UPDATE:
Нытьё про отсутсвие SystemTextJsonFormatter снимается. В сампле была другая версия.
D>Для меня это выглядит как "Ищю реализзацию IBufferWritter на byte[]. И нахожу, но она доступна только в .NET, но не в .NET Framework. Без веских на это причин"
Про то, что класс помечен как public в других версиях .NET (Core) ты в стартовом сообщении не написал.
<!-- ArrayBufferWriter is publicly exposed from the System.Memory ref and only it should define this constant as true. -->
<DefineConstants>$(DefineConstants);MAKE_ABW_PUBLIC</DefineConstants>
Т.е. видимо он включен в несколько библиотек, но только в некоторых должнен быть в публичном интерфейсе.
Здравствуйте, Doom100500, Вы писали:
D>Если клиент использует SystemTextJsonFormatter, то параметры не сериализуются. А с JsonMessageFormatter — нет проблем.
А какое поведение вы ожидаете?
XXXFormater Это же просто обертка над разными сериализаторами.
Эти 2 сериализатора сделаны разными людьми, используют разную разметку атрибутами и работают местами по-разному. Есть даже довольно большая статья в MSDN по миграции с одного на другой Migrate from Newtonsoft.Json to System.Text.Json — там явно не всё, но даже этого — выше крыши.
Ну а то, что ребята не стали завязываться на какой-то один сериализатор, а сделали возможность использовать тот, который вам удобнее — это же наоборот отлично!
Вы просто выберите какой-то один, который вам подходит больше и остановитесь на нем.
Ну или если очень нужна поддержка сразу 2-х... ну снабдите модели двойным набором атрибутов.
D>Ничего, кроме негатива, не испытал исследуя эту либу (официальную от Майков!!!)
Ну если весь негатив сводится к различию в поведении JSON-сериализаторов, которые являются внешними по отношению к этой библиотеке, то для меня библиотека выглядит вполне приличной.
Ну и да, по поводу её официальности... Вообще-то (на сколько я знаю) это библиотека, которую разрабатывала команда VS, когда они начали выносить в отдельные процессы части встроенных расширений VS. А потом уже открыли исходники и сделали небольшую документацию.
Я, откровенно говоря, не помню, чтобы где-то в документации или статьях на неё особо ссылались. Даже та же gRPC встречается куда чаще.
Здравствуйте, Михаил Романов, Вы писали:
D>>Если клиент использует SystemTextJsonFormatter, то параметры не сериализуются. А с JsonMessageFormatter — нет проблем. МР>А какое поведение вы ожидаете?
Хотелось бы, чтобы заявленное поведение всё-таки присутсввовало независимо от используемого паерсера. В данном случае — это ядро библиотеки, которая не разобралась со своими — же обёртками над своим — же парсером.
МР>XXXFormater Это же просто обертка над разными сериализаторами. МР>Эти 2 сериализатора сделаны разными людьми, используют разную разметку атрибутами и работают местами по-разному. Есть даже довольно большая статья в MSDN по миграции с одного на другой Migrate from Newtonsoft.Json to System.Text.Json — там явно не всё, но даже этого — выше крыши.
Да, я всё это читал, но через интерфейсы этих обёрток всё равно не пробиться к парсеру напрямую, кроме как самому всё разгребать — т.е. переписать ядро библиотеки — т.е. нафейфуа она тогда мне вообще? Ни перегрузок, чтобы переопределять поведение, ни свойств. Просто бери — копируй код и меняй потроха. Не таким я себе представлял Open Source.
МР>Ну а то, что ребята не стали завязываться на какой-то один сериализатор, а сделали возможность использовать тот, который вам удобнее — это же наоборот отлично!
Только сторонний работает по своей-же документации, а свой — нет. Просто молодцы, чё!
МР>Вы просто выберите какой-то один, который вам подходит больше и остановитесь на нем.
Поведение разное, несмотря на то, сама спецификация JsonRpc — на полторы страницы в хроме. Какая разница какой парсер? Есть метод, есть параметры, есть результат — работай (атрибуты — это, действительно, fine tunning, опустим их)
Хотелось взять майковский парсер, пока не задолбался выяснять почему с клиента не приходят пораметры, хотя по документации должны. Пришлось попробовать другой, а у него интерфейс другой, и работает он по-другому. А spec протокола — простой как три копейки — это вообще от парсера не должно зависеть 😫
D>>Ничего, кроме негатива, не испытал исследуя эту либу (официальную от Майков!!!) МР>Ну если весь негатив сводится к различию в поведении JSON-сериализаторов, которые являются внешними по отношению к этой библиотеке, то для меня библиотека выглядит вполне приличной.
Плюс кастомизация, переопределение поведения (см. выше).
Да и поведение не надо быбло бы менять, если бы с парсерами проблем не было бы таких диких.
МР>Я, откровенно говоря, не помню, чтобы где-то в документации или статьях на неё особо ссылались. Даже та же gRPC встречается куда чаще.
Нужен протокол JsonРpc, не Grpc. И эта либа единственная от microsoft (мы не хотим стороннего из — за бюрократии, но это другая проблема).
