2007/09/20 21:49
ひょんなこと ( ※ ) から、 TypeForwardedToAttribute クラス (System.Runtime.CompilerServices) というクラスの存在を知りました。
でも、MSDN には
別のアセンブリ内にある転送先の Type を指定します。このクラスは継承できません。
TypeForwardedToAttribute 属性を使用して、古いアセンブリに対してコンパイルを実行した呼び出し元を妨げずに、あるアセンブリから別のアセンブリに型を移動します。
としか書いてなくて、全く意味がわかりませんでした。
で、ネットで検索してみたら見つかりました。
Mimori's Algorithms tDiary(2007-04-25)
なるほど、例えば、コンソールアプリケーション A からクラスライブラリ A の Hoge クラスと Fuga クラスを利用していたとします。後に Fuga クラスをクラスライブラリ A からクラスライブラリ B へと移動した場合、コンソールアプリケーション A はクラスライブラリ B を参照していないため、そのままでは Fuga クラスを利用できなくなってしまいます。通常、この問題を解決するには、コンソールアプリケーション A の参照設定を修正して再コンパイルする必要があります。しかし、それができない場合に TypeForwardedToAttribute 属性が登場するわけですね。クラスライブラリ A に TypeForwardedToAttribute 属性を付加してクラスライブラリ B の Fuga クラスを指定すれば、コンソールアプリケーション A の参照設定を修正することなく、Fuga クラスを引き続き利用できるわけです。
※ MCP 試験 70-551: UPGRADE: MCAD Skills to MCPD Web Developer by Using the Microsoft .NET Framework
でも、MSDN には
別のアセンブリ内にある転送先の Type を指定します。このクラスは継承できません。
TypeForwardedToAttribute 属性を使用して、古いアセンブリに対してコンパイルを実行した呼び出し元を妨げずに、あるアセンブリから別のアセンブリに型を移動します。
としか書いてなくて、全く意味がわかりませんでした。
で、ネットで検索してみたら見つかりました。
Mimori's Algorithms tDiary(2007-04-25)
なるほど、例えば、コンソールアプリケーション A からクラスライブラリ A の Hoge クラスと Fuga クラスを利用していたとします。後に Fuga クラスをクラスライブラリ A からクラスライブラリ B へと移動した場合、コンソールアプリケーション A はクラスライブラリ B を参照していないため、そのままでは Fuga クラスを利用できなくなってしまいます。通常、この問題を解決するには、コンソールアプリケーション A の参照設定を修正して再コンパイルする必要があります。しかし、それができない場合に TypeForwardedToAttribute 属性が登場するわけですね。クラスライブラリ A に TypeForwardedToAttribute 属性を付加してクラスライブラリ B の Fuga クラスを指定すれば、コンソールアプリケーション A の参照設定を修正することなく、Fuga クラスを引き続き利用できるわけです。
※ MCP 試験 70-551: UPGRADE: MCAD Skills to MCPD Web Developer by Using the Microsoft .NET Framework
スポンサーサイト
2007/04/03 17:44
プロジェクトのプロパティを開いてビルド イベントのページで次のように設定します。
ビルド前に実行するコマンド ライン
"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /u "$(TargetName)"
ビルド後に実行するコマンド ライン
"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i "$(TargetFileName)"
これで、ビルドと同時にアセンブリが GAC にインストールされます。
ビルド前に実行するコマンド ライン
"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /u "$(TargetName)"
ビルド後に実行するコマンド ライン
"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i "$(TargetFileName)"
これで、ビルドと同時にアセンブリが GAC にインストールされます。
2006/10/01 12:11
アセンブリには、署名（電子署名）を行うことができる。
一般的に、共有DLLには、署名を行うことが推奨される。
GACにインストールするDLL、ClickOnceのアプリケーション マニフェストと配置ファイルには、署名が必須となる。
また、一般的に、EXEファイル、一つのアプリケーション固有のDLLには、署名を付けないことが推奨される。
【 アセンブリの署名による利点 】
アセンブリの署名により、主に以下のような効果が得られる。
[ １． DLLをGACにインストールできる ]
GACとは、一台のPC内で、グローバルに参照できる特殊な領域のことである。GACにインストールされたDLLは、一台のPC内で共有される。
具体的な場所は、 [ %SystemRoot%\assembly ] となる。 [ %SystemRoot% ] は、Windows XPなら通常 [ C:\WINDOWS ] を示す。
GACへのインストールは手動ででき、単にDLLをGACへドラッグ＆ドロップするだけでインストールされる。また、グローバル アセンブリ キャッシュ ツール (Gacutil.exe) を使ってインストールすることもできる。Gacutil.exeを使ってインストールするには、.NET Framework付属のコマンドプロンプトで以下のコマンドを実行する。FileNameには、DLL名を記述する。gacutil /i FileNameなお、.NET Framework クラスライブラリ （以降、NFCと表記） も、ここにインストールされている。
[ ２． DLLのバージョン管理が行える ]
例えば、.NET Framework （以降、.NET Fxと表記） 1.1のNFCは、バージョン1.0.5000.0で、.NET Fx 2.0のNFCはバージョン2.0.0.0であるが、これらはGAC内に共存できる。
これらが共存しているPCで、.NET Fx 1.1をベースに作成されたアプリケーションを実行するとどうなるか？答えは、バージョン1.0.5000.0のNFCが利用される。つまり、バージョンの異なるDLLが存在しても、アプリケーションは決められたバージョンのDLLを利用するということである。
DLLのバージョン管理が行われることで、DLL Hellが解消されるという利点が得られる。
なお、バージョン管理は、GAC内のDLLに限らず、アプリケーションのインストールディレクトリ内のDLLにも適用される。
（実は、NFCは下位互換性があり、また特別なので、.NET Fx 1.1がインストールされていない場合、.NET Fx 1.1ベースのアプリケーションは.NET Fx 2.0上で動き.NET Fx 2.0のNFCを利用するわけだけど＾＾； ）
[ ３． アセンブリの改竄を検出できる ]
これは電子署名そのものの性質 （詳しくは次回） でもある。
アセンブリを誰かが勝手に改竄した場合、アプリケーションの実行時にそれを検出することができる。
この利点が、ある意味一番大きな利点かもしれない。
ただし、署名に使った秘密鍵が第三者の手に渡らないことが大前提である。署名に使った秘密鍵さえあれば、改竄した後に再び署名を行うことができてしまうため、秘密鍵は厳重に保管しなければならない。
【 アセンブリに署名を行う方法 】
アセンブリに電子署名を行うには、RSA暗号化方式 （詳しくは次回） の秘密鍵と公開鍵という、対になった鍵 （以降、キーペアと表記） が必要である。
キーペアを作成し、キーペアを元にアセンブリに署名する手順を以下に記述する。
[ 従来からの方法 ]
.NETでは、キーペアを作成するためのツールとして、厳密名ツール (Sn.exe) が提供されている。
使用方法は簡単で、.NET Framework付属のコマンドプロンプトで以下のコマンドを実行すれば、キーペアがファイルとして作成される。outfileには、出力ファイル名を記述し、拡張子は.snkとする。sn -k outfileキーペアファイルをキー コンテナという特殊なファイルに格納する場合は、続けて以下のコマンドを実行する。infileには作成したキーペアファイルの名前、ContainerNemaにはキー コンテナの名前を記述する。 （キー コンテナに拡張子はない。）sn -i infile ContainerName
キーペアを作成したら、アセンブリに署名を行う。署名を行うには、アセンブリ リンカ (Al.exe) を利用するか、AssemblyKeyFileAttribute （キーペアをキーコンテナにインストールした場合はAssemblyKeyNameAttribute） を使用する。
アセンブリリンカを使う場合は、アセンブリファイルではなくモジュールファイル（拡張子は.netmodule）が必要となるため、C#コンパイラを使って自分でコンパイルを行うことになる。この辺は、＠ITさんの以下の記事が参考になる。
＠IT：インサイド .NET Framework ［改訂版］第1回 マネージ・コード／アセンブリ／モジュール
属性を使う場合は、以下のコードを （通常、AssemblyInfo.csに） 記述するだけでよい。[assembly: AssemblyKeyFile("FileName")]キーコンテナにインストールした場合は、以下のコードとなる。[assembly: AssemblyKeyName("ContainerName")]
ただし、NET Framework 2.0 では、AssemblyKeyFileAttributeやAssemblyKeyNameAttributeによるアセンブリの署名は、セキュリティ上の問題等を理由に非推奨となっている。
[ Visual Studio 2005 での署名 ]
Visual Studio 2005では、キーペアの作成からアセンブリの署名までを、簡単に行うことができるようになった。手順は以下のようになる。
パスワードで保護する場合は、キーペアではなく電子証明書 （内部にキーペアが含まれている。拡張子はpfx） が作成される。パスワードで保護しない場合は、キーペアが作成される。
電子証明書のパスワードは比較的容易に解読可能であるため、パスワードの有無は実質的に、キーペアファイルと電子証明書のどちらを作成するかの違いでしかないと言える。
また、電子証明書は、発行者と発行先が同一な、いわゆるオレオレ証明書なので、電子証明書を作成する必要はあまりないと思われる。 （電子証明書を使う必要がないのではなく、オレオレ証明書を使う必要がないという意味なので注意。）
なお、既存のキーペアや既存の電子証明書を利用する場合は、手順4，5，6の代わりに、コンボボックスの [ <参照...> ] を選択し、参照ダイアログにてファイルを選択する。
[ 参考 ]
アセンブリおよびマニフェストへの署名の管理
＠IT：インサイド .NET Framework ［改訂版］第2回 アセンブリのアイデンティティ
[ 関連 ]
ClickOnce マニフェストの署名
一般的に、共有DLLには、署名を行うことが推奨される。
GACにインストールするDLL、ClickOnceのアプリケーション マニフェストと配置ファイルには、署名が必須となる。
また、一般的に、EXEファイル、一つのアプリケーション固有のDLLには、署名を付けないことが推奨される。
【 アセンブリの署名による利点 】
アセンブリの署名により、主に以下のような効果が得られる。
[ １． DLLをGACにインストールできる ]
GACとは、一台のPC内で、グローバルに参照できる特殊な領域のことである。GACにインストールされたDLLは、一台のPC内で共有される。
具体的な場所は、 [ %SystemRoot%\assembly ] となる。 [ %SystemRoot% ] は、Windows XPなら通常 [ C:\WINDOWS ] を示す。
GACへのインストールは手動ででき、単にDLLをGACへドラッグ＆ドロップするだけでインストールされる。また、グローバル アセンブリ キャッシュ ツール (Gacutil.exe) を使ってインストールすることもできる。Gacutil.exeを使ってインストールするには、.NET Framework付属のコマンドプロンプトで以下のコマンドを実行する。FileNameには、DLL名を記述する。gacutil /i FileNameなお、.NET Framework クラスライブラリ （以降、NFCと表記） も、ここにインストールされている。
[ ２． DLLのバージョン管理が行える ]
例えば、.NET Framework （以降、.NET Fxと表記） 1.1のNFCは、バージョン1.0.5000.0で、.NET Fx 2.0のNFCはバージョン2.0.0.0であるが、これらはGAC内に共存できる。
これらが共存しているPCで、.NET Fx 1.1をベースに作成されたアプリケーションを実行するとどうなるか？答えは、バージョン1.0.5000.0のNFCが利用される。つまり、バージョンの異なるDLLが存在しても、アプリケーションは決められたバージョンのDLLを利用するということである。
DLLのバージョン管理が行われることで、DLL Hellが解消されるという利点が得られる。
なお、バージョン管理は、GAC内のDLLに限らず、アプリケーションのインストールディレクトリ内のDLLにも適用される。
（実は、NFCは下位互換性があり、また特別なので、.NET Fx 1.1がインストールされていない場合、.NET Fx 1.1ベースのアプリケーションは.NET Fx 2.0上で動き.NET Fx 2.0のNFCを利用するわけだけど＾＾； ）
[ ３． アセンブリの改竄を検出できる ]
これは電子署名そのものの性質 （詳しくは次回） でもある。
アセンブリを誰かが勝手に改竄した場合、アプリケーションの実行時にそれを検出することができる。
この利点が、ある意味一番大きな利点かもしれない。
ただし、署名に使った秘密鍵が第三者の手に渡らないことが大前提である。署名に使った秘密鍵さえあれば、改竄した後に再び署名を行うことができてしまうため、秘密鍵は厳重に保管しなければならない。
【 アセンブリに署名を行う方法 】
アセンブリに電子署名を行うには、RSA暗号化方式 （詳しくは次回） の秘密鍵と公開鍵という、対になった鍵 （以降、キーペアと表記） が必要である。
キーペアを作成し、キーペアを元にアセンブリに署名する手順を以下に記述する。
[ 従来からの方法 ]
.NETでは、キーペアを作成するためのツールとして、厳密名ツール (Sn.exe) が提供されている。
使用方法は簡単で、.NET Framework付属のコマンドプロンプトで以下のコマンドを実行すれば、キーペアがファイルとして作成される。outfileには、出力ファイル名を記述し、拡張子は.snkとする。sn -k outfileキーペアファイルをキー コンテナという特殊なファイルに格納する場合は、続けて以下のコマンドを実行する。infileには作成したキーペアファイルの名前、ContainerNemaにはキー コンテナの名前を記述する。 （キー コンテナに拡張子はない。）sn -i infile ContainerName
キーペアを作成したら、アセンブリに署名を行う。署名を行うには、アセンブリ リンカ (Al.exe) を利用するか、AssemblyKeyFileAttribute （キーペアをキーコンテナにインストールした場合はAssemblyKeyNameAttribute） を使用する。
アセンブリリンカを使う場合は、アセンブリファイルではなくモジュールファイル（拡張子は.netmodule）が必要となるため、C#コンパイラを使って自分でコンパイルを行うことになる。この辺は、＠ITさんの以下の記事が参考になる。
＠IT：インサイド .NET Framework ［改訂版］第1回 マネージ・コード／アセンブリ／モジュール
属性を使う場合は、以下のコードを （通常、AssemblyInfo.csに） 記述するだけでよい。[assembly: AssemblyKeyFile("FileName")]キーコンテナにインストールした場合は、以下のコードとなる。[assembly: AssemblyKeyName("ContainerName")]
ただし、NET Framework 2.0 では、AssemblyKeyFileAttributeやAssemblyKeyNameAttributeによるアセンブリの署名は、セキュリティ上の問題等を理由に非推奨となっている。
[ Visual Studio 2005 での署名 ]
Visual Studio 2005では、キーペアの作成からアセンブリの署名までを、簡単に行うことができるようになった。手順は以下のようになる。
- ソリューション エクスプローラでプロジェクトの右クリックメニューの [ プロパティ ] をクリックし、プロジェクト デザイナを開く。
- [ 署名 ] タブをクリック。
- [ アセンブリの署名 ] チェックボックスにチェックを付ける。
- コンボボックスの [ <新規作成...> ] を選択する。
- [ キー ファイル ] テキストボックスに、作成するキーペアファイルの名前 （拡張子は不要） を入力する。
- パスワードで保護する場合は、[ キーファイルをパスワードで保護する ] にチェックを付け、8桁以上のパスワードを入力する。保護しない場合は、チェックを外す。
- [ OK ] ボタンをクリックする。
パスワードで保護する場合は、キーペアではなく電子証明書 （内部にキーペアが含まれている。拡張子はpfx） が作成される。パスワードで保護しない場合は、キーペアが作成される。
電子証明書のパスワードは比較的容易に解読可能であるため、パスワードの有無は実質的に、キーペアファイルと電子証明書のどちらを作成するかの違いでしかないと言える。
また、電子証明書は、発行者と発行先が同一な、いわゆるオレオレ証明書なので、電子証明書を作成する必要はあまりないと思われる。 （電子証明書を使う必要がないのではなく、オレオレ証明書を使う必要がないという意味なので注意。）
なお、既存のキーペアや既存の電子証明書を利用する場合は、手順4，5，6の代わりに、コンボボックスの [ <参照...> ] を選択し、参照ダイアログにてファイルを選択する。
[ 参考 ]
アセンブリおよびマニフェストへの署名の管理
＠IT：インサイド .NET Framework ［改訂版］第2回 アセンブリのアイデンティティ
[ 関連 ]
ClickOnce マニフェストの署名
Calendar
