1

そのため、デバッグモードでビルドするときに、アセンブリ名に「d」拡張子を追加しています。C＃でこれを行う標準的な方法は、.csprojファイルを編集して、次のように入力することです。

<PropertyGroup>
  <AssemblyName Condition="'$(Configuration)' == 'V90 Debug'">$(AssemblyName)d</AssemblyName>
</PropertyGroup>

これには望ましい効果がありますが、darnプロジェクトは常に出力.dllを再構築し、それに依存する他のプロジェクトが再リンクするなどの原因になります。この変更がなければ、このような問題は発生しません。

これまでのところ、プロジェクト出力の冗長性を高めることは役に立ちませんでした。

編集：追加の重要な詳細は、構成に「V90リリース」、「V90デバッグ」、「V100リリース」などの名前を使用しているため、VisualStudioランタイムのさまざまなバージョンをターゲットにできることです。標準の構成名でテストアプリを作成しましたが、その場合は問題が発生しないことがわかりました。

4

1 に答える 1

4

C /C++開発で古い標準を使用しています。マネージコードとの大きな違いは、リンカーがないことです。以前は、デバッグビルドでライブラリの「d」バージョン、リリースビルドでライブラリの非dバージョンを使用するようにリンカーを構成していました。このメカニズムは.NETには完全に存在せず、ライブラリ内のコードは実行時に動的にリンクされます。ビルドごとに異なる名前を付けることは、実質的に大幅に少なくなります。

この古い戦略を追求する場合に遭遇する問題の1つは、プロジェクトの参照アセンブリで追加の問題が発生することです。異なる構成で異なる名前を使用する適切な方法はありません。依存アセンブリはプロジェクトの参照ノードに一覧表示されます。これは、構成に依存しないプロジェクトのプロパティです。Condition不可能ではありません。参照アセンブリの名前を変更するには、さらに多くのハックが必要になります。ビルドの依存関係のチェックもこれによって影響を受ける可能性があります。

これは実際には必要ありません。アセンブリのデバッグビルドとリリースビルドは同じメタデータを持ちます。ただし、これをスキップすると、実行時に問題が発生します。CLRは、間違ったアセンブリ名を使用するように指示されます。これをハッキングするには、サブディレクトリ内のアセンブリを非表示にし、AppDomain.AssemblyResolveイベントを使用して正しいアセンブリをロードすることで技術的に可能です。アセンブリの名前を変更してこのディレクトリにコピーするには、ビルド後のイベントが必要です。これらのアセンブリが他のアセンブリに依存している場合、これはすべて急いで醜くなります。

簡単に言えば、以前の標準はマネージコードには適していません。

于 2011-08-02T21:12:53.300 に答える