Перевод на NetStandard.

[Gankov]

Прошу синхронизировать планы по переводу библиотек QSProject на NetStandart. Потому как в моем представлении у текущих библиотек не имеет смысл, просто переключать сборку, под NetStandart. А надо создавать отдельные библиотеки .Core, в который мы переносим весь код который мы хотим иметь в будущем как общих в том числе и для новых реализаций.

Это будет способ сделать шаг к зачистке проектов от старого кода. В частности, я планировал полностью выпилить зависимость от https://github.com/QualitySolution/Gtk.DataBindings Поэтому думаю, переводить на нет стаднарт ее не имело смысла. С My-FyiReporting, думаю что добавление NetStandart надо делать в upstream. Наша ветка сборки и так уже разрослась какие ми то отклонениями. Очень бы не хотелось поддерживать полностью свою копию My-FyiReporting. Мы сделали своию ветку для для того чтобы пилить ее отдельно, а просто для того чтобы нам проще было фиксить версии пакетов в зависимостях не более.

[efimov90]

По поводу репортинга: переход на NetStandard2.0 не должен ничего сломать, пулл реквест с переходом: https://github.com/QualitySolution/My-FyiReporting/pull/9

Нужно ли делать пулл-реквест от QSBuild в апстрим? Или нужно сделать пулл-реквест только моих изменений? Если 2е - то как это сделать?

[Gankov]

Я бы апстрим преводил на NetStandart. Ибо такие большие изменения в нашей ветке возможно сильно усложнять перенос любых изменений из апстрима к нам. Я бы не хотел чтобы наша ветка сильно отличалась. От апстрима. Изначально QSBuild создавался только для того чтобы сопоставлять версии зависимостей с зависимостями в наших проектах. Туда не планировалось вносить какие другие изменения. Это то что касается My-FyiReporting.

Из QSProjects вы планируете что-то переводить на NetStandard?

[ArseniiShub]

Планируем переводить на NetStandard всё, до чего сможем дотянуться

[Gankov]

Вот мне как раз это и не очень нравится. Ибо понятно у фреймворка нет будущего. Поэтому надо мигрировать на нет. Но код текущего GUI на dotNet, насколько я понимаю, мигрировать не может. Поэтому он скорей всего будет просто помирать с проектами на нем.

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

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

Поэтому я хотел бы переносить в dotnet только то что реально будет использоваться в новом десктопе. Вот буквально по классу, по интерфейсу решать. Надо ли это видеть грубо говоря в библиотеках 2.0. А все что свазяно со старым десктопом пускай остается в Framework. Я так понимю вы наоборт хотите все впереключить под нет стандарт и не заниматься чисткой и рефакторингом устаревшего.

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

Сильно это мешает вашим планам?

[ArseniiShub]

Чистить библиотеки конечно нужно, но мы, как ты и говоришь, просто хотели перевести всё проекты на стандарт. По идее это не сложно, мы просто осторожно по одной переводим. А если начать каждый класс проверять это всё растянется очень надолго. Чистка вообще никак не связана с этим делом, можно и потом ей заняться По идее и все библиотеки с gtk можно перевести, если там не будет никаких ограничений (или gtk не умеет в стандарт и core?)

[Gankov]

GTK да не умеет в Core насколько я знаю. Поэтому их переводит на Standard вообще смысла нет. А по поводу "растянется", к сожалению из-за несовершенства на текущем этапе в управлении разработкой в библиотеках, потому что оно отсутствует совсем. Уверен, что как раз наоборот. Рефакториг и чистка в том числе. возможна только если это надо для реализации каких-то конкретных задач. Просто так, якобы в свободное время, никто ничего рефакторить не будет. И чистить тем более. Мне сложно представить, чтобы кто нибудь из нас, взял, составил список классов, понял какие под удаление, пошел рефакторить старый код, чтобы что-то удалить устаревший класс. Как пример я свое время, начал помечать, некоторые классы, оставлено только для ВВ. И что хоть кто нибудь их за годы, занялся чисткой? Уверен никто и не займется. Я уже так не делаю. Да я и сам такой, уже год практически на каждый месяц планирую эксперимент про переводу на новый GUI... С другой стороны например понадобился модуль на dotnet, он только в старых библиотеках. В процессе перетаскивания, возможно придется его зарефакторить, чтобы он был менее связным. И имелась возможность вытащить только его, а не кучу устаревшего кода вместе с ним.

Попробую еще раз объяснить смысл идеи. Старый десктоп код на dotnet не передет. Поэтому на dotnet будет писаться только новый код. В каких ото отдельный проектах. Теперь возникает желание шарить часть кода, между старыми проектами которые не когда не переедут на dotnet и новыми. Для этого расширенный под Standard код можно использовать и там и там. Но так как на dotnet, только новый код. Он не должен линковастья с классами которые мы решили не развивать. Поэтому как не крути, те куски кода которые мы захотим расшарить, между старой жизнью и новой, от старой жизни надо будет конкретно так отделить в отдельную dll. Иначе эту зависимость просто не увидеть. В результае, когда у нас будут полноценные проекты на dotnet во всех либах которые компилируются под dotnet, не будет легаси, тянущегося со старых подходов. Когда без этого нельзя будет решить задачу с бизнес значимостью, такой рефакторинг будет делаться. Если можно будет просто срезать углы, никто ничего удалять не будет. У меня такое мнение.

[efimov90]

GTK умеет standard 2.0 использовать

[Gankov]

GTK умеет standard 2.0 использовать

Это понятно. Скорее Standard умеет быть зависимость для Framework.

Можно ли проект на GTK-sharp-2 зашпилить целиком на Core? Помоему нет. GTKSharp который 3, тот да, на dotnet работает.

[Gankov]

Я тут вообще подумывал, еще и подтянуть количество тестов...В библиоетках. добавил в сборки покрытие тестами. Планировал для классов перенесенных на dotnet попробовать сделать покрытие не менее 60-70%. :)

[ArseniiShub]

А работает кстати всё. На NetCore 3.1 запустил Vodovoz, наш основной проект

[Gankov]

Ну то есть можем полностью на net core перескочить?

[Gankov]

Если так, то это другая история.

[ArseniiShub]

Вроде того, пришлось отключить некоторые неподдерживаемые пакеты, типа WCF и System.Drawing, но конкретно сам gtk работает нормально.

[Gankov]

Если вы целиком перезжаете в результате, то ок. Давайте вашим путем идти. А чистку я уж тогда буду вручную через перетаскивание между библиотеками проводить. Наметил, чуть более расширенную схему разделения основной библиотеки на Ядро, десктоп и ГУИ.