プラットフォームがx64のとき、継承しているフォームのデザイン画面が表示されない。

Question

はじめまして。

VisualStudio2015にてVBのアプリ開発を行っております。
OSがWindows10(64bit)のため、プラットフォームはx64に設定しています

フォームのデザインを行う際、とあるフォーム(ex.Form1)を継承して、
別のフォーム(ex.Form2)を作成したいのですが、継承しているフォーム(ex.Form2)のデザイン画面を開くと
以下のエラーが表示され、デザイン画面が表示されません。

“ファイル内にデザインできるクラスがないため、このファイルのデザイナーを表示できませんでした。ファイルの以下のクラスがデザイナーで見つかりました:Form2 ___ 基本クラス
'WindowsAppkication1.Form1'を読み込めませんでした。アセンブリが参照されているか、およびすべてのプロジェクトがビルドされているかを確認してください。”

MSDNフォーラムや他のサイトに、
「プラットフォームをx64からx86やAnyCPUに変更し、ビルドする」ことでデザイン画面を開けるとの記述がありましたが、
先に述べたように、OSが64bit版で、また、とあるdll(64bit版)を使う都合上、
プラットフォームはx64でないと、実行はできてもエラーメッセージが表示されてしまうので、
なんとかx64のままでデザイン画面を開きたいと考えています。

「設定を変更する」や「パッチやアップデートをすることで解決できる」などの解決策があれば、
是非とも教えていただけないでしょうか。

もし、VisualStudioの設定上、x64のままでデザイン画面を開くことは不可能なのであれば、
下記のような手順をとらなければならないのでしょうか。

・フォームのデザインを行う時
一時的にプラットフォームをx86に変更しビルドし直す→デザイン画面を開き修正する

・デザイン画面を修正後、実行する時
再びプラットフォームをx64に戻しビルドし直す→実行する

なお、環境の詳細は以下の通りです。
OS：Windows 10 Enterprise
    64ビットオペレーティングシステム　x64ペースプロセッサ
VS：Microsoft Visual Studio Professional 2015
    Version 14.0.23107.0 D14REL
    Microsoft .NET Framework
    Version 4.6.00079

よろしくお願いいたします。

Answer 1

ささごん さま　よろしく。

" ... およびすべてのプロジェクトがビルドされているかを確認してください。” とありますが、　実際にビルドしても同じ状況ですか？。

Answer 2

ShiroYuki_Mot様

返信ありがとうございます。

何度かビルドを行ったり、一旦VisualStudioを閉じ、再度ソリューションを立ち上げても、デザイン画面は表示されませんでした。また、binフォルダやobjフォルダを削除してビルドしたりもしていますが、やはり表示されませんでした。

Answer 3

解決策含め、以下の記事に記載がありました。

https://support.microsoft.com/ja-jp/help/967050/cannot-display-inherited-form-in-form-designer-when-base-form-defined

Answer 4

Visual Studio は 32-bit 版のみです。質問者さんが行っているVisual Studio で「デザイン画面を開く」というのは 32-bit 版のアプリで x64 でコンパイルされた .dll を使うのと同じこどだと思います。

つまり、以下の記事の［Step 4. DLL ファイルのロードメカニズム］のセクションの図で×印がついているケースと同じはずです。

Part 1. 64 ビット Windows OS の基本知識
https://blogs.msdn.microsoft.com/nakama/2008/10/30/part-1-64-windows-os/

> OSがWindows10(64bit)のため、プラットフォームはx64に設定しています

そもそもそこに勘違いがあるような気がしますが・・・

以下の記事の［Step 8. コンソールアプリケーションにおけるコンパイルスイッチの意味］のセクションの最後の図を見てください。

Part 2. .NET Framework 2.0 アプリケーションの 64 ビット対応
https://blogs.msdn.microsoft.com/nakama/2008/11/05/part-2-net-framework-2-0-64/

Any CPU で作るのが正解だと思いませんか？

x64 で作ると、まだ巷に多数存在すると思われる 32-bit OS の PC では動かなくなります。図の×印を見てください。

Answer 5

uemu様、SurferOnWww様

返信ありがとうございます。

お二人に教えていただいたサイトをもとに、開発環境をもう一度、精査してみます。

Answer 6

VS は x86 しかなく、Windows Forms のデザイナで継承クラスやユーザーコントロールを扱うと、そのアセンブリを読み込むので、AnyCPU か x86 である必要がある点は、64bit 開発の悩みどころです。

最初から GUI プロジェクトを AnyCPU として分離し、プラットフォーム依存要素から切り離せるように設計しておかないと、デザイナが表示できない、表示するためにいちいち x86 に切り替えないといけないなど、手間がかかります。

今回は、既にある x64 DLL を使うとのことなので、それも含めて AnyCPU にできるのか、できないのかで難易度は変わりそうです。

Answer 7

> 開発環境をもう一度、精査してみます。

私のレスで書きましたように、OS が 64-bit だからと言って x64 でコンパイルするのが妥当なのかどうかをまずは検討されることをお勧めします。

質問者さんが言われる「開発環境をもう一度、精査」ということが具体的にどういうことか不明ですが、.dll を含めてすべて Any CPU で問題なければ、普通に考えて開発環境はそのままで済むと思います。

とにかく、Visual Studio には 32-bit 版しかないというところは何ともならないです。

どうしても x64 でコンパイルされたコントロールを使う必要があるなら、それを Visual Studio のデザイン画面で表示するのは諦めざるを得ないと思います。（環境で何とかできる話ではなさそうなので、手段をかんがえて対応せざるを得ないと思います）

Answer 8

返信が遅れてしまい、申し訳ありません。

AnyCPUに変更したところ、デザイン画面は表示されました。

実のところ、ためしにAnyCPUでビルドしたこともあったのですが、

AnyCPUでビルドすると、アプリケーションは実行できるものの、VSに別の警告がでてきてしまい、

そのため、警告がでてこないx64にて実行を行いたいという経緯がありました。

以下は、その警告の内容です。

「構築されているプロジェクトのプロセッサ アーキテクチャ "MSIL" と、参照 "Oracle.DataAccess" のプロセッサ アーキテクチャ "AMD64" の間には不一致がありました。この不一致は、ランタイム エラーを発生させる可能性があります。プロジェクトと参照の間でプロセッサ アーキテクチャが一致するように、構成マネージャーを使用してターゲットとするプロジェクトのプロセッサ アーキテクチャを変更するか、ターゲットとするプロジェクトのプロセッサ アーキテクチャに一致するプロジェクト アーキテクチャとの依存関係を参照で設定することを検討してください。」

最初の書き込みにて述べた「とあるdll(64bit版)」とは「Oracle.DataAccess.dll」のことでして、

上記の警告は「つくったプログラムはAnyCPUなのに、参照するOracle.DataAccess.dllはx64だから、

一致しませんよ」というような意味なのだと思っています。

繰り返しにはなりますが、この警告を出さないために、x64にこだわっていました。

現在、この警告が出ていても問題なくアプリケーションの機能が動き、

かつ、警告が出ていても大丈夫であると説明できる根拠を調べています。

もし、根拠がしっかりとわかれば、開発はAnyCPUにて行いたいと思います。

Answer 9

> 現在、この警告が出ていても問題なくアプリケーションの機能が動き、
> かつ、警告が出ていても大丈夫であると説明できる根拠を調べています。
> もし、根拠がしっかりとわかれば、開発はAnyCPUにて行いたいと思います。

どういう状況でビルドするとその警告が出るのでしょう？

エラーメッセージでググって調べましたが、以下の記事が 1 件ヒットしたのみでした。

Visual Studio Express 2015 for Webで64bit開発
http://qiita.com/rsuzuki/items/b1b592a04dd0bc4a7210

その記事は、デフォルトの 32-bit 版 IIS Express（開発用 Web サーバー）上で 64-bit 版の ODP.NET を使う ASP.NET Web アプリ（デフォルトで Any CPU）をビルドしたら質問者さんと同じ警告が出たそうです。

どこに問題があるかと言うと、32-bit 動作している IIS Express で、 Any CPU でコンパイルした Web アプリは 32-bit で動くが、それから 64-bit 版の ODP.NET を使おうとしたということです。

Visual Studio はビルドする際に Web アプリと ODP.NET だけでなく IIS Express との不整合もチェックして警告を出したように見えます。（ホントに IIS Express までチェックするのか？・・・という気もしますが、記事の話に間違いなければそのようです）

質問者さんの開発しているのは Windows Forms アプリのようですので IIS Express は関係ないのですが、上記の記事のケースと同様に Windows Forms アプリと ODP.NET 以外の何かとの整合を調べて警告を出したような気がします。

それが何か分からないとはっきりしたことは言えませんが、少なくとも 64-bit OS 上で Any CPU でコンパイルした Windows Forms アプリ、Any CPU でコンパイルした .dll、64-bit 版 ODP.NET は問題なく動くことは確かだと思います。（注：Any CPU でもビルドオプションで［32 ビットを優先(P)］にチェックを入れるのは NG と思います）

32/64-bit 版両方の OS 上で動かしたいなら、Windows Forms アプリと .dll は x86 でコンパイルし、32-bit 版の ODP.NET を使うことで可能だと思います。

詳しくは先に紹介した記事をよく読んでください。

Answer 10

どういう状況でビルドするとその警告が出るのでしょう？

「どういう状況でビルドすると」警告がでるかと言いますと、

「AnyCPUに変えてビルドしたら」としか今は言えないです。特殊な設定とかは、おそらく行っていないと思います。

確証はありませんが、以下のサイトを見る限りでは、この警告は出てもしかたないのかもしれません。

Visual Studio で "プロセッサ アーキテクチャ 間 の 不一致" 警告の抑制https://garafu.blogspot.jp/2014/09/visual-studio.html

こちらのページでは、「警告が鬱陶しい」から「抑制する」とありました。「問題ないのに、警告が出て鬱陶しい」という意味なら、無視してもいいということになるのですが、そこは書かれていませんでした。

.NET備忘録-10.oo4o-13.AnyCPU対応 - KOZの館 - Visual Basic Programming -http://kozhouse.homeip.net/dotnet/oo4o/13/

こちらのページでは、サイトの最後のほうにある「OracleInProcServer.NET を AnyCPU でコンパイル 」の章で、「ワーニングエラー(MSIL と Oracle.DataAccess のアーキテクチャが違う)が出ますが、無視してください」との記述がありました。ですが、環境が異なるので、説明する上での根拠としては薄いのかなとも思います。

ちなみに、このアプリケーションは64bitマシンでのみの使用を想定しています。

ですので、この警告がどうしても気になる場合は、最悪、デザイン時のみAnyCPUでビルドし、実行時は、x64にてビルドするというのも、手かもしれません。（デザイン時と実行時の環境が異なるというのも、なにか弊害がありそうな気もしますが）

ただ、まずは、AnyCPUで実行してみようかと思います。

Answer 11

質問者さんが探された記事には理由が書いてありませんが、多分以下の記事に書いてあるのが理由ではないかと思います。

https://secure.toshiba-teli.co.jp/ttfa/web/faq_j/faq1345.html

つまり、ODP.NET はネイティブの dll を呼び出す必要があるので、"AMD64"のプロセッサアーキテクチャでコンパイルされています。このため、C#アプリケーションをデフォルトのプロセッサアーキテクチャ”Any CPU"でコンパイルするとプロセッサアーキテクチャ不一致の警告が表示されます・・・ということのように思えます。

やはり自分の想像（IIS Express までチェックしている）は大ハズレれだったようですが、何にせよ、先の私のレスで書いた、

> 少なくとも 64-bit OS 上で Any CPU でコンパイルした Windows Forms アプリ、Any CPU でコンパイルした .dll、64-bit 版 ODP.NET は問題なく動くことは確かだと思います。（注：Any CPU でもビルドオプションで［32 ビットを優先(P)］にチェックを入れるのは NG と思います）

は間違いないはずです。

Answer 12

警告は、「AnyCPU という x86 でも x64 でも動くように設定をしているのに、それに反する、x64 限定のアセンブリを参照している」ことを指摘しています。
本質的には、x64 を参照するプロジェクトを x64 としていくなど、警告が出ないように構成するべきです。

ただ、x64 だと Windows Forms のデザイナで読み込めないという当初の問題にぶつかるので、警告を受けないようにうまく作るには、Form/UserControl を x64 の汚染を受けないようにうまく切り出して AnyCPU を維持し、必要な処理を外部から注入する、依存関係逆転の原則を取り入れる必要があります。（原則については調べてみてください）

もっとも、そこまで頑張らないというのであれば、警告を無視するか、表示されないように加工した上で AnyCPU で継続し、「x86 では実行しないでね」で済ませることでしょう。
プロジェクトを分けているのであれば、exe プロジェクトだけ x64 指定にしてしまえば、x86 で仕組み的にも実行できなくなります。

長々と書きましたが、質問者のあなた自身が、どこまで頑張るかで決めてください。
警告を無視してとりあえずしのぐのか、きちんとプロジェクトやクラスを切り分けていって、警告されないようにきれいに作るのか。