Visual Studio 2005 でのコンパイル時間が非常に遅い

https://stackoverflow.com/questions/55517

09-06-2019
|

質問

コンパイル時間が非常に遅くなり、デュアルコア 2GHz、2G Ram マシンでは 20 分以上かかる場合があります。

その多くは、70 を超えるプロジェクトにまで成長したソリューションのサイズと、大量のファイルがある場合にそれ自体がボトルネックとなる VSS によるものです。(残念ながら、VSS を交換することはオプションではないため、これを VSS bash に落としたくないです)

私たちはプロジェクトの統合を検討しています。また、アプリケーションの各要素の関心事の分離を強化し、コンパイル時間を短縮するために、複数のソリューションを用意することも検討しています。物事を同期させようとすると、これが DLL 地獄になるのは目に見えています。

他のチームがこのスケーリングの問題にどのように対処したか、コードベースがクリティカルマスに達し、ステータスバーがコンパイルメッセージを表示するのを見て半日を無駄にしている場合はどうするかを知りたいと思っています。

アップデートこれが C# ソリューションであることを忘れていました。C++ に関するすべての提案に感謝しますが、ヘッダーについて心配しなければならなくなってから数年が経ちました。

編集：

これまでに役に立った素晴らしい提案 (以下に他に素晴らしい提案がないと言っているのではなく、何が役に立ったかというだけです)

新しい 3 GHz ラップトップ - 管理者に不満を言うと、失われた使用率が驚異的に機能します
コンパイル中にウイルス対策機能を無効にする
コンパイル中に VSS (実際にはネットワーク) から「切断」します - VS-VSS 統合を完全に削除して、VSS UI の使用に固執する可能性があります

まだコンパイルを完全に実行することはできませんが、あらゆる部分が役に立ちます。

オリオン氏は、ジェネリック医薬品にも影響がある可能性があるとコメントで述べました。私のテストによると、パフォーマンスの低下は最小限に抑えられているようですが、確実になるほどではありません。ディスクの動作によりコンパイル時間が一定しない可能性があります。時間の制限により、私のテストにはライブシステムで表示されるほど多くのジェネリックやコードが含まれていなかったので、それが蓄積される可能性があります。コンパイル時のパフォーマンスのためだけに、使用されるべき場所でジェネリックを使用することを避けるつもりはありません

回避策

私たちは、新しいソリューションでアプリケーションの新しい領域を構築し、必要に応じて最新の DLL をインポートし、満足できる場合にはそれらをより大きなソリューションに統合するという実践をテストしています。

また、作業が必要な領域だけをカプセル化する一時的なソリューションを作成し、コードを再統合した後にそれらを破棄することで、既存のコードに対して同じことを行うこともできます。このコードを再統合するのにかかる時間と、開発中にリップヴァンウィンクルのような迅速な再コンパイルを経験しないことで得られる時間とを比較検討する必要があります。

解決

Chromium.org チームは、次のいくつかのオプションをリストしました。ビルドを加速する (この時点ではページの半分ほど):

高速化の降順に:

Microsoft ホットフィックスをインストールする 935225.

Microsoft ホットフィックスをインストールする 947315.

真のマルチコアプロセッサを使用してください。インテル Core Duo 2。Pentium 4 HT ではありません)。

3 つの並列ビルドを使用します。Visual Studio 2005 では、次のオプションがあります。 ツール > オプション...> プロジェクトとソリューション > ビルドと実行 > 並行プロジェクトビルドの最大数.

.ilk、.pdb、.cc、.h ファイルに対するウイルス対策ソフトウェアを無効にし、次のファイルのみをウイルスチェックします。 修正する. 。ソースが存在するディレクトリのスキャンを無効にします。愚かなことはしないでください。

Chromium コードを 2 番目のハードドライブに保存してビルドします。ビルドを実際に高速化するわけではありませんが、少なくとも gclient 同期またはビルドを実行するときにコンピューターの応答性は維持されます。

ハードドライブを定期的にデフラグしてください。

仮想メモリを無効にします。

他のヒント

1 つのソリューションに 100 近くのプロジェクトがあり、開発ビルド時間はわずか数秒です :)

ローカル開発ビルド用に、変更される Visual Studio アドインを作成しました。 Project references に DLL references 不要なプロジェクトをアンロードします (もちろん、元に戻すオプションもあります)。

ソリューション全体を構築する一度
現在作業していないプロジェクトをアンロードし、すべてのプロジェクト参照を DLL 参照に変更します。
チェックインする前に、すべての参照を DLL からプロジェクト参照に戻します。

一度に少数のプロジェクトだけを作業している場合、ビルドにかかる時間はわずか数秒になりました。追加のプロジェクトはデバッグ DLL にリンクされているため、デバッグすることもできます。このツールで多数の変更を行うには通常 10 ～ 30 秒かかりますが、それほど頻繁に変更する必要はありません。

2015 年 5 月の更新

私が（以下のコメントで）交わした取り決めは、プラグインをオープンソースにリリースするというものでした。もし十分な関心が得られます。4 年後、このプロジェクトは 44 票しか得られていないため (Visual Studio には現在 2 つの後続バージョンがある)、現在は優先度の低いプロジェクトです。

21 プロジェクトと 1/200 万 LOC のソリューションでも同様の問題が発生しました。最大の違いは、ハードドライブが高速になったことです。パフォーマンスモニターからの「平均」ディスクキュー」はラップトップ上で大幅に増加し、ハードドライブがボトルネックであることを示していました。

総再構築時間のデータは次のとおりです...

1) ラップトップ、Core 2 Duo 2GHz、5400 RPM ドライブ (キャッシュは不明。標準の Dell inspiron でした)。

再構築時間 = 112 秒。

2) デスクトップ (標準問題)、Core 2 Duo 2.3Ghz、シングル 7200RPM ドライブ 8MB キャッシュ。

再構築時間 = 72 秒。

3) デスクトップ Core 2 Duo 3Ghz、シングル 10000 RPM WD Raptor

再構築時間 = 39 秒。

10,000 RPM ドライブを軽視することはできません。ビルドが大幅に速くなったほか、ドキュメントの表示やファイルエクスプローラーの使用など、その他すべての動作が著しく速くなりました。コードのビルドと実行のサイクルが短縮され、生産性が大幅に向上しました。

企業が開発者の給与に費やしている金額を考えると、 非常識な 受付係が使っているのと同じ PC を彼らに装備させることで、どれだけ無駄にできるかということです。

C# .NET ビルドの場合は、次を使用できます。 .NET デーモン. 。これは、Visual Studio のビルドプロセスを引き継いで高速化する製品です。

これは、ユーザーが行った変更を分析することによって行われ、実際に変更したプロジェクトと、ユーザーが加えた変更に実際に依存した他のプロジェクトのみをビルドします。つまり、内部コードのみを変更する場合、ビルドする必要があるプロジェクトは 1 つだけです。

ウイルス対策ソフトをオフにします。コンパイル時間に時間がかかります。

分散コンパイルを使用します。ゾレアックス IncrediBuild コンパイル時間を数分に短縮できます。

私はこれを、コンパイルに通常 5 ～ 6 時間かかる巨大な C/C++ ソリューションで使用しました。IncrediBuild により、この時間を 15 分に短縮できました。

Visual Studio のコンパイル時間を数秒に短縮する手順

残念ながら、Visual Studio は、アセンブリのインターフェイスの変更と、重要でないコード本体の変更を区別できるほど賢くありません。この事実が、大規模に絡み合ったソリューションと組み合わされると、コードを 1 行変更するたびに、ほぼ毎回、望ましくない「フルビルド」の完全な嵐を引き起こす可能性があります。

これを克服する戦略は、自動参照ツリー構築を無効にすることです。これを行うには、「構成マネージャー」(ビルド/構成マネージャー...次にアクティブソリューション構成ドロップダウンで「新規」を選択) を使用して、デバッグ構成からコピーする「ManualCompile」という新しいビルド構成を作成します。「新しいプロジェクト構成を作成する」チェックボックスをオンにしないでください。この新しいビルド構成では、すべてのプロジェクトのチェックを外して、どのプロジェクトも自動的にビルドされないようにします。「閉じる」をクリックしてこの構成を保存します。この新しいビルド構成はソリューションファイルに追加されます。

IDE 画面の上部にあるビルド構成ドロップダウン (通常は「デバッグ」または「リリース」のいずれかが表示されます) を使用して、あるビルド構成から別のビルド構成に切り替えることができます。事実上、この新しい ManualCompile ビルド構成では、次のビルドメニューオプションが無効になります。「ソリューションのビルド」または「ソリューションの再構築」。したがって、ManualCompile モードの場合は、変更している各プロジェクトを手動でビルドする必要があります。これを行うには、ソリューションエクスプローラーで影響を受ける各プロジェクトを右クリックし、[ビルド] または [再ビルド] を選択します。全体的なコンパイル時間はわずか数秒になることがわかります。

この戦略が機能するには、AssemblyInfo ファイルと GlobalAssemblyInfo ファイルにある VersionNumber が開発者のマシン上で静的のまま (もちろんリリースビルド中は静的) であり、DLL に署名しない必要があります。

この ManualCompile 戦略を使用する潜在的なリスクは、開発者が必要なプロジェクトのコンパイルを忘れる可能性があり、デバッガを起動すると予期しない結果 (デバッガを接続できない、ファイルが見つからないなど) が発生する可能性があることです。これを回避するには、大規模なコーディング作業をコンパイルする場合は「デバッグ」ビルド構成を使用し、単体テスト中または限定された範囲の迅速な変更を行う場合にのみ ManualCompile ビルド構成を使用することがおそらく最善です。

これが C または C++ で、プリコンパイル済みヘッダーを使用していない場合は、プリコンパイル済みヘッダーを使用する必要があります。

メインソリューションには 80 以上のプロジェクトがあり、開発者が作業しているマシンの種類に応じて、ビルドに約 4 ～ 6 分かかりました。私たちはそれは長すぎると考えました。テストのたびに、実際に FTE が無駄になります。

では、ビルド時間を短縮するにはどうすればよいでしょうか?すでにご存知かと思いますが、ビルド時間に大きな影響を与えるのはプロジェクトの数です。もちろん、すべてのプロジェクトを削除して、すべてのソースファイルを 1 つに単純に放り込むつもりはありませんでした。しかし、それでも組み合わせることができるプロジェクトがいくつかありました。ソリューション内のすべての「リポジトリプロジェクト」には独自の単体テストプロジェクトがあるため、すべての単体テストプロジェクトを 1 つのグローバル単体テストプロジェクトに単純に結合しました。これにより、プロジェクトの数が約 12 プロジェクトに削減され、ソリューション全体の構築にかかる時間をなんとか 40% 節約できました。

ただし、別の解決策を検討しています。

新しいプロジェクトで新しい (2 番目の) ソリューションをセットアップしようとしたこともありますか?この 2 番目のソリューションは、ソリューションフォルダーを使用してすべてのファイルを組み込むだけです。たった 1 つのプロジェクトによる新しいソリューションのビルド時間を見て驚くかもしれないからです。

ただし、2 つの異なるソリューションを使用するには、慎重な考慮が必要です。開発者は実際には 2 番目のソリューションに取り組み、最初のソリューションを完全に無視する傾向があるかもしれません。70 を超えるプロジェクトを含む最初のソリューションはオブジェクト階層を処理するソリューションになるため、これがビルドサーバーがすべての単体テストを実行するソリューションになるはずです。したがって、継続的統合のサーバーは最初のプロジェクト/ソリューションである必要があります。オブジェクト階層を維持する必要があります。

1 つのプロジェクトだけを使用する 2 番目のソリューション (これにより、ビルドがはるかに速くなります) は、すべての開発者によってテストとデバッグが行われるプロジェクトになります。ただし、ビルドサーバーを見てそれらに注意する必要があります。何かが壊れた場合は、それを修正する必要があります。

参照がプロジェクト参照であり、ライブラリ出力ディレクトリ内の DLL を直接参照していないことを確認してください。

また、絶対に必要な場合 (マスター EXE プロジェクト) を除き、これらをローカルにコピーしないように設定します。

私はこの回答を最初にここに投稿しました:https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473このページには他にも多くの役立つヒントが記載されています。

Visual Studio 2008 を使用している場合は、/MP フラグを使用してコンパイルし、単一のプロジェクトを並行してビルドできます。これも Visual Studio 2005 の文書化されていない機能であると読んだことがありますが、自分では試したことはありません。

/M フラグを使用して複数のプロジェクトを並行してビルドできますが、これは通常、マシン上で使用可能なコアの数にすでに設定されていますが、これは VC++ にのみ適用されると思います。

この質問は何年も前のものですが、このトピックは今日でも興味深いものです。最近同じ問題に悩まされましたが、ビルドパフォーマンスを最も向上させた 2 つのことは、(1) コンパイルに専用 (そして高速) ディスクを使用すること、(2) すべてのプロジェクトで同じ出力フォルダーを使用すること、およびプロジェクトで CopyLocal を False に設定することです。参考文献。

いくつかの追加リソース:

いくつかの分析ツール:

ツール - >オプション - > VC ++プロジェクト設定 - >ビルドタイミング=はい、すべてのVCProjの時間を作成します。

追加 /Bt コンパイラコマンドラインに切り替えて、各 CPP ファイルにどれだけの時間がかかったかを確認します

使用 /showIncludes ネストされたインクルード (他のヘッダーファイルをインクルードするヘッダーファイル) をキャッチし、前方宣言を使用することで大量の IO を節約できるファイルを確認します。

これにより、依存関係やパフォーマンスの負荷を排除し、コンパイラのパフォーマンスを最適化することができます。

より高速なハードドライブに投資するためにお金を費やす前に、プロジェクト全体を RAM ディスク上に構築してみてください (RAM に余裕があることが前提です)。ネット上では、さまざまな無料の RAM ディスクドライバーが見つかります。SSD を含め、RAM ディスクよりも高速な物理ドライブは見つかりません。

私の場合、Incredibuild を使用して 7200 RPM SATA ドライブ上の 6 コア i7 でビルドするのに 5 分かかったプロジェクトは、RAM ディスクを使用することでわずか約 15 秒短縮されました。永続ストレージに再コピーする必要性と作業内容が失われる可能性を考慮すると、15 秒では RAM ディスクを使用する動機としては十分ではなく、高 RPM ドライブや SSD ドライブに数百ドルを費やす動機もおそらくあまりありません。

ゲインが小さいということは、ビルドが CPU バウンドであったこと、または Windows ファイルキャッシュがかなり効果的であったことを示している可能性がありますが、どちらのテストもファイルがキャッシュされていない状態から行われたため、私は CPU バウンドのコンパイルに大きく傾いています。

コンパイルしている実際のコードに応じて、使用できる距離は異なる場合がありますので、ためらわずにテストしてください。

完全なビルドを行った後のビルドディレクトリのサイズはどれくらいですか?デフォルトのセットアップを使用する場合、ビルドするすべてのアセンブリは、その依存関係のすべての DLL とその依存関係の依存関係などをコピーします。bin ディレクトリにコピーします。私の前職で約 40 のプロジェクトのソリューションを扱っていたとき、同僚は、ビルドプロセスで最もコストがかかる部分はこれらのアセンブリを何度もコピーすることであり、1 つのビルドで同じ DLL の何ギガバイトものコピーが生成される可能性があることを発見しました。もう一度。

以下は、NDepend の著者である Patrick Smacchia からの、個別のアセンブリであるべきものとすべきでないものについての有益なアドバイスです。

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

これを回避するには基本的に 2 つの方法がありますが、どちらにも欠点があります。1 つは、明らかに多大な労力を要するアセンブリの数を減らすことです。もう 1 つは、すべての bin フォルダーが統合され、プロジェクトが依存関係の DLL をコピーしないようにビルドディレクトリを再構成することです。これらはすべて同じディレクトリにすでに存在するため、コピーする必要はありません。これにより、ビルド中に作成およびコピーされるファイルの数が大幅に減少しますが、セットアップが難しく、パッケージ化に特定の実行可能ファイルに必要な DLL だけを取り出すのが困難になる場合があります。

おそらく、いくつかの共通関数を使用していくつかのライブラリを作成すると、同じソースが複数のプロジェクトで何度もコンパイルされることがなくなります。

異なるバージョンの DLL が混在することが心配な場合は、静的ライブラリを使用してください。

VSS 統合をオフにします。これを使用する選択肢はないかもしれませんが、DLL は常に「誤って」名前が変更されてしまいます...

そして、プリコンパイルされたヘッダー設定を必ず確認してください。ブルース・ドーソンのガイドは少し古いですが、それでも とても 良いです - チェックしてみてください: http://www.cygnus-software.com/papers/precompiledheaders.html

120 以上の exe、lib、dll があり、ビルドにかなりの時間がかかるプロジェクトがあります。1 つのマスターバッチファイルから make ファイルを呼び出すバッチファイルのツリーを使用します。私は過去にインクリメンタル（または気まぐれな）ヘッダーによる奇妙な問題に遭遇したことがあったので、今はそれらを避けています。私は完全なビルドを行うことはあまりなく、通常は 1 時間の散歩に行く間、一日の終わりまでそのままにしておきます (つまり、30 分程度かかるとしか推測できません)。したがって、これが作業やテストに使用できない理由は理解できます。

作業とテストのために、アプリ (またはモジュールまたはライブラリ) ごとに別のバッチファイルのセットがあり、これにはすべてのデバッグ設定も含まれていますが、これらは依然として同じ make ファイルを呼び出します。時々 DEBUG のオンとオフを切り替えて、ビルドまたはメイクを決定したり、モジュールが依存する可能性のあるライブラリもビルドするかどうかなどを決定したりすることがあります。

また、バッチファイルは、完成した結果を (または複数の) テストフォルダーにコピーします。設定に応じて、これは (30 分ではなく) 数秒から 1 分で完了します。

私は .rc ファイルなどを制御したいので、別の IDE (Zeus) を使用しました。MS コンパイラを使用しているにもかかわらず、実際にはコマンドラインからコンパイルすることを好みます。

興味のある方は、このバッチファイルの例を投稿していただければ幸いです。

ソースディレクトリ (ソースを検索可能にしたい場合は特に obj ディレクトリ) でファイルシステムのインデックス作成を無効にします。

これが Web アプリの場合、シナリオに応じてバッチビルドを true に設定すると役立つ場合があります。

<compilation defaultLanguage="c#" debug="true" batch="true" >

概要は次のとおりです。 http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

また、循環プロジェクト参照を確認することもできます。かつて私にとってそれは問題でした。

あれは：

プロジェクト A がプロジェクト B を参照する

プロジェクト B はプロジェクト C を参照します

プロジェクト C はプロジェクト A を参照します

Xoreax IB のより安価な代替手段の 1 つは、私が uber-file ビルドと呼んでいるものの使用です。これは基本的に次の .cpp ファイルです。

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

次に、個々のモジュールの代わりに uber ユニットをコンパイルします。コンパイル時間は 10 ～ 15 分から 1 ～ 2 分に短縮されました。uber ファイルあたりの #include の数がどれだけ意味があるのかを試してみる必要があるかもしれません。プロジェクトによって異なります。等10 個のファイルを含める場合もあれば、20 個のファイルを含める場合もあります。

コストを支払うので、次の点に注意してください。

ファイルを右クリックして「コンパイル...」と言うわけにはいきません。ビルドから個々の cpp ファイルを除外し、uber cpp ファイルのみを含める必要があるからです。
静的グローバル変数の競合に注意する必要があります。
新しいモジュールを追加するときは、uber ファイルを最新の状態に保つ必要があります

それはちょっと面倒ですが、新しいモジュールに関してほとんど静的なプロジェクトの場合、最初は苦労する価値があるかもしれません。場合によっては、この方法が IB を上回ることも見たことがあります。

C++ プロジェクトの場合は、プリコンパイルされたヘッダーを使用する必要があります。これにより、コンパイル時間に大きな違いが生じます。cl.exe が実際に何をしているのかはわかりませんが (プリコンパイルされたヘッダーを使用していないため)、探しているようです。 たくさん 最終的に正しい場所に移動する前に、すべての間違った場所に STL ヘッダーが存在します。これにより、コンパイルされるすべての .cpp ファイルに秒単位の時間が追加されます。これが cl.exe のバグなのか、それとも VS2008 におけるある種の STL の問題なのかはわかりません。

構築しているマシンは最適に構成されていますか?

当社最大の C++ エンタープライズスケール製品のビルド時間が、 19時間 に 16分 適切な SATA フィルタードライバーがインストールされていることを確認します。

微妙。

Visual Studio 2005 には文書化されていない /MP スイッチがあります。「/MP」スイッチを参照してください。 http://lahsiv.net/blog/?p=40, これにより、プロジェクトベースではなくファイルベースでの並列コンパイルが可能になります。これにより、最後のプロジェクトのコンパイル、または 1 つのプロジェクトをコンパイルする場合のコンパイルが高速化される可能性があります。

CPU を選択する場合:L1 キャッシュサイズはコンパイル時間に大きな影響を与えるようです。また、通常は、遅いコアを 4 つ使用するよりも、高速なコアを 2 つ使用する方が優れています。Visual Studio は、追加のコアをあまり効果的に使用しません。(これは C++ コンパイラーでの経験に基づいていますが、おそらく C# コンパイラーにも当てはまります。)

また、VS2008 にも問題があると確信しています。3G Ramを搭載したデュアルコアIntelラップトップで、ウイルス対策機能をオフにして実行しています。ソリューションのコンパイルは非常にスムーズに行われることがよくありますが、デバッグを行っている場合、後続の再コンパイルでは速度が大幅に低下することがよくあります。メインディスクの継続的なライトから、ディスク I/O ボトルネックがあることは明らかです (それは聞こえます)。ビルドをキャンセルしてVSをシャットダウンすると、ディスクアクティビティが停止します。VS を再起動し、ソリューションをリロードしてから再構築すると、はるかに高速になります。次回はユニット

私の考えでは、これはメモリページングの問題です。VSはメモリが不足し、O/Sはスペースを確保しようとしてページスワッピングを開始しますが、VSはページスワップが提供できる以上のものを要求しているため、速度がクロールまで低下します。他に説明が思いつきません。

VS は間違いなく RAD ツールではありませんね。

ひょっとしてあなたの会社では PKI/暗号化ソリューションに Entrust を使用しているのでしょうか?結局のところ、C# で構築されたかなり大規模な Web サイトのビルドパフォーマンスは最悪で、Rebuild-All に 7 分以上かかりました。

私のマシンは 16GB RAM と 512GB SSD を搭載した i7-3770 なので、パフォーマンスはそれほど悪くないはずです。同じコードベースを構築する古いセカンダリマシンでは、ビルド時間が非常に速くなっていることに気付きました。そこで、両方のマシンで ProcMon を起動し、ビルドのプロファイリングを行い、結果を比較しました。

なんと、このパフォーマンスの遅いマシンには 1 つの違いがありました。それは、スタックトレース内の Entrust.dll への参照です。この新しく取得した情報を使用して StackOverflow を検索し続けたところ、次のものが見つかりました。 MSBUILD (VS2010) 一部のマシンでは非常に遅い. 。受け入れられた回答によると、問題は、Entrust ハンドラーがネイティブの Microsoft ハンドラーではなく .NET 証明書チェックを処理していたという事実にあります。また、Entrust v10 では、Entrust 9 で発生しているこの問題が解決されることも示唆されています。

現在はアンインストールしているので、ビルド時間が大幅に短縮されました 24秒. 。YYMV は、現在構築中のプロジェクトの数を示していますが、お問い合わせのスケーリングの問題に直接対処していない可能性があります。修正を提供できる場合は、この応答に編集を投稿します それなし ソフトウェアをアンインストールする必要があります。

VS2008に問題があるのは確かです。なぜなら、私がやったことは、VS2005 で作成されたプロジェクトをアップグレードするために VS2008 をインストールしたことだけだからです。私のソリューションには 2 つのプロジェクトしかありません。大きくないですよ。VS2005でのコンパイル:VS2008での30秒の編集：5分

これまでに役に立った素晴らしい提案 (以下に他に素晴らしい提案がないというわけではありません。問題がある場合は、何が役に立ったかを読んでいただくことをお勧めします)

新しい 3 GHz ラップトップ - 管理者に不満を言うと、失われた使用率が驚異的に機能します
コンパイル中にウイルス対策機能を無効にする
コンパイル中に VSS (実際にはネットワーク) から「切断」します - VS-VSS 統合を完全に削除して、VSS UI の使用に固執する可能性があります

まだコンパイルを完全に実行することはできませんが、あらゆる部分が役に立ちます。

また、新しいソリューションでアプリケーションの新しい領域を構築し、必要に応じて最新の DLL をインポートし、満足できる場合はそれらをより大きなソリューションに統合するという実践もテストしています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow