Миграция приложения Delphi 7 к.NET
Я бы использовал регулярное выражение, которое использует утверждение нулевой длины
, чтобы сопоставить что-либо в строке после ключевого слова (даже буквальную звездочку)
сценарий изменяется на месте, используя то же имя файла при сохранении.
## Q:\Test\2019\01\18\SO_54259368.ps1
Push-Location "C:\Program Files\SplunkUniversalForwarder\etc\system\local"
$Clie = "inputs.conf"
$Serv = "server.conf"
(Get-Content $Clie) -replace "(?<=^host = ).*$",$Env:COMPUTERNAME | Set-Content $Clie
(Get-Content $Serv) -replace "(?<=^serverName = ).*$",$Env:COMPUTERNAME | Set-Content $Serv
Pop-Location
8 ответов
Я работал в компании, которая мигрировала от Delphi до WPF/.Net приблизительно 2007. Мы попробовали часть подходом части. Это было болезненно. Мы всегда сталкивались с тонкими ошибками в interop. Вызов от Delphi до WPF или Winforms и назад является болезненным. Если различные средства управления UI и окна Вашего приложения обращаются друг к другу много, я думаю, что Вы испытаете значительную болезнь роста.
Если бы можно позволить себе сделать целое преобразование сразу, я пошел бы для него. В противном случае разделение части Вашего приложения, которые автономны или имеют минимум взаимодействий с остальной частью приложения.
Я также предложил бы вскочить в.Net 2008. Почему Вы выбираете технологию, которая почти 4 года (VS 2005)? Я думаю, что это очень, очень плохое бизнес-решение принять решение вскочить в.Net 2.0, когда.Net 3.5 очень стабилен. Единственная допустимая причина, которую я когда-либо представлял бы управлению для.Net 2.0, будет состоять в том, чтобы поддерживать Windows 2000. У Вас все еще есть клиенты на Win2k? У Вас все еще будут клиенты на Win2k к тому времени, когда Ваше преобразование завершено? У Вас есть клиенты, которых Вы не можете получить для перемещения в XP или Vista?.Net 3.0 и 3.5 не поддерживается в Win2k. Это - единственный недостаток, о котором я могу думать.
.Net 3.5 и предложение 2008 года C# значительные преимущества для Вашей компании. У Вас есть много функций языка, которые ускорятся, разрабатывают время по сравнению с C# 2.0. У Вас есть WPF, который значительно превосходит Winforms. Я утверждал бы, что можно разработать тот же batteleship-серый Windows, Вы вошли бы в Winforms с WPF, разработали бы их быстрее, и когда Вы захотите некоторую усладу для глаз, Вы будете использовать технологию, которая может легко обеспечить его. Если Вы изучаете новую платформу работы с окнами для этого преобразования, почему бы не вложить капитал в изучение нового материала?
Кроме того, скажите мне, что Вы на самом деле не купили VS 2005. Можно купить Универсальную лицензию MSDN приблизительно для той же стоимости и получить каждый сопутствующий товар разработки, который делает Microsoft. Купите его у третьей стороны, и Вы получите хорошую скидку.
Извините, если я оторвался отрицательный. С уважением, удача на миграции. У меня просто есть ретроспективные кадры, когда я думаю о необходимости бросить всех положительных героев в.Net 3.5.
Это походит на действительно плохую идею мне.
Есть ли какое-либо технологическое преимущество для Вашего продукта, чтобы быть в.NET, или это - главным образом политическое решение быть магазином Microsoft? Для клиент-сервер Delphi довольно жесток для избиения. Я использовал VS2005/8, и это действительно и действительно действительно и искренне не столь хорошо как Delphi для разработки Win32. Но если Вы собираетесь мигрировать на сеть в будущем, затем VS имеет определенные преимущества.
Если упрямые бизнес-люди просто отказываются использовать Delphi еще, то KiwiBastard корректен, IMO. Преобразуйте сначала в Delphi.NET, затем мигрируйте оттуда на VS2005. Или 2010, так как это - более реалистическая временная шкала :)
Я ранее работал в компании, которая хотела преобразовать от Delphi до C#.NET, потому что.NET является все прохладной и блестящей. Они ввели еще некоторых разработчиков, у которых был большой опыт C#, и он закончил тем, что брал 3 раза разработчиков, вдвое более длинных для портирования приложения на C# затем, он сделал, чтобы записать этому первый раз в Delphi для очень небольшого количества дополнительного ROI (несколько новых опций были добавлены в процессе). Плюс клиенты не были довольны производительностью приложения или UI.
Тематическое исследование после тематического исследования показывает, что перезапись является плохой идеей. (Благодарность за информацию к kogus)
Если необходимо переместиться в.NET (да, я знаю, Вы не приняли решение, кто-то с меньшей информацией сделал), затем, я предложу использовать Delphi для.NET или RemObjects Oxygene. Последнее существо плагин Visual Studio. Но даже marc hofman, Главный Архитектор программного обеспечения RemObjects Oxygene сказал, что это - плохая идея переместить совершенно рабочее приложение в.NET "просто так."
Если можно ожидать Призмы Delphi, которая является также дополнением Visual Studio и, как ожидают, будет отсутствовать позже в этом году.
Постепенное преобразование означало бы изменять собственный код Delphi для использования COM, таким образом, сторона.NET может сосуществовать с Delphi (или возможно использующий некоторую другую технологию - трудно для высказывания)
Если Вы можете, могло бы быть легче преобразовать приложение в Delphi.NET сначала, то, по крайней мере, биты.NET смогут связаться немного легче.
Просто мысль.
Отодвигание от инструментов CodeGear/Borland в основном устраняет любой Delphi, который основанное на.NET решение и общее количество переписывают Вашего приложения.
Я надеюсь, что мой ответ ниже помогает с Вашими решениями.
На основе опыта (переписывавшего приложение Delphi с командой людей), это сводится к любому из двух вариантов ниже.
Но сначала предупреждение: Вы приложите, по крайней мере, общие усилия по разработке, которые это приложило для записи текущего приложения Delphi.
В нашем случае было гарантировано это усилие, так как старое приложение Delphi (который на самом деле это был Kylix) имело конец жизненного цикла из-за различных причин. Наш переписывать состоял из двух частей: перепишите с ограниченной дополнительной функциональностью, сопровождаемой большой дополнительной функциональностью (дизайн первой части уже принял вторую часть во внимание).
Назад к Вашему выбору:
1-общее количество переписывают в C# или VB.NET в Visual Studio
2-частичное повторное использование Вашего существующего слоя бизнеса Delphi кодирует при помощи Oxygene от RemObjecs (плагин Visual Studio с синтаксисом, который очень похож на синтаксис Delphi). CodeGear скоро предложит Призму (вероятно, до конца 2008), который будет также интегрироваться в Visual Studio.
Поскольку доступ к данным.NET и UI полностью отличаются от Delphi, необходимо будет сделать их с нуля (оба для сценария 1 и 2). Visual Studio 2008 предлагает много преимуществ здесь по Visual Studio 2005.
Нет такой вещи как выполнение этой миграции постепенно, так как Вы делаете изменение комплексной платформы здесь, это все или ничего подход.
Оба сценария займут значительное количество времени (даже при том, что у Вас есть опыт Delphi, получение себя приучило в мире.NET, займет время).
Visual Studio может взаимодействовать с Crystal Reports и подходит к SQL Server.
Начиная с Visual Studio 2008 предлагает много преимуществ (не только.NET 3.5, но также и мудрая производительность), необходимо пойти с этим. На стороне UI необходимо сделать сбалансированный выбор между WinForms (иначе Windows Forms) и Windows Presentation Foundation (иначе WPF).
Если это, 1 к 1 переписывают, Вы могли бы хотеть придерживаться WinForms, поскольку это знакомо тому, что Вы имеете. Вероятно, необходимо использовать некоторые сторонние компоненты для получения движения UI; DevExpress является хорошим выбором здесь, поскольку у них есть подобные компоненты в Delphi и Visual Studio.
Но если Вы хотите пойти для будущей услады для глаз, затем Вы могли бы рассмотреть WPF. Будьте подготовлены к более крутой кривой обучения здесь, чем WinForms, поскольку это очень отличается от того, к чему Вы привыкли.
Если Вы решаете остаться с Delphi, Вы могли бы хотеть изучить VCL для сети (иначе IntraWeb) и в Delphi 2009 (много изменилось в мире Delphi, так как о Delphi 7 объявили 6 лет назад).
Удача, делающая Ваш выбор!
- jeroen
Я предложил бы смотреть на Гидру от RemObjects. Это в основном стучит интерфейс com для Вас и предоставляет шаблон "наблюдатель" для взаимодействия через интерфейс между Вашим Delphi и приложением .NET. У Вас могут быть формы .NET, появляются на панелях в Вашем приложении Delphi. Это обеспечивает хороший миграционный путь, где Вы заменяете свой код Delphi поразрядно, поскольку Вы перемещаете функциональность в .NET.
Для меня вопрос был бы: какой язык Вы использовали бы? Я надеюсь что C# и не VB.Net. (Со всей неловкой политикой в этом варианте использования это не ясно каким-либо образом.)
Следующее, которое Вы, вероятно, услышите, - то, что существуют преобразователи там, которые помогут Вам делающий это. Мы просто прошли оценку таких преобразователей (Delphi 7 к C#) и были очень! разочарованный.
Я могу предложить компромисс? Как насчет Призмы Delphi? Это - Delphi в VS2008. Несомненно, у Вас все еще есть Delphi и поэтому Codegear, но у Вас также есть VS (поскольку Ваша компания ожидает Вас к).
Только можно действительно решить, возможна ли часть подходом части. Например, может приложение быть разделенным легко, или все формы слишком сильно вместе со всей бизнес-логикой. Технически это возможно, но все зависит от того, как кодовая база структурирована действительно.