Миграция .Net Framework => .Net Core
Есть у нас приложение, разработку которого мы начали году в 2017
Состоит из 2 частей: Веб-приложение на и Бэкэнд (Windows Service, На схеме это ServiceHost)
между собой Веб-приложение и ServiceHost общаются по WCF плюс он еще принимает и отправляет данные по WCF третьим лицам
Основные требования заказчика выполнены и собрались мы его мигрировать на .Net #7.
Первые препятствия были поднять Windows сервис на .Net Core и WCF сервис - тут вроде разобрались
Потом споткнулись об отсутствие Workflow Foundation под Core, нашли вроде порт от энтузиастов, но там во-первых не полная поддержка (нет графического редактора Workflows), во-вторых у нас там кастомизировано слегка, так что пришлось эту идею отбросить и мигрировать только веб-проложение.
Но тут челлендж в том, что все остальное должно остаться .Net Framework(то есть веб на .Net #7 долен референцировать Persistence на .Net Framework 4.X, что само по себе вроде работает).
И сейчас боремся с тем, чтобы веб-приложние дружило с Persistence и его зависимостями(Entity Framework + Oracle.ManagedDataAccess)
Проблема в том, что в старом приложении был web.config, в котором мы говорили EF, что он должен работать с драйвером Оракла.
<configSections>
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</configSections>
<entityFramework>
<providers>
<provider invariantName="Oracle.ManagedDataAccess.Client" type="Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices, Oracle.ManagedDataAccess.EntityFramework, Version=6.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
</providers>
</entityFramework>
<system.data>
<DbProviderFactories>
<remove invariant="Oracle.ManagedDataAccess.Client" />
<add name="ODP.NET, Managed Driver" invariant="Oracle.ManagedDataAccess.Client" description="Oracle Data Provider for .NET, Managed Driver" type="Oracle.ManagedDataAccess.Client.OracleClientFactory, Oracle.ManagedDataAccess, Version=4.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
</DbProviderFactories>
</system.data>
В Net.Core ни веб ни эпп.конфига нет.
В общем или мы тупые или этот проект превращается в легаси.
.png)
Не переживайте во всём можно разобраться, только нужно время
А в чём проблема с ораклом? Работает без проблем, строка соединения в appsettings.json
Где то примерно так
{
"AppSettings": {
"IsSqlite": false,
"ConnectionString": "Host=myhost; user id=myuser; database=mydb;",
"DbPassword": "<set value into secrets.json",
},
</set>
services.AddDbContext<AppDbContext>(
optionsBuilder =>
{
{
optionsBuilder.UseOraclel($"password={appSettings.DbPassword};{appSettings.ConnectionString}");
optionsBuilder.EnableSensitiveDataLogging().LogTo(l => Debug.WriteLine(l));
optionsBuilder.EnableDetailedErrors(true);
optionsBuilder.LogTo(l => Debug.WriteLine(l));
}
}, ServiceLifetime.Transient);
А зачем WCF затащили?
отчего так? Не видел еще что бы так делали
REST Api выдает что нужно из ДБ, а морда общается с АПИ
не вижу смысла общаться контроллерам из ASP.Net MVC с базой данных через посредника в лице бэкэнда.
И почему WCF(Soap), а не Rest - в .Net он гораздо лучше (был) интегрирован.
в .Net он гораздо лучше (был) интегрирован
Вероятно ударение на был. Для меня это какая то старая рухлядь.
https://learn.microsoft.com/ru-ru/dotnet/architecture/grpc...
не вижу смысла общаться контроллерам из ASP.Net MVC с базой данных
А в чём тогда смысл?
https://en.wikipedia.org/wiki/ASP.NET_MVC - It is no longer in active development. В этом?
Как заставили работать WCF на дотнете 5+? Вроде, там кроме какой-то замены, пилимой командой энтузиастов, не было? Мы у себя отказались.
Веб конфигов в дотнете 5+ нет - теперь всё в джейсоне хранится. Но суть та же - та же строка подключения.
Не знаю, как у вас общаются между собой приложения между дотнет 4- и 5+ (через какие-то независимые схемы обмена данными, типа REST?), но если код написан на 4- без задействования либ, зависящих от 4-, то он без изменений переносится в 5+. У нас надо какое-то время в проекте держать и версии 4-, и версии 5+. Для этого мы в проекты 5+ добавляет ссылки на исходные файлы (add as link) 4-. А ещё раньше часть либ на .NET Standard переводилась (зачастую тоже через add as link).
По букварям по миграциям прошлись?
https://learn.microsoft.com/en-us/dotnet/core/porting/
https://learn.microsoft.com/en-us/aspnet/core/migration/pr...
https://learn.microsoft.com/en-us/dotnet/architecture/blaz...
Там ещё надо внимательным быть при выборе миграции на какую 5+ версию. 5, 6 и 7 между собой немного отличаются, а 5 и 6 - довольно таки много. И может статься (т.е. я не уверен), что сразу мигрировать на 7 не получится - придётся в некоторых местах пройти все миграции последовательно: 4 - 5 - 6 - 7.
У нас тоже есть слой Workflows, но по мне это хрень какая-то, если приложение не прямо мегамонструозное. При анализе кода заметил, что часть работы, которая писалась в слое Workflows, также присутствовала и в бизнес логике. Т.е. по сути пофиг было, где эту логику писать, а лишний слой лишь усложнял понимание. Хотя, может так стало после многочисленных переписываний кода (нам досталась версия возрастом лет 15 после минимум двух команд).
В общем или мы тупые или этот проект превращается в легаси.
Вы - тупые легаси, старпёры и замшелые динозавры. Переходите на MAUI и Blazor, пока вас не стёрла с лица земли молодая шпана. )))
Всё это дерьмо упрощается до
если использовать Blazor и MAUI. Т.е. стрелочек от бизнеса и далее к клиентам может быть максимум по 2.
Но для вытряхивания денег из заказчиков можно, конечно, рисовать лабиринты и ребусы.
services.AddDbContext<AppDbContext>(
optionsBuilder =>
{
{
optionsBuilder.UseOraclel($"password={appSettings.DbPassword};{appSettings.ConnectionString}");
optionsBuilder.EnableSensitiveDataLogging().LogTo(l => Debug.WriteLine(l));
optionsBuilder.EnableDetailedErrors(true);
optionsBuilder.LogTo(l => Debug.WriteLine(l));
}
}, ServiceLifetime.Transient);Функция AddDbContext это часть EntityFrameworkCore
а мне нужно оставить EntityFramework 6, чтобы работал ServiceHost и все остальное
Как заставили работать WCF на дотнете 5+? Вроде, там кроме какой-то замены, пилимой командой энтузиастов, не было? Мы у себя отказались.
есть ограничения, не все байндинги реализованы, не нашел возможности поднимать несколько сервисов на разных портах, но вроде работает
Веб конфигов в дотнете 5+ нет - теперь всё в джейсоне хранится. Но суть та же - та же строка подключениястрока подключения - фигня
вот как сказать ЕФ, чтобы он работал с драйвером оракла - не пойму
https://github.com/CoreWCF
Это коммьюнити проджект. Со всеми вытекающими. Официально МС забила на WCF.
есть ограничения, не все байндинги реализованы
Я это ещё год с лишним назад смотрел, и тогда тоже было "не все байндинги реализованы". Прошёл год с лишним, а оно всё ещё "не все...", и нет гарантий, что будут все. МС педалит свой СигналР, и хотя в начале говорили, что не на замену, но чем дальше, тем больше похоже на замену.
https://www.reddit.com/r/csharp/comments/whz0zk/replacing_...
Простой проект на WCF (см. пример в первой ссылке на блог коммьюнити) и на SignalR по объёму почти равны, но в примере WCF лишь код для самой WCF, без обвязки в виде клиента, а в примере SignalR - со всей обвязкой. Вот ещё букварь с примером на СигналР.
Вообще, желание повязать Дотнет 4- и 5+ хреновое. По букварям с миграциями там для неподдерживаемых технологий, коих не так уж мало, просто стоит "побрейтесь". В лучшем случае - "вот вам коммьюнити проект, ждите реализации нужных вам фич, или реализуйте сами".
Многие проблемы решает добавление либы Microsoft.Windows.Compatibility.
Старые сторонние либы можно заменить аналогами (например, логгер log4net на что-то актуальное).
Про WCF уже сказали.
System.EnterpriseServices (COM+) - нет.
Тут ещё. Для WWF предлагается ещё один коммьюнити проект.
Вообще, желание повязать Дотнет 4- и 5+ хреновое.
или так, или все переделывать. Такое заказчику не продашь.
Для WWF предлагается ещё один коммьюнити проект.
спасибо, кэп.
Получается что Repository pattern не пользуете, предложение напрямую к базе обращается? Брр.
Вот ту вроде готовый пример есть, там они контекст сервисом сделали.
https://learn.microsoft.com/en-us/aspnet/core/data/entity-...
или так, или все переделывать. Такое заказчику не продашь.
Нужно просто разложить по полочкам все варианты. Гибрид проживет еще какое то время и опять завалится.
А вот относительно Блазора я бы предложил все же подумать, уж некоторое количество лет только его и пользую.
https://demos.telerik.com/blazor-ui/grid/overview
https://demos.telerik.com/blazor-ui/scheduler/overview - драг дроп очень удобный.
Хотя да, для некоторых приложений он не подходил, с .нет 8 некоторые ограничения должны уйти.
Теперь можно будет для каждой страницы указывать работать с ней как "сервер" или как "клиент". Причем если нужные либы не подгружены, то может пользоваться сервер, а после погрузки клиент/васм
Фактически из за этого пришлось пользовать ангуляр в одном из проектов, очень уж долго было первичное время отклика.
Схему видел?
И что именно там нужно было увидеть?
Без оракла каждый может
Ну можно еще через нет стандарт попробовать.
https://github.com/dedpichto/ag.DbData.Oracle
https://www.hanselman.com/blog/referencing-net-standard-as...
Хотя никак не доходят до меня все эти мучения. Есть у меня АПИ, как хочу так и делаю, есть вызовы АПИ - тоже как хочу так и делаю или нет4 или нет6.
что Workflow Foundation не мигрируется на новые версии.
https://github.com/UiPath/CoreWF
А что в нем интересного? никогда не приходилось пользовать.
И что именно там нужно было увидеть?
увидеть, где
предложение напрямую к базе обращается
Ну можно еще через нет стандарт попробовать.
https://github.com/dedpichto/ag.DbData.Oracle
Не похоже, чтобы это был драйвер оракла для EF.
в общем объяснить ЕФ, что нужно использовать драйвер оракла, у меня получилось
но при попытке доступа к ДБ вылетает ошибка
System.TypeLoadException: 'Could not load type 'System.Security.Principal.WindowsImpersonationContext'
from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.'
at OracleInternal.ConnectionPool.PoolManager`3.CreateNewPRThreadFunc(Object state)
at System.Threading.QueueUserWorkItemCallback.Execute() in /_/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs:line 1220
at System.Threading.ThreadPoolWorkQueue.Dispatch() in /_/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs:line 924
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() in /_/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WorkerThread.cs:line 77
в нет 7 этого класса конечно нет
и вообще любопытно, для чего оно понадобилось ораклу
Вроде, со всеми БД работа идёт через провайдеры баз данных? Обычно сама МС или кто сторонний их пишет - к ним все вопросы, чего не обновляют. Толку пытаться самому в одного это вытащить, если эти штуки пишут команды шестизначных помидоров с семизначными опционами?
возможность графического представления процессов.
Что то типа этого?
https://blazor.syncfusion.com/demos/diagramcomponent/flowchart?theme=bootstrap5
Что то типа этого?
https://blazor.syncfusion.com/demos/diagramcomponent/flowchart?theme=bootstrap5
Ты не понял. Наше приложение не даёт пользователю возможность моделировать процессы. Процессы работают внутри приложения - обрабатывают данные.
вообще-то две
Зачем DevArt, когда есть бесплатный драйвер напрямую от производителя?
https://www.devart.com/dotconnect/oracle/articles/comparin...
линия от Presistence к Domain же в другую сторону.
tps://www.devart.com/dotconnect/oracle/articles/comparin...
ещё бы они в своей сравниловке написали, что хуже чем другие.
Вот только я уверен, что
1) у них тоже нет версии, которая совместима с обоими мирами
2) потребуется переписывать имеющийся код, если заменить драйвер от оракла.
у них тоже нет версии, которая совместима с обоими мирами
Ну вроде NET standard вполне достаточен для обоих миров. Хотя я так и не понял отчего нельзя всё перекомпилить.
dotConnect for Oracle has four sets of assemblies:
- for full .NET Framework
- .NET Standard 1.3 compatible assemblies (compatible with .NET Core 1.0 and higher and .NET Framework 4.6 and higher)
- .NET Standard 2.0 compatible assemblies (compatible with .NET Core 2.0 and higher and .NET Framework 4.6.1 and higher)
- .NET Standard 2.1 compatible assemblies (compatible with .NET Core 3.0 and higher only, .NET Framework is not supported)
потребуется переписывать имеющийся код, если заменить драйвер от оракла.
Это если извращения есть. А так, довольно спокойно перешли с Оракла на постгрес.
У Оракла же лицензия/цены изменилась.
Не похоже, чтобы это был драйвер оракла для EF
------
Там не драйвер, а провайдер.
С OracleManagetAccess - никак не связанный.
Задача провайдера в ЕФ - синтез СКЛ под конкретную версию Оракла.
А ОраклеМанаджетАкксесс - это повехностная проверка СКЛ (и нахрена ее туда впендрючили?) и управление обменом с сервером.
Провайдер для ЕФ - встроенный в .Нет. Ничего дополнительного не нужно. Должно работать из коробки.
А с ОраклеМанаджетАксесс нужно выбирать внимательно - там куча версий и зависимостей от версии сервера... хотя... он сам сообщает что не поддерживает... хммм... это анменаджет сообщает, а как манаджет не знаю.
для чего оно понадобилось ораклу
-----
Для прав доступа скорее всего.
Посмотри версии драйверов - твои требуют .Нет 4.0, а код в котором идет вызов скорее всего не совместимый.
И проверь еще тип проекта и используемый в проекте фраймворк - там иногда просто слетают установки.