5

同じ C# .NET プロジェクトの複数のバージョンをデプロイする必要があります。プロジェクトの出力は、ネイティブ アプリケーションで使用される COM 相互運用アセンブリです。私が抱えている問題は、このアセンブリのいくつかのバージョンを並べて展開する必要があることですが、何をしても異なるバージョンが作成されないようです。代わりに、バージョンは互いにオーバーライドします。

アセンブリの GUID の変更、アセンブリのバージョン番号の変更、アセンブリの厳密な名前キーの再生成、アセンブリのタイトルと説明の変更を試みました。バージョン管理のために、アセンブリ内の個々の型の GUID または名前を変更する必要はありません。

これらのバージョンが互いに上書きされないようにし、それらを並べて表示およびデプロイできるようにするにはどうすればよいですか?

前もって感謝します！

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;

namespace InteropTest
{
    [Guid("...")]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    public class Test
    {
        public Test()
        {
        }

        public string Version
        {
            get
            {
                return "1.0";
            }
        }
    }
}
4

2 に答える 2

6

バージョン管理のために、アセンブリ内の個々の型の GUID または名前を変更する必要はありません。

しかし、COM タイプが互いに干渉しないようにするために必要なことは、まさにそれです。[Guid] は、COM クラスが登録されている HKLM\Software\Classes\CLSID のレジストリ キーを選択するために使用されます。同じ Guid を持つ 2 つの異なるバージョンは、互いのキーを上書きします。DLL Hell としても知られています。パブリック インターフェイスを変更するには、新しい Guid を使用して、古い GUID を使用するクライアントが不正な動作を診断できないために停止しないようにする必要があります。非常に厳しい COM 要件。

[Guid] 属性を省略することは非常に可能です。CLR に任せて生成してください。これで、アセンブリ属性が役割を果たし始めます。guid 値は、アセンブリ名とバージョン、およびインターフェイスの一連のメソッドとその引数を含む洗練されたアルゴリズムによって自動生成されます。したがって、すべての変更が自動的に別の GUID を生成することを保証します。そして、予想どおり、必要に応じて、別の [AssemblyVersion] は別の [Guid] を生成します。

「サイドバイサイド」であなたが意味すると私が想定した別のアプローチは、アセンブリを登録せず、代わりにマニフェストに依存することです。クライアント プログラムに埋め込む必要があります。<clrClass>要素を使用して [ComVisible] クラスを宣言します。バージョン管理は、展開の詳細になります。MSDN のハウツーはこちらです。[ComVisible] アセンブリではなく、クライアントプログラムに埋め込む必要があることに注意してください。それが問題になりがちです。

于 2010-11-22T12:58:02.347 に答える
2

可能であれば、ネイティブ アプリケーションで相互運用機能アセンブリへの遅延バインディングを試してください。また、AutoDual を使用してインターフェイスを自動生成し、代わりに独自に明示的に生成することはお勧めしません。詳細については、こちらをお読みください。regedit を開いて Guid と ProgId を検索し、登録されているアセンブリのバージョンを確認することで、問題のトラブルシューティングを行うことができます。

于 2010-11-22T12:14:12.227 に答える