День добрый.

Простите, а где DataSet контрол в net5? и как работать с SQL серверами?

привычных способов из net framework нет в net5 ?

H>Простите, а где DataSet контрол в net5? и как работать с SQL серверами?
MSDN утверждает что DataSet на месте, и SO поддерживает

Здравствуйте, hi_octane, Вы писали:

H>>Простите, а где DataSet контрол в net5? и как работать с SQL серверами?
_>MSDN утверждает что DataSet на месте, и SO поддерживает

меня интересует этот контрол. в net5 я его не нахожу

H>меня интересует этот контрол. в net5 я его не нахожу
H>Image: dataset.1605351387.png
Для Core 3.1 и 5, дизайн тайм WPF и WinForms новый, причем WinForms вообще практически с нуля делается.
Много чего сделано, но про датасеты все еще значится как enhancement с примерным сроком для VS 16.9 превью 2. Поэтому его нет в тулбоксе.
Пруф дать не могу, закрытый репозиторий у MS
Из кода можете сейчас пользоваться, все работает. Как вариант — можно попробовать в дизайнере сделать проект для 4.x, там все настроить, а потом уже готовые файлы вставить в проект для 5

H>Простите, а где DataSet контрол в net5? и как работать с SQL серверами?
H>привычных способов из net framework нет в net5 ?

офигеть
его кто-то использует?

Здравствуйте, notacat, Вы писали:

H>>меня интересует этот контрол. в net5 я его не нахожу
H>>Image: dataset.1605351387.png
N>Для Core 3.1 и 5, дизайн тайм WPF и WinForms новый, причем WinForms вообще практически с нуля делается.

А им разве WF не бросила? Зачем wpf и wf?wf будет работать под линуксом?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, notacat, Вы писали:

H>>>меня интересует этот контрол. в net5 я его не нахожу
H>>>Image: dataset.1605351387.png
N>>Для Core 3.1 и 5, дизайн тайм WPF и WinForms новый, причем WinForms вообще практически с нуля делается.

S>А им разве WF не бросила? Зачем wpf и wf?wf будет работать под линуксом?
Он только под Win, для переноса существующих с FW на Core ибо FW больше поддерживаться не будет.
Плюс развивают WinUI Project Reunion
Syncfusion Previews WinUI Controls

Здравствуйте, Sharov, Вы писали:

N>>Для Core 3.1 и 5, дизайн тайм WPF и WinForms новый, причем WinForms вообще практически с нуля делается.
S>А им разве WF не бросила? Зачем wpf и wf?wf будет работать под линуксом?
Я так понял переделываются именно дизайнеры + тулчейн, а не сами фреймворки (хотя их тоже лопатили, но только для переноса).
Почему с 0, это интересный вопрос. Возможно, хотят избавляться от поддержки каких-то инструментов, которые являются ключевыми. Ну, например (в качестве бреда), в WinForms всё завязано на CodeDOM, который, по сути, является сериализатором для дизайнера форм. А CodeDOM не развивается, даже не с C# 4, а где-то сильно раньше. И если избавляться от него, то это сравнимо с "написать с 0".
Но, это всего лишь возможный пример.

МР>Я так понял переделываются именно дизайнеры + тулчейн, а не сами фреймворки (хотя их тоже лопатили, но только для переноса).
МР>Почему с 0, это интересный вопрос.
потому что рантайм на Core, а студия на .Net Framework. Старый дизайнер мог в процессе студии рисовать контролы и с ними напрямую работать, а сейчас получается два разных процесса, которые надо как-то дружить друг с другом.

H>>Простите, а где DataSet контрол в net5?
JSM>его кто-то использует?
Те, у кого структура данных определяется в рантайме.

Здравствуйте, Osaka, Вы писали:

H>>>Простите, а где DataSet контрол в net5?
JSM>>его кто-то использует?
O>Те, у кого структура данных определяется в рантайме.

Для этого есть масса решений. Хотя бы ExpandoObject, на вскидку.

O>>Те, у кого структура данных определяется в рантайме.
САД>Для этого есть масса решений. Хотя бы ExpandoObject, на вскидку.
И почему мне стоит потратить рабочее время на их изучение, если я уже знаю как задача решается датасетом?

Здравствуйте, Osaka, Вы писали:

O>>>Те, у кого структура данных определяется в рантайме.
САД>>Для этого есть масса решений. Хотя бы ExpandoObject, на вскидку.
O>И почему мне стоит потратить рабочее время на их изучение, если я уже знаю как задача решается датасетом?

Потому что девелопер всегда стремится к изучению нового, а не застрял в глубоком 2002м году.
А потом жалуются, что на работу не берут, или денег мало платят....

Здравствуйте, СвободуАнжелеДевис, Вы писали:

САД>Здравствуйте, Osaka, Вы писали:

САД>Потому что девелопер всегда стремится к изучению нового, а не застрял в глубоком 2002м году.
САД>А потом жалуются, что на работу не берут, или денег мало платят....

Да Вы правы. Я действительно застрял в 2004-2005 году по С#. Потому что ушел в SAP
И с того времени я ABAP Разработчик. Причем 100% времени. Другие системы или другие языки на работе не применяются. Все в ABAP.
И я потерял развитие C#. Хотя на нем написал достаточно проектов в период с
с появления до 2004 года.
Сейчас вот от ностальгии пытаюсь в свободное время вспомнить C#
C# не является сейчас тем с чем я работаю. Но вышла net5 пытаюсь ковырять и вспомнить что к чему,

Пока я не понял как обойтись без DataSet. Как мне связывать datagrid с структурой данных.
Я привык юзать dataset.
Буду благодарен если вы покажите какой либо ссылкой на ютуб или статью как сейчас это делать правильно.

Спасибо.

Здравствуйте, Hermitap, Вы писали:

H>Да Вы правы. Я действительно застрял в 2004-2005 году по С#. Потому что ушел в SAP
H>И с того времени я ABAP Разработчик. Причем 100% времени. Другие системы или другие языки на работе не применяются. Все в ABAP.

Сочувствую.) Кстати, из sap nco DataSet вырезали еще лет 10 назад.

H>И я потерял развитие C#. Хотя на нем написал достаточно проектов в период с
H>с появления до 2004 года.

Это времена первой версии? Много времени прошло. Можно сказать, что сейчас это совсем другой язык и другой фреймворк.

H>Сейчас вот от ностальгии пытаюсь в свободное время вспомнить C#
H>C# не является сейчас тем с чем я работаю. Но вышла net5 пытаюсь ковырять и вспомнить что к чему,

H>Пока я не понял как обойтись без DataSet. Как мне связывать datagrid с структурой данных.
H>Я привык юзать dataset.
H>Буду благодарен если вы покажите какой либо ссылкой на ютуб или статью как сейчас это делать правильно.

К сожалению, не встречал документации, которую можно однозначно посоветовать. В общем случае для замены DataSet предлагают использовать классы с интерфейсом INotifyPropertyChanged и коллекции с INotifyCollectionChanged. Как потом эти коллекции заполнять и следить за изменениями, тоже однозначных рекомендаций нет, можно руками, можно с помощью ORM.

Здравствуйте, notacat, Вы писали:

N>потому что рантайм на Core, а студия на .Net Framework. Старый дизайнер мог в процессе студии рисовать контролы и с ними напрямую работать, а сейчас получается два разных процесса, которые надо как-то дружить друг с другом.
Логично.
Реальность как всегда прозаичнее...

С другой стороны, после выхода "WPF в Core" теоретически становится возможной миграция и самой студии на .Net Core (опять же я не пытаюсь даже примерно оценить объемы работы — чисто "как минимум WPF уже тут")
Но в любом случае — это не вопрос завтрашнего дня, а работать нужно уже сейчас.

Здравствуйте, Михаил Романов, Вы писали:

МР>Но в любом случае — это не вопрос завтрашнего дня, а работать нужно уже сейчас.

ну с DataSet вопрос решился. Возможно он по другому работать стал.
Мы создаем DataSet1.xsd а он уже появляется на тулбоксе и его можно на форму добавить.


Upd.. хотя нет. Не решился. Падает. При попытке положить на форму. Пустой тянется. С таблицей падает.
При этом в framework 4.8 все работает. Microsoft такой Microsoft.

Здравствуйте, Hermitap, Вы писали:

H>Upd.. хотя нет. Не решился. Падает. При попытке положить на форму. Пустой тянется. С таблицей падает.
H>При этом в framework 4.8 все работает. Microsoft такой Microsoft.
H>Image: ds.1605521251.jpg
Ну я так понимаю, Наталья об этом и говорила — что пока на уровне дизайнера поддержки нет, всё только в коде.

Здравствуйте, Hermitap, Вы писали:

H>Пока я не понял как обойтись без DataSet. Как мне связывать datagrid с структурой данных.
H>Я привык юзать dataset.

Сейчас для этого используют обычные объекты и биндинг в WPF. А для доступа к данным разные надстройки над LINQ. Мы вот заюзали LINQ2DB написанный одним из основателей этого сайта IT. Еще есть убогенький Entity Framework.

Здравствуйте, Hermitap, Вы писали:

H>Простите, а где DataSet контрол в net5? и как работать с SQL серверами?

H>привычных способов из net framework нет в net5 ?

Студия (VS2019 16.9.0 Preview 1.0) пока сидит на FW 4.8.03752.

То есть, насколько я понимаю, она сама пока толком работать с NET5 не может...

Хороший вопрос, собственно говоря.

Походу с DDEX провайдером пока можно не напрягаться

Здравствуйте, VladD2, Вы писали:

VD>Сейчас для этого используют обычные объекты и биндинг в WPF. А для доступа к данным разные надстройки над LINQ. Мы вот заюзали LINQ2DB написанный одним из основателей этого сайта IT. Еще есть убогенький Entity Framework.

2 Коваленко Дмитрий: Что смешного в моих словах?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, VladD2, Вы писали:

VD>>Сейчас для этого используют обычные объекты и биндинг в WPF. А для доступа к данным разные надстройки над LINQ. Мы вот заюзали LINQ2DB написанный одним из основателей этого сайта IT. Еще есть убогенький Entity Framework.

VD>2 Коваленко Дмитрий: Что смешного в моих словах?

Да так, навеяло. Ничего личного.

Я вот что хотел бы спросить здесь.

У MS вроде была Linq для SQL. У меня даже толстая книжка есть про этот Linq.

Но потом они её закопали? Предложив EF6?

А теперь снова откопали в своем EFCore?

Так?

Я вообще ничего не писал под эти вещи не писал.

Хотя под EFCore (повторно) пытаюсь написать провайдер.

	Мда
	Сначало вроде неплохо пошло. Но потом уколебался спотыкаться об их код. И их похоже задрал

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>У MS вроде была Linq для SQL. У меня даже толстая книжка есть про этот Linq.
КД>Но потом они её закопали? Предложив EF6?

У MS была реализация для MS SQL Server, но MS на нее забил. Сейчас MS предлагает только EF. Они его конечно развивают, но и по скорости и по удобству LINQ2DB лучше.

КД>А теперь снова откопали в своем EFCore?

EF — это универсальной фрэймворк не привязанный к Сиквелу. Плюс там море наворотов. Связи с провадером для Сивела у него нет. EF Core — это развитие EF из фрэймворка.

КД>Хотя под EFCore (повторно) пытаюсь написать провайдер.

А зачем провайдер то? Провайдер нужен если есть свой источник данных.

Здравствуйте, VladD2, Вы писали:


VD>У MS была реализация для MS SQL Server, но MS на нее забил. Сейчас MS предлагает только EF. Они его конечно развивают, но и по скорости и по удобству LINQ2DB лучше.


Интересно нашел SQL Server Protocols.

[MS-LETSF]: LINQ Expression Tree Serialization Format
5 Appendix A: Full XML Schema

При том, что LINQ Expression Tree не сериализуются напряму.

Здравствуйте, VladD2, Вы писали:

VD>EF — это универсальной фрэймворк не привязанный к Сиквелу. Плюс там море наворотов. Связи с провадером для Сивела у него нет. EF Core — это развитие EF из фрэймворка.

Сиквелу — это SQL? А не MSSQL?

КД>>Хотя под EFCore (повторно) пытаюсь написать провайдер.

VD>А зачем провайдер то? Провайдер нужен если есть свой источник данных.

У меня есть свой ADO.NET провайдер. Я хочу натянуть на него EFCore. Пока еще хочу...

---
LINQ2DB я как-то натягивал. Почти натянул. Но в конце все пошло не так.

---
... идеи там наверное хорошие. А вот реализация

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Сиквелу — это SQL? А не MSSQL?

Нет. Я именно про MSSQL говорил. EF его поддерживает тоже, но и другие серверы тоже. А то был специализированный провайдер.

КД>У меня есть свой ADO.NET провайдер. Я хочу натянуть на него EFCore. Пока еще хочу...

А. Ясно. Ну, это похвальное начинание.

КД>LINQ2DB я как-то натягивал. Почти натянул. Но в конце все пошло не так.

Ну, так обратился бы к автору. Он очень отзывчев. Да и другие могли бы помочь.

КД>... идеи там наверное хорошие. А вот реализация

Да, ладно! Не наговаривай. Если бы там все было плохо, столько народа его не использовало бы.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Сиквелу — это SQL? А не MSSQL?

VD>Нет. Я именно про MSSQL говорил. EF его поддерживает тоже, но и другие серверы тоже. А то был специализированный провайдер.

И это правильно, наверное. А то получаются вещи, гвоздями приколоченные к полу.

КД>>LINQ2DB я как-то натягивал. Почти натянул. Но в конце все пошло не так.

VD>Ну, так обратился бы к автору. Он очень отзывчев. Да и другие могли бы помочь.

Я общался с ними

КД>>... идеи там наверное хорошие. А вот реализация

VD>Да, ладно! Не наговаривай. Если бы там все было плохо, столько народа его не использовало бы.

Я говорил про эти вещи (EFCore, Linq2Db) в целом.

И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.

Здравствуйте, Коваленко Дмитрий, Вы писали:

Не оверквоть, плиз.

КД>И это правильно, наверное. А то получаются вещи, гвоздями приколоченные к полу.

Что же правильного в не универсальных решениях? Так путем смены конфига ты можешь поменять используемый сервер. Скажем в базовом варианте ты используешь бесплатный Sqlight, а в расширеном MS SQL Server или Oracle. Конечно, какие-то ресурсы при этом придется потратить на обеспечение совместимости, но код будет единым. Не придется писать отдельные решения для поддержки всех видов сервером.

КД>И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.

Ну, так то, что для EF и LINQ2DB написано море провайдеров говорит о том, что авторы уделили серьезное внимание созданию инфраструктуры провайдеров.

Здравствуйте, VladD2, Вы писали:

КД>>И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.

VD>Ну, так то, что для EF и LINQ2DB написано море провайдеров говорит о том, что авторы уделили серьезное внимание созданию инфраструктуры провайдеров.

Да, Copy&Paste — сильная вещь.

Здравствуйте, Hermitap, Вы писали:
Во всем виноват коронавирус
https://visualstudiomagazine.com/articles/2020/12/01/blazor-performance.aspx?admgarea=ALM

Обратите внимание, что сама WinForms испытала некоторые проблемы при пересадке со старой платформы .NET Framework только для Windows на кросс-платформенную схему .NET Core с открытым исходным кодом (теперь она является частью .NET 5).

Команда разработчиков Microsoft в конце прошлого года объяснила "огромную техническую проблему", с которой она столкнулась при создании конструктора WinForms на .NET Core.

"Для разработчиков .NET Core Windows Forms Designer (когда мы выпустим версию GA) будет выглядеть и чувствовать себя так же, как и .NET Framework Windows Forms Designer", — сказала Оля Гавриш, менеджер программ .NET, в октябре 2019 года. "Но для нас это огромная техническая проблема, чтобы привести дизайнера к .NET Core, потому что это требует поверхности разработки, которая размещает живую форму .NET Core, чтобы работать вне процесса Visual Studio. Это означает, что нам нужно заново спроектировать способ, которым дизайнерская поверхность "взаимодействует" с Visual Studio."

Растущая пандемия COVID-19 также вызвала некоторые проблемы в достижении первоначальных целей .NET 5, так что другие функциональные возможности планировалось включить в Nov. 10 дебют .NET 5 был отложен до .NET 6, выпуска долгосрочной поддержки (LTS), запланированного на ноябрь 2021 года.

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

Здравствуйте, notacat, Вы писали:

N>я думаю, они банально недооценили размер проблемы, написать новый дизайнер для винформс, да еще с роутингом между процессами. Т.е. когда они только первый раз нам рассказывали, что они планируют, в 19 году, это уже было очевидно. Но прогресс неплохой, могло быть хуже.

Что такое "роутинг между процессами" в контексте дизайнера?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, VladD2, Вы писали:

КД>>>И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.

VD>>Ну, так то, что для EF и LINQ2DB написано море провайдеров говорит о том, что авторы уделили серьезное внимание созданию инфраструктуры провайдеров.

КД>Да, Copy&Paste — сильная вещь.

Ты и нас достал и EF Core команду. Вместо того чтобы писать провайдер, начал учить как надо писать код. И надо было все бросить и написать как надо прям на завтра.
Сначала делается дело, потом смотрится что можно улучшить. Бывает что можно дорефакториться и получить проседание в скорости или того хуже в памяти на ровном месте. И потом уже ты смотришь на предыдущее решение внимательней.
Копипаста в провайдерах присутствует минимально и постепенно устраняется, опять же прогнав через BenchmarkDotNet.

Здравствуйте, Sharov, Вы писали:
S>Что такое "роутинг между процессами" в контексте дизайнера?
Форма живёт в одном процессе, а бэкенд компилятора (roslyn et al) — в другом.

N>>я думаю, они банально недооценили размер проблемы, написать новый дизайнер для винформс, да еще с роутингом между процессами. Т.е. когда они только первый раз нам рассказывали, что они планируют, в 19 году, это уже было очевидно. Но прогресс неплохой, могло быть хуже.

S>Что такое "роутинг между процессами" в контексте дизайнера?
Поверхность дизайнера вместе с содержимым — один процесс в .Net 5, студия и проперти грид — другой процесс в .Net 4.(7 или 8, не помню), чтобы показать что-то в проперти гриде, сериализовать, а изменения применить к дизайнеру — каждый раз надо как-то пробросить все типы туда-обратно. Может роутинг не то слово, давно не читала русскоязычной документации

Здравствуйте, Danchik, Вы писали:

КД>>Да, Copy&Paste — сильная вещь.

D>Ты и нас достал и EF Core команду. Вместо того чтобы писать провайдер, начал учить как надо писать код. И надо было все бросить и написать как надо прям на завтра.

Ой, ой, ой.

---
Понять и простить (с) Один из разработчиков Firebird. Наверное в 2013-ом году.

Здравствуйте, Danchik, Вы писали:

КД>>>>И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.

VD>>>Ну, так то, что для EF и LINQ2DB написано море провайдеров говорит о том, что авторы уделили серьезное внимание созданию инфраструктуры провайдеров.

КД>>Да, Copy&Paste — сильная вещь.

D>Ты и нас достал и EF Core команду. Вместо того чтобы писать провайдер, начал учить как надо писать код.

В общем, я закончил свою штуку. Под EF Core.

Одна (из двух) подсистем не пролезла в их инфраструктуру.

Ну а в вашу не пролезли обе.

Такие дела.

Здравствуйте, DDDX, Вы писали:

DDD>В общем, я закончил свою штуку. Под EF Core.

А зачем эта штука нужна, да ещё через OLE DB? Есть же нормальный нативный FB3 провайдер.

Здравствуйте, IT, Вы писали:

DDD>>В общем, я закончил свою штуку. Под EF Core.

IT>А зачем эта штука нужна, да ещё через OLE DB? Есть же нормальный нативный FB3 провайдер.

	Разработчик FBNetProvider про свое поделие. 2013 год.
	[1] Let’s face it, the code is crappy. Redesign would be nice. But I don’t blame anybody, 5-10 years ago it was different story. .NET was different (a lot) and we had different understanding of how it works and should work (and how we should design code).

С тех пор там практически ничего не поменялось. С моей точки зрения.

---
Что касается OLE DB (IBProvider).

Меня вообще забавляют такие вопросы.

Сейчас этот слой предоставляет базовые сервисы для взаимодействия с сервером.

Управление ресурсами подключения, всякие парсеры/конверторы/кэши, механику результирующих множеств и так далее и тому подобное.

Ну, в общем, сейчас это самодостаточный клиент к FB, предоставляющий вполне приличный объектный API. Который полностью освобождает верхний уровень от всякой низкоуровневой мути.

По уровню сложности и надежности, скажем так, он выходит за рамки обывательского представления о такого рода компонентах.

Так что эту штуку уже не объехать и не перепрыгнуть.

И я рассмеюсь в лицо тому, кто скажет, что он сможет заместить его функционал

Он по-моему сейчас поддерживает около 20 разных версий FB/IB, два типа ISC API.

А для FB еще до кучи предоставляет заново спроектированный и исправленный сетевой клиент (их родной меня задрал).

Кста, к IBProvider-у еще сервис пула OLEDB подключений прилагается на замену системному (тоже утомил).

---
ADO.NET провайдер (lcpi.data.oledb) — "просто транслятор вызовов" в OLEDB провайдер.

Если бы System.Data.OleDb был нормально написан, этот провайдер можно было бы не создавать.

---
Уровень EFCore.

Это для тех кому лень писать запросы. Грубо говоря.

И здесь весь сыр-бор в обеспечении корректности и согласованности этого "генератора" запросов.

В основном это касается "локальных" и "серверных" вычислений.

На главной странице приведен один из таких примеров.

Ну и до кучи я там другие вещи EFCore поправил.

Я не про то, что им в трекер писал.

Даже забавно, что они там сами не в состоянии в полный рост использовать свои собственные наработки.

И да, этот мой провайдер для EFCore поддерживает работу с базами данных первого диалекта. Потому что (пока) могу.

---
А вообще, в целом, поскольку внизу лежит нормальный провайдер данных, внутри windows-приложения можно чудить не по-детски.

В середине нулевых это была смесь кода на плюсах и VBS. Типа полностью программируемого репликатора и заскриптованных пользовательских приложений.

С начала 10-ых уже можно прикручивать и компоненты на C# — раз, два.

А сейчас вот уже можно и через EFCore запросы к базе лепить.

---
Как-то так.

Здравствуйте, DDDX, Вы писали:

IT>>А зачем эта штука нужна, да ещё через OLE DB? Есть же нормальный нативный FB3 провайдер.
DDD>С тех пор там практически ничего не поменялось. С моей точки зрения.

А как остальной мир живёт в таких невыносимых условиях?

DDD>Что касается OLE DB (IBProvider).
DDD>Меня вообще забавляют такие вопросы.

Это да. Меня тоже забавляют такие ответы.

DDD>ADO.NET провайдер (lcpi.data.oledb) — "просто транслятор вызовов" в OLEDB провайдер.

Т.е. линукс похрен. К тому же, чтобы запустить прогу, использующую эту хрень, нужно ставить и настраивать кучу всякого.

DDD>А вообще, в целом, поскольку внизу лежит нормальный провайдер данных, внутри windows-приложения можно чудить не по-детски.

Мне всегда казалось, что задача провайдера данных не "чудить не по-детски", а прилежно передавать SQL от клиента к серверу и полученный результат обратно. Разве не так?

S>Команда разработчиков Microsoft в конце прошлого года объяснила "огромную техническую проблему", с которой она столкнулась при создании конструктора WinForms на .NET Core.
S>"Для разработчиков .NET Core Windows Forms Designer (когда мы выпустим версию GA) будет выглядеть и чувствовать себя так же, как и .NET Framework Windows Forms Designer", — сказала Оля Гавриш, менеджер программ .NET, в октябре 2019 года. "Но для нас это огромная техническая проблема, чтобы привести дизайнера к .NET Core, потому что это требует поверхности разработки, которая размещает живую форму .NET Core, чтобы работать вне процесса Visual Studio. Это означает, что нам нужно заново спроектировать способ, которым дизайнерская поверхность "взаимодействует" с Visual Studio."
Нет бы воспользоваться поводом, и закопать "сериализацию формы в код", и сделать возможность дизайнить winforms через xaml, единообразно с wpf. Без дизайнера — winforms через xaml уже давно работает.

Здравствуйте, IT, Вы писали:

<вырезано>

IT>К тому же, чтобы запустить прогу, использующую эту хрень, нужно ставить и настраивать кучу всякого.

Есть такая штука — "Registration Free COM".

Все ставится простым копированием.

DDD>>А вообще, в целом, поскольку внизу лежит нормальный провайдер данных, внутри windows-приложения можно чудить не по-детски.

IT>Мне всегда казалось, что задача провайдера данных не "чудить не по-детски",

В приложении, а не в провайдере.

Здравствуйте, IT, Вы писали:

DDD>>С тех пор там практически ничего не поменялось. С моей точки зрения.
IT>А как остальной мир живёт в таких невыносимых условиях?

Отвечу так.

В нулевых я юзал FB. Полагаю, что достаточно в серьезном проекте. Мля, да его везде юзал. И он радовал меня.

А потом начал ... копать его код и как отрезало.

То есть давай различать эксплуатацию бытовой техники и четкое понимание того, что она из себя на самом деле представляет.

Почему дальше вожусь с FB? "Ну, понимаешь сынок, родину не выбирают". И я точно знаю, что оно щас все такое.

И кстати, я не питаю илюзий и насчет своего кода. Но прилагаю все усилия чтобы не давать повода

IT>Т.е. линукс похрен.

Не интересно. Такой ответ тебя устроит?

Но толстенная книжка по Linux API у меня стоит на полке.

	Навеяло
	Я в 2005 купил первое издание Рихтера про .NET. Прочитал её летом 2011-го. Меня тогда натурально начало рвать на плюсы и надо было что-то с этим делать Другую книжку по алгоритмам (Седжвик, кажется) купил в 2003. Полистал введение, понял как решать свою задачу и отложил её в сторону. Прочитал её только летом 2020. Так что эта книжка про Linux должна отлежать свое. Введение я прочитал, толковая. Только не говори, что на Linux нет COM

Здравствуйте, DDDX, Вы писали:

DDD>Не интересно. Такой ответ тебя устроит?

Зачем ты тогда сюда про это пишешь? В облаках, даже приватных, винды, считай, нет. А гоняние БД на десктопах/мелких серверах это нынче великая экзотика, по крайней мере в плане разработки таких решений, а не эксплуатации существующих.
Так что неинтересно это твое виндовс онли.

Здравствуйте, Ночной Смотрящий, Вы писали:

DDD>>Не интересно. Такой ответ тебя устроит?

НС>Зачем ты тогда сюда про это пишешь? В облаках, даже приватных, винды, считай, нет. А гоняние БД на десктопах/мелких серверах это нынче великая экзотика, по крайней мере в плане разработки таких решений, а не эксплуатации существующих.
НС>Так что неинтересно это твое виндовс онли.

Он спросил, я ответил.

Я так понимаю, что про существу — что из себя должен мог бы представлять нормальный провайдер EFCore, вопросов нет.

Здравствуйте, DDDX, Вы писали:

DDD>Я так понимаю, что про существу — что из себя должен мог бы представлять нормальный провайдер EFCore, вопросов нет.

По существу у тебя там количество звезд все красноречиво говорит.

Здравствуйте, DDDX, Вы писали:

DDD>

	Навеяло
	DDD>Я в 2005 купил первое издание Рихтера про .NET. Прочитал её летом 2011-го. Меня тогда натурально начало рвать на плюсы и надо было что-то с этим делать DDD>Другую книжку по алгоритмам (Седжвик, кажется) купил в 2003. Полистал введение, понял как решать свою задачу и отложил её в сторону. Прочитал её только летом 2020. DDD>Так что эта книжка про Linux должна отлежать свое. Введение я прочитал, толковая. DDD>Только не говори, что на Linux нет COM

Такая же фигня -- покупаю книжки и не читаю их потом. Или забрасываю на середине.

Здравствуйте, Osaka, Вы писали:

S>>Команда разработчиков Microsoft в конце прошлого года объяснила "огромную техническую проблему", с которой она столкнулась при создании конструктора WinForms на .NET Core.
S>>"Для разработчиков .NET Core Windows Forms Designer (когда мы выпустим версию GA) будет выглядеть и чувствовать себя так же, как и .NET Framework Windows Forms Designer", — сказала Оля Гавриш, менеджер программ .NET, в октябре 2019 года. "Но для нас это огромная техническая проблема, чтобы привести дизайнера к .NET Core, потому что это требует поверхности разработки, которая размещает живую форму .NET Core, чтобы работать вне процесса Visual Studio. Это означает, что нам нужно заново спроектировать способ, которым дизайнерская поверхность "взаимодействует" с Visual Studio."
O>Нет бы воспользоваться поводом, и закопать "сериализацию формы в код", и сделать возможность дизайнить winforms через xaml, единообразно с wpf. Без дизайнера — winforms через xaml уже давно работает.

Пошли другим путем
State of the Windows Forms Designer for .NET Applications

До тех пор, пока мы не добавили поддержку приложений .NET Core, существовал только один процесс, devenv.exe, в котором работали как среда Visual Studio, так и разрабатываемое приложение. Но .NET Framework и .NET Core не могут работать вместе в devenv.exe, и в результате нам пришлось вывести дизайнера из процесса, поэтому мы назвали нового дизайнера – WinForms из конструктора процессов (или, сокращенно, дизайнера ООП).

Заглянем под капот дизайнера WinForms
Разработка форм и пользовательских элементов управления с помощью дизайнера WinForms таит в себе пару сюрпризов для людей, которые впервые заглядывают под капюшон дизайнера:

Дизайнер не “сохраняет” (сериализует) макет в каком-либо XML или JSON. Он сериализует определение Forms/UserControl непосредственно в код – в новом конструкторе ООП, который является либо C#, либо Visual Basic .NET. Когда пользователь помещает Кнопку в Форму, код для создания этой Кнопки и назначения ее свойств генерируется в методе Формы, называемом " Инициализировать компонент`. Когда форма открывается в конструкторе, анализируется метод " Инициализировать компонент` и отображается тень .ЧИСТАЯ сборка создается на лету из этого кода. Эта сборка содержит исполняемую версию "InitializeComponent", которая загружается в контексте конструктора. Затем выполняется метод `InitializeComponent`, и дизайнер теперь может отобразить полученную форму со всеми ее определениями элементов управления и назначенными свойствами. Мы называем этот вид сериализации сериализацией объектной модели документа кода или, для краткости, сериализацией CodeDom. По этой причине вы не должны редактировать "Инициализировать компонент" напрямую: в следующий раз, когда вы визуально отредактируете что-то в форме и сохраните это, метод будет перезаписан, и ваши изменения будут потеряны.
Все элементы управления WinForms имеют два уровня кода. Сначала есть код для элемента управления, который выполняется во время выполнения, а затем есть конструктор элементов управления, который управляет поведением во время разработки. Функциональные возможности конструктора элементов управления для каждого элемента управления не реализованы в самом конструкторе. Скорее, специальный конструктор элементов управления взаимодействует со службами и функциями Visual Studio.Давайте рассмотрим `SplitContainer " в качестве примера:

Войдите на сервер DesignToolsServer
Разработчикам необходимо, чтобы их формы в конструкторе выглядели именно так, как они будут выглядеть во время выполнения (WYSIWYG). Будь то свойство "placeholderText" из предыдущего примера или макет формы с требуемым шрифтом по умолчанию – сериализатор CodeDom должен запускаться в контексте версии .NET, на которую нацелен проект. И мы, естественно, не можем этого сделать, если сериализация CodeDom выполняется в том же процессе, что и Visual Studio. Чтобы решить эту проблему, мы запускаем конструктор вне процесса (отсюда и прозвище из конструктора процессов) в новом процессе .NET (Core) под названием DesignToolsServer. Процесс DesignToolsServer запускает ту же версию .NET и ту же разрядность (x86 или x64), что и ваше приложение.

Теперь, когда вы дважды щелкаете по форме или элементу управления пользователем в Обозревателе решений, служба загрузчика конструктора Visual Studio определяет цель .Net версия и запускает процесс DesignToolsServer. Затем загрузчик конструктора передает код из метода `InitializeComponent` в процесс DesignToolsServer, где он теперь может выполняться в желаемой среде выполнения .NET и теперь может работать со всеми типами и свойствами, предоставляемыми этой средой выполнения.

Здравствуйте, СвободуАнжелеДевис, Вы писали:

САД>Потому что девелопер всегда стремится к изучению нового, а не застрял в глубоком 2002м году.
САД>А потом жалуются, что на работу не берут, или денег мало платят....

Забавно, всегда думал, что годный ответ на этот вопрос — потому что новое решение лучше старого а)... б).... в)...

САД>>Потому что девелопер всегда стремится к изучению нового, а не застрял в глубоком 2002м году.
САД>>А потом жалуются, что на работу не берут, или денег мало платят....
P>Забавно, всегда думал, что годный ответ на этот вопрос — потому что новое решение лучше старого а)... б).... в)...

годно — маломальски заниматься саморазвитием, и интересоваться тем, что происходит в своей сфере, тогда и вопросов подобных возникать не будет

P>Забавно, всегда думал, что годный ответ на этот вопрос — потому что новое решение лучше старого а)... б).... в)...
Сейчас правильный ответ — новое решение уже как-то работает, а старое сняли с поддержки и того и гляди отвалиться. Надо мигрировать заранее пока не бахнуло.

Здравствуйте, СвободуАнжелеДевис, Вы писали:

САД>годно — маломальски заниматься саморазвитием, и интересоваться тем, что происходит в своей сфере, тогда и вопросов подобных возникать не будет
Обрати внимание, я комментировал не вопрос, а ответ.

Здравствуйте, СвободуАнжелеДевис, Вы писали:

САД>Потому что девелопер всегда стремится к изучению нового, а не застрял в глубоком 2002м году.

Не, кто в 2002 году застрял советуют изучать в 2022 ExpandoObject и прочее дерьмо мамонта из тех времен.