問題タブ [legacy]

私の会社には、VB6 で記述された大量のレガシーアプリケーションがあります。

VB6 アプリケーションから .NET (具体的には 3.5) への移行を進めています。

VB6 から .NET に移行するための最善の戦略は何ですか?

注：以下の更新は「プロジェクト管理」に移動する必要があり、主な質問とは関係ありません。

[更新] : これまでのフィードバックに感謝します。
ポップアップする質問が増えました。

1. 新しいアプリケーションを開発する開発者をどのように割り当てますか?
2. レガシー アプリを新しいアプリに変換する特別な 1 回限りのアップグレード部門が必要ですか? それとも、すべての開発者が変換プロセスに参加する必要がありますか?
3. 上級開発者のみが変換に参加する必要がありますか? ジュニア開発者？または混合？

この問題について考えれば考えるほど、より多くの疑問が浮かび上がってくるようです。

存在しない古いアプリケーションを使用している顧客がいます。彼はアプリケーションを作成した会社に問題があり、彼らは彼のデータベースのパスワードを公開しません。彼は、アプリケーションを「レンタル」しているようなものであり、何も開示する権利がないという契約書に署名した (当時) ことに気付きました。この顧客は、その会社で同じ問題を抱えているのは自分だけではないことに気付きました。彼は歯科医であり、同じ古いアプリケーションを使用している他の歯科医が、新しいソフトウェアを購入しようとして患者を新しいシステムに移行しようとしたときに、同じ問題を経験しました。

どちらの場合でも、彼は自分の小さな firebird データベースを開きたいので、少なくとも一部のデータを SQL Server に抽出できます。デフォルトの「マスターキー」（実際には、8文字の制限により「マスターキー」です）を試してみましたが、役に立ちませんでした。

今、私は彼が合法的に会社に彼の情報を公開するよう強制しようとすることができることを知っていますが、私はそれを手短にやりたいと思っています. 古いFirebirdパスワードをブルートフォース/クラックできるアプリを知っている人はいますか?

ありがとう。

編集: レガシー ソフトウェアは「STOMA-W」です。インターネット上でも見つけることができません。彼らはスペインのアストゥリアスにあります。

なんらかのひねくれた理由で、Python 1.0 を試してみたいと思っています。コンパイルするにはどうすればよいでしょうか。それとも、現在のコンパイラで問題なくコンパイルできる以前のバージョンは何ですか?

私は Mac OS X 10.5 を使用していますが、(言語がどのように変化したかについての) 単なる好奇心のためであるため、Linux 仮想マシンでのコンパイルも可能です..

FxCopをレガシーコードに導入した経験のある人はいますか？誰かがルールに違反するコードを導入した場合、ビルドを失敗させたいと思います。しかし、レガシーコードには9000を超える違反があるため、当面はこれは不可能です。

私が知っているエラーを抑制する唯一の方法はSuppressMessage属性を使用することですが、これはメソッドとGeneratedCodeAttributeでのみ機能します。この最後のものは、クラスと名前空間に使用できますが（正しく思い出せば）、生成されていないコードには使用しないでください（ここを参照）。

現在、違反を削除するために毎日時間がかかりますが、ビルドが失敗しないため、新しい違反が導入され続けています。

何か案は？

整数値を varchar 列に保存しているレガシーデータベースを使用しています。この列を Int32 プロパティにマップする必要があり、データベース列のデータが数値または NULL の場合にうまく機能します。

ただし、列に null ではなく空の文字列が含まれている場合、問題が発生します。nhibernate は、整数に変換できないというエラーをスローします。

例外が発生したすべての値をデフォルト値 (この場合はゼロ) に自動的に変換するようにクラス マッピングを構成することはできますか?

C で記述された大規模なマルチプラットフォーム アプリケーションがあります (C++ の量は少ないですが増加しています)。これは、大規模な C/C++ アプリケーションに期待される多くの機能を備えて、何年にもわたって進化してきました。

• #ifdef地獄
• テスト可能なコードの分離を困難にする大きなファイル
• 複雑すぎて簡単にテストできない関数

このコードは組み込みデバイスを対象としているため、実際の対象で実行するには多くのオーバーヘッドがかかります。そのため、ローカル システム上で、短いサイクルでより多くの開発とテストを行いたいと考えています。ただし、「システムの .c ファイルにコピー/貼り付け、バグを修正し、コピー/貼り付けを戻す」という従来の戦略は避けたいと考えています。開発者がわざわざそれを行うのであれば、後で同じテストを再作成し、自動化された方法で実行できるようにしたいと考えています。

ここに問題があります。コードをリファクタリングしてよりモジュール化するには、コードをよりテストしやすくする必要があります。しかし、自動化された単体テストを導入するには、よりモジュール化する必要があります。

1 つの問題は、ファイルが非常に大きいため、適切な単体テストを作成するためにスタブ化する必要がある同じファイル内の関数を呼び出す関数がファイル内にある可能性があることです。私たちのコードがよりモジュール化されるにつれて、これはそれほど問題ではないように思えますが、それはまだ先の話です。

私たちが考えたことの 1 つは、「テスト可能であることがわかっている」ソース コードにコメントをタグ付けすることでした。次に、テスト可能なコードのソース ファイルをスキャンするスクリプトを作成し、それを別のファイルにコンパイルして、単体テストにリンクします。欠陥を修正し、機能を追加するにつれて、ゆっくりと単体テストを導入することができます。

ただし、このスキームを (必要なすべてのスタブ関数と共に) 維持するのが面倒になり、開発者が単体テストの維持をやめるという懸念があります。したがって、別のアプローチは、すべてのコードのスタブを自動的に生成するツールを使用し、それとファイルをリンクすることです。(これを実行できる唯一のツールは、高価な商用製品です) しかし、このアプローチでは、外部呼び出しのみをスタブ化できるため、開始する前にすべてのコードをよりモジュール化する必要があるようです。

個人的には、開発者には外部の依存関係について考えてもらい、独自のスタブをインテリジェントに作成してもらいたいと考えています。しかし、10,000 行にも及ぶ恐ろしく大きくなりすぎたファイルのすべての依存関係をスタブ化するには、これは非常に困難な作業になる可能性があります。すべての外部依存関係のスタブを維持する必要があることを開発者に納得させるのは難しいかもしれませんが、それは正しい方法ですか? (私が聞いたもう 1 つの議論は、サブシステムのメンテナーがサブシステムのスタブを維持する必要があるというものです。しかし、開発者に独自のスタブを作成することを「強制」することが、より良い単体テストにつながるのではないでしょうか?)

もちろん、これ#ifdefsは問題に別の次元全体を追加します。

いくつかの C/C++ ベースの単体テスト フレームワークを見てきましたが、適切に見える多くのオプションがあります。しかし、「単体テストのないコードの毛玉」から「単体テスト可能なコード」への移行を容易にするものは見つかりませんでした。

それで、これを経験した他の人への私の質問は次のとおりです。

• 良い出発点は何ですか？私たちは正しい方向に進んでいますか、それとも明らかな何かが欠けていますか?
• 移行に役立つツールは何ですか? (現在の予算はほぼ「ゼロ」なので、できれば無料/オープン ソース)

ビルド環境は Linux/UNIX ベースであるため、Windows 専用のツールは使用できないことに注意してください。

私は、もともと MSDOS を対象としていたプログラムの、かなり古くて複雑なコードベースを継承しました。このプログラムのいくつかのセクションは、アセンブラー プログラムを作成した会社と製品にちなんで、「Phar Lap assembler」と呼ばれる x86 アセンブラーのあいまいな方言で書かれていることが判明しました。Google でかなり詳細な検索を行いましたが、元のアセンブラー プログラムも、それに関する情報やドキュメントも見つかりません。(Experts Exchange で、似たような質問をしている人々のかなり苛立たしいページをいくつか見つけましたが)。

つまり、基本的には、PharLap アセンブラー (386asm.exe) のコピーを見つけるか、方言に関する十分な情報を見つけて、より「標準的な」MASM のような方言に変換するまで、これをコンパイルすることはできません。 . それか、それを読んで理解するだけで筋肉をつけようとします。

または、これがどれも不可能な場合は、この問題について何らかの助けが必要であり、少なくともプログラムの 1 つのセクションをコンパイルできるようにする必要があります。

.c ファイルには、次のような構造体宣言があります。

次に、次のようなアセンブラがあります。これは、おそらく同じ型宣言を作成して、一部のアセンブラ コードで同じ型を使用できるようにしようとしています。

これは、次のような最後の行でエラーでコンパイルされます (watcom アセンブラー):

基本的に、これが言っているのは、この構造体のアセンブラー バージョンがこの構造体の C バージョンと一致しないということだと思います。アセンブラで dd の代わりに WORD と DWORD のさまざまな組み合わせを試しましたが、このささいなことを乗り越えることはできません。これら 2 つの宣言を完全に一致させる方法を見つけることができれば、pharlap に関する情報の必要性は減るでしょう。

また、この広大な質問に対してより良いタイトルを考えられる人がいれば、私は自由に考えます。

編集：わかりました、重要な情報をざっと見ただけでした。これはもともと Phar Lap アセンブラ (私は持っていません) 用に書かれたファイルで、watcom アセンバー (wasm) を使用してアセンブルしようとしています。この特定のエラーの問題は、Phar Lap では大文字と小文字が区別されるように見えるが、watcom では区別されないことが判明した。したがって、bhashctl は BhashCtl と同じものとして認識されます。義理の兄の助けを借りてこれを理解しました。大文字と小文字を区別しないことがその原因であるとは思いもしませんでした。

libc5 を使用する従来のリンカがありますが、いくつかの要因により、ソースではなくバイナリしかありません。はい、バージョン管理があれば現在の問題は解決できたはずです...現在、この問題はツール チェーンと製品ライン全体で使用されていますが、この特定の馬はとうの昔に姿を消しました。

このリンカは Linux カーネル 2.6.24 で動作しますが、2.6.25 (および 2.6.26) では失敗し、次のメッセージが表示されます。

対応するレガシー コンパイラにも同様の問題がありましたが、stackoverflow.com の回答と多くの調査により、コンパイラの問題は Linux カーネル 2.6.25 の「brk ランダム化」が原因であることが判明しました。その回避策は、sysctl 変数と環境変数を設定することです。

ただし、これはリンカには役立ちません。

「ldd」を使用して、リンカーにはより多くの共有ライブラリの依存関係があることがわかりました (コンパイラには libc.so.5 しかありませんでした):

そして、libg++.so.27 の libc5 バージョンをインストールする必要があるかもしれないことを読みました。それが最新の libg++.so.27 を上書きし、libc5 以外のアプリで問題を引き起こすかどうかわからないので、私はそれをするのをためらっています。

では、libg++.so.27 の libc5 バージョンを見つけてインストールするか、brk のランダム化を無効にするより良い方法があるか、またはリンカーの問題を引き起こしているカーネル 2.6.24 と 2.6.25 の間に別の違いがありますか?

編集

この検索の詳細と私の最終的な解決策については、こちらを参照してください。

多くのレガシー Web フォーム ページを含むプロジェクトに MVC を追加しています。これはうまくいきます。ただし、現在、MVC 用と Web フォーム用に別々のマスターページがあります。2 つのマスター ページは、基本的に同じ出力を生成します。私は本当にWebフォームを1つ殺し、すべてのページでMVCマスターページを使用してDRYのままにしたいと思っています。

両方を変更するのを忘れたとき、DRYではないことですでに数回噛まれました。

私は明白な方法を試し、MVC マスターページで Web フォーム コンテンツ ページの MasterPage 属性をポイントするだけでした。これにより、MVC マスターは MVC ビューでのみ機能するというエラーがスローされます。

これは、MVC プロジェクトと Web フォーム プロジェクトが混在する場合によくある問題のようです。私の MVC マスターは ViewData で何もしていないので、Web フォームがそれらを使用できない理由はわかりません。