64bit.NETコンポーネントが登録できない

分類:[.NET]

2012/02/22(Wed) 14:54:11 編集(投稿者)

かなり調べているのですが、情報が足りず行きずまってる
状況です。ご存知の方がいらっしゃいましたら
ヒントでもかまいませんのでコメント頂けませんでしょうか？
宜しくお願い致します。

VS2005で開発された.NETコンポーネント（DLL）があり、
通常開発者は、このDLLをVS2005のツールボックスに登録することで
新しいコントロールがツールボックス上に配置され、
開発ができる状況になります。

ここまでは特に問題なし。

今回上記コンポーネントを64bitOS対応にする必要があり、
VS2005のプロジェクトをVS2010に読み込みし、
CPUオプションをAnyCPUからx64に変更しビルドしました。
エラーもなくビルドが成功しました。

このx64にしたコンポーネントをVS2010のツールボックスに
登録しようとすると「.Netコンポーネントではありません」
というエラーが発生します。

そこで質問になります。
.NETコンポーネントはx64として開発可能なのでしょうか？

> このx64にしたコンポーネントをVS2010のツールボックスに
> 登録しようとすると「.Netコンポーネントではありません」
> というエラーが発生します。
>
> そこで質問になります。
> .NETコンポーネントはx64として開発可能なのでしょうか？

　　VisualStudio自体は、32bitアプリケーションではなかった
　　でしょうか？

　　タスクマネージャで調べてみて下さい。

以上。

■No29925に返信(オショウさんの記事)
>>このx64にしたコンポーネントをVS2010のツールボックスに
>>登録しようとすると「.Netコンポーネントではありません」
>>というエラーが発生します。
>>
>>そこで質問になります。
>>.NETコンポーネントはx64として開発可能なのでしょうか？
>
> 　　VisualStudio自体は、32bitアプリケーションではなかった
> 　　でしょうか？
>
> 　　タスクマネージャで調べてみて下さい。
>
> 以上。

コメント頂きありがとうございます。
もともとのアプリケーションはご指摘のように
32bitDLL＋32bitアプリになります。

今回、32bitDLLを64bitビルドしなおしています。
エラーが発生しないと仮定した場合、
次の手順にて64bitアプリを開発します。
１．64bitDLLをVS2010に登録し、カスタムコントロールを追加
２．64bitアプリを開発

上記、１の登録のときにエラーになってしまい、登録できないことが
今回の困ったことになります。

質問に対しての答えですが
DLLに対応するアプリは64bitですが、DLLが登録できないため
カスタムコントロールが使えないため、64bitアプリを開発できない状況
にあります。

2012/02/22(Wed) 22:43:30 編集(投稿者)

■No29926に返信(菊池さんの記事)
>>　　VisualStudio自体は、32bitアプリケーションではなかった
>>　　でしょうか？
(略)
> コメント頂きありがとうございます。
> もともとのアプリケーションはご指摘のように
> 32bitDLL＋32bitアプリになります。

きちんとコメントを読んでいますか？
あなたのアプリケーションがどうかではなく、Visual Studio の話をしていますよ。

ツールボックスに .NET のアセンブリ（ユーザーコントロール）を追加すると、Visual Studio は自分のプロセスにそのアセンブリを読み込もうとします。
しかしながら、Visual Studio は 32bit プロセスですので、64bit のアセンブリを読み込むことはできません。
この件はサポート情報(KB)にも挙がっています。(2010 でも変わりません)
http://support.microsoft.com/kb/963017

ところで、64bit Windows で動かすためには以下の 3 つの選択肢があるわけですが、あえて (3) を選んだ理由はありますか？

(1) x86 でビルドして WOW64 で動かす
(2) AnyCPU でビルドして x86 では 32bit、x64 では 64bit として動かす
(3) x64 でビルドして x86 では動作せず、x64 では 64bit として動かす

差し障りがなければ、クラスライブラリプロジェクト(DLL)は AnyCPU で、アプリケーションプロジェクト(EXE)は AnyCPU もしくは x64 とすればよいのではないでしょうか。

# たとえ、クラスライブラリを x64 にしたい理由があったとしても、
# ユーザーコントロールを含むクラスライブラリだけでも AnyCPU にすれば済むはず。
# できないのなら、クラスの分離を検討すべきかな。

■No29927に返信(Azuleanさんの記事)
> 2012/02/22(Wed) 22:43:30 編集(投稿者)
>
> ■No29926に返信(菊池さんの記事)
> >>　　VisualStudio自体は、32bitアプリケーションではなかった
> >>　　でしょうか？
> (略)
>>コメント頂きありがとうございます。
>>もともとのアプリケーションはご指摘のように
>>32bitDLL＋32bitアプリになります。
>
> きちんとコメントを読んでいますか？
> あなたのアプリケーションがどうかではなく、Visual Studio の話をしていますよ。

申し訳ありませんでした。
主語をきちんと確認しておりませんでした。
おっしゃる通りVisual Studioそのものの話でした。

> ツールボックスに .NET のアセンブリ（ユーザーコントロール）を追加すると、Visual Studio は自分のプロセスにそのアセンブリを読み込もうとします。
> しかしながら、Visual Studio は 32bit プロセスですので、64bit のアセンブリを読み込むことはできません。
> この件はサポート情報(KB)にも挙がっています。(2010 でも変わりません)
> http://support.microsoft.com/kb/963017

サポート情報を確認しました。
調べて頂きありがとうございました。

> ところで、64bit Windows で動かすためには以下の 3 つの選択肢があるわけですが、あえて (3) を選んだ理由はありますか？
>
> (1) x86 でビルドして WOW64 で動かす
> (2) AnyCPU でビルドして x86 では 32bit、x64 では 64bit として動かす
> (3) x64 でビルドして x86 では動作せず、x64 では 64bit として動かす

３を選んだ理由は、お客様の必須要件であったためです。

> 差し障りがなければ、クラスライブラリプロジェクト(DLL)は AnyCPU で、アプリケーションプロジェクト(EXE)は AnyCPU もしくは x64 とすればよいのではないでしょうか。
> # たとえ、クラスライブラリを x64 にしたい理由があったとしても、
> # ユーザーコントロールを含むクラスライブラリだけでも AnyCPU にすれば済むはず。

なるほど、そういう方法があったんですね。
思いつきませんでした。実際に動作するか試してみます。

> # できないのなら、クラスの分離を検討すべきかな。

すみません。このクラスの分離という意味ですが
どういうことでしょうか？
なぜクラスの分離という話に行き着くのかが理解できません。
お手数とは思いますが、補足を頂けないでしょうか？
手間とは思いますが、宜しくお願い致します。

>># できないのなら、クラスの分離を検討すべきかな。
>
> すみません。このクラスの分離という意味ですが
> どういうことでしょうか？
> なぜクラスの分離という話に行き着くのかが理解できません。
> お手数とは思いますが、補足を頂けないでしょうか？
> 手間とは思いますが、宜しくお願い致します。

ユーザコントロールの部分と、その他の部分を、別のDLLに
分離し、ユーザコントロールの部分をAnyCPUとして、
そのほかの部分をAnyCPUもしくはx64とするということで
理解しました。

DLLはAnyCPUとして、アプリもAnyCPUとしてビルドすることにより
64bitOS上で動作することを確認しました。
また、アプリをx64としてビルドしても問題なく動作しています。

みなさま、コメント頂きありがとうございました。
大変助かりました。