Visual Studio 2005 で既存の Delphi 7 ビジネス アプリケーションを .NET 2.0 に移行する方法について何かアドバイスはありますか?
Visual Studio 2005 は既に購入済みで、会社は Borland/Codegear ツールから離れたいと考えています。
このアプリケーションは単一のクライアント サーバー実行可能ファイルであり、多数のサード パーティの UI コントロールとレポート用の Crystal レポート 10 を利用しています。
多くの SQL Server 2000 ストアド プロシージャだけでなく、UI 内の Delphi 型にまたがる広範なビジネス ロジックがあります。ストアド プロシージャ ロジックの多くを .NET クラスに移動することも、もう 1 つの目標です。
顧客への影響を軽減するために、可能であれば、完全な書き直し/変換ではなく、部分ごとのアプローチが推奨されます。前もって感謝します。
[更新] この種のシナリオで Managed VCL を使用した経験がある人はいますか?
それは私には本当に悪い考えのように聞こえます。
あなたの製品が .NET にあることには技術的な利点がありますか? それとも、Microsoft ショップになることは主に政治的な決定ですか? クライアント サーバーの場合、Delphi に勝るものはありません。私は VS2005/8 を使用してきましたが、それは Win32 開発用の Delphi ほど良くありません。しかし、将来 Web に移行する場合、VS には明確な利点があります。
頑固なビジネス関係者がもう Delphi の使用を拒否するだけなら、IMO の KiwiBastard が正解です。最初に Delphi.NET に変換してから、そこから VS2005 に移行します。または2010年、それはより現実的なタイムラインであるため:)
私は、2007 年頃に Delphi から WPF/.Net に移行していた会社で働いていました。痛かったです。私たちは常に相互運用で微妙なバグに遭遇していました。Delphi から WPF または Winforms への呼び出しとその逆は苦痛です。アプリケーションのさまざまな UI コントロールとウィンドウが相互に頻繁に呼び出しを行う場合、かなりの成長痛を経験することになると思います。
変換全体を一度に行う余裕があれば、私はそれを選びます。そうでない場合は、アプリのスタンドアロンの部分を分割するか、アプリの残りの部分とのやり取りが最小限に抑えられます。
また、.Net 2008 に飛び込むことをお勧めします。なぜ、ほぼ 4 年前のテクノロジ (VS 2005) を選択するのですか? .Net 3.5 が非常に安定しているときに .Net 2.0 に飛び込むことを選択するのは、非常に悪いビジネス上の決定だと思います。私が .Net 2.0 について経営陣に提示する唯一の正当な理由は、Windows 2000 をサポートすることです。まだ Win2k の顧客はいますか? 変換が完了するまでに、まだ Win2k の顧客はいますか? XP または Vista に移行できない顧客はいますか? .Net 3.0 および 3.5 は Win2k ではサポートされていません。それが私が考えることができる唯一の欠点です。
.Net 3.5 と C# 2008 は、企業に大きなメリットをもたらします。C# 2.0 と比較して開発時間を短縮する多くの言語機能があります。Winforms よりもはるかに優れた WPF があります。私は、WPF を使用して Winforms で取得するのと同じ戦艦の灰色の Windows を開発し、より速く開発できると主張します。この変換のために新しいウィンドウ プラットフォームを学習している場合は、新しいものを学習するために投資してみませんか?
また、VS 2005 を実際に購入したわけではないことを教えてください。ほぼ同じ費用でMSDN ユニバーサルライセンスを購入でき、Microsoft が製造するすべての開発関連製品を入手できます。サードパーティから購入すると、かなりの割引が適用されます。
マイナスになったらごめんなさい。心から、移行の幸運を祈ります。.Net 3.5 のすべての利点をあきらめなければならないことを考えると、フラッシュバックがあります。
私は以前、DelphiからC＃.NETに変換したいと考えていた会社で働いていました。これは、.NETがすべてクールで光沢があるためです。彼らはC＃の経験が豊富な開発者を何人か連れてきて、アプリケーションをC＃に移植するのに2倍の時間がかかることになりました。その過程で新しい機能が追加されました）。さらに、顧客はアプリケーションのパフォーマンスやUIに満足していませんでした。
ケーススタディの後のケーススタディは、書き直しが悪い考えであることを示しています。（kogusへの帽子の先端）
.NETに移行する必要がある場合（ええ、あなたは決定を下しませんでした。情報が少ない人が決定しました）、Delphifor.NETまたはRemObjectsOxygeneを使用することをお勧めします。後者はVisualStudioプラグインです。しかし、RemObjectsOxygeneのチーフソフトウェアアーキテクトであるmarchofmanでさえ、完全に機能するアプリケーションを.NETに移行するのは「理由だけで」悪い考えだと言っています。
Visual Studioアドインでもあり、今年後半にリリースされる予定のDelphiPrismを待つことができれば。
断片的な変換とは、Delphi のネイティブ コードを COM を使用するように変更して、.NET 側が Delphi と共存できるようにすることを意味します (または、他のテクノロジを使用する可能性があります - 言うのは難しいです)。
可能であれば、最初にアプリを Delphi.NET に変換する方が簡単かもしれません。そうすれば、少なくとも .NET ビットはもう少し簡単に通信できるようになります。
ちょっとした考え。
RemObjectsのHydraをご覧になることをお勧めします。基本的にcomインターフェースをラップし、Delphiと.Netアプリケーション間のインターフェースのためのオブザーバーパターンを提供します。Delphiアプリ内のパネルに.Netフォームを表示させることができます。これにより、機能を.Netに移行するときに、Delphiコードを少しずつ置き換えることができる優れた移行パスが提供されます。
CodeGear/Borland ツールから離れると、基本的に Delphi .NET ベースのソリューションがなくなり、アプリケーションを完全に書き直す必要がなくなります。
以下の私の回答があなたの決定に役立つことを願っています。
経験から（人々のチームで Delphi アプリケーションを書き直した）、以下の 2 つの選択肢のいずれかに要約されます。
ただし、最初に警告します。少なくとも、現在の Delphi アプリケーションを作成するのにかかった総開発作業が必要になります。
私たちの場合、古い Delphi アプリケーション (実際には Kylix でした) はさまざまな理由でサポートが終了したため、この取り組みは正当化されました。私たちの書き直しは 2 つの部分で構成されていました。追加機能を制限して書き直し、その後に多くの追加機能を追加しました (最初の部分の設計では、2 番目の部分がすでに考慮されていました)。
選択に戻る:
1- Visual Studio の C# または VB.NET での完全な書き直し
2- RemObjecs の Oxygene (Delphi 構文と非常によく似た構文を持つ Visual Studio プラグイン) を使用して、既存の Delphi ビジネス レイヤ コードを部分的に再利用します。CodeGear はすぐに (おそらく 2008 年末までに) Prism を提供し、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 フォーム) と Windows Presentation Foundation (別名 WPF) の間でバランスの取れた選択を行う必要があります。
1 対 1 で書き直す場合は、使い慣れた WinForms を使用することをお勧めします。UI を動作させるには、おそらくサードパーティのコンポーネントを使用する必要があります。DevExpress は、Delphi と Visual Studio に同様のコンポーネントがあるため、ここでは適切な選択です。
しかし、将来の見栄えを良くしたい場合は、WPF を検討することをお勧めします。ここでは、慣れ親しんだものとは大きく異なるため、WinForms よりも学習曲線が急になることに備えてください。
Delphi を使い続けることにした場合は、Web 用の VCL (別名 IntraWeb) と Delphi 2009 (6 年前に Delphi 7 が発表されて以来、Delphi の世界では多くの変化がありました) を検討することをお勧めします。
あなたの選択を頑張ってください！
--jeroen
John Brant、Don Roberts らによる 150 万行の Delphi プロジェクトの C# への変換の成功に関する科学的報告があります。彼は Delphi パーサー、C# ジェネレーター、および AST に関する多くの変換ルールを作成しました。一連のルールを徐々に拡張し、毎日のビルド、多くの単体テスト、難しい Delphi の部分の書き直しを行うことで、Delphi と C# の深い知識を持つ元の開発者を含む 4 人のチームで、 18か月でソフトウェア。John Brant と Don Roberts は、リファクタリング ブラウザと SmaCC コンパイラ構築キットの最初の開発者であるため、それほど速く作業を進めることはまずありません。
これはかなりの投資でしたが、「元の開発と同じ規模」にはなりません。著者は、Jeroen が指摘したように、特に新しい要件が考慮されている場合、ツールを使用せずに、または単発ツールを使用して簡単に書き直すと、その結果になる可能性が非常に高いと述べています。
作成者は、別のプロジェクトで同じプラットフォームにとどまりながら大規模なリファクタリングを行い、永続化インフラストラクチャを完全に置き換えました。これは、古い (BDE?) ベースのプロジェクトに関連する可能性があります。
私にとっての質問は次のとおりです。どの言語を使用しますか? VB.Net ではなく C# を希望します。(このユースケースのすべてのぎこちない政治により、これは決して明確ではありません。)
次に耳にすることは、これを行うのに役立つコンバーターが世の中にあるということです。そのようなコンバータ（Delphi 7 から C# へ）の評価を行ったところ、非常に優れていました。残念だった。
妥協案を提案してもいいですか？Delphi Prismはどうですか？VS2008のDelphiです。確かに、Delphi と Codegear はまだありますが、VS もあります (会社が期待しているように)。
ピースごとのアプローチが可能かどうかを本当に判断できるのはあなただけです。たとえば、アプリケーションが簡単に分割されたり、すべてのフォームがすべてのビジネス ロジックと強く結合しすぎたりする可能性があります。技術的には可能ですが、すべてはコード ベースが実際にどのように構成されているかによって異なります。