none
「mscorlib.dll を参照しない」の項目がない RRS feed

  • 質問

  • Visual Studio 2012のプロジェクトの設定について質問です。

    Visual Studio 2012 Professionalでプロジェクトのプロパティを開き、「ビルド」の「詳細設定」

    の中で「mscorlib.dllを参照しない」を有効/無効にする項目があると、MSDNのドキュメント

    にあるのですが、私の環境では当該のダイアログの中にはそのような項目がありません。

    なぜでしょう? 何か考えられる理由はあるでしょうか。目的のプロジェクトの種類はC#の

    SharePoint 2013用アプリで、SharePoint Onlineでの動作が目的です。リストを使う

    (SPWebなどを使う。これらは32ビットプラットフォームに非対応)ため、64ビットライブラリのみ

    を参照するようにしたいのです(オブジェクトブラウザで見ると、参照先のmscorlibは32ビット

    ライブラリなので参照対象から外したい。もしくは参照先を64ビット版のmscorlibにしたい)。

    2013年5月30日 4:53

回答

  • 「32ビットの優先」がグレーになっているのはきっとDLLだからです。

    最初の質問にて、『SharePoint 2013用アプリ』の開発であると書かれていました。

    SharePoint アプリの概要によれば、『SharePoint 用アプリ の最も基本的な形式は、アプリ マニフェストとともに SharePoint に登録される Web アプリケーションです。』だそうです。当方には SharePoint が無いため、それがどのようなプロジェクトなのかは確認できなかったのですが、これはクラスライブラリに相当するものなのでは無いでしょうか。

    exeの設定を変更する必要があります。

    ASP.NET の場合ですと、IIS 管理ツールで[アプリケーション プール]-[詳細設定]-[32 ビット アプリケーションの有効化]で、64bitから32bitに変更できるようになっていますね。今回の件とは関係あるかどうかは別として。

    SharePoint 開発の情報は、SharePoint フォーラム の「SharePoint - 開発とプログラミング」の方が具体的な情報が得やすいかも知れません。(既に「SharePoint 2013」のフォーラムに、関連質問を投稿されているようですが)

    • 回答としてマーク SG-TOM 2013年6月5日 0:37
    2013年6月4日 9:12

すべての返信

  • Visual Studio 2012 Professionalでプロジェクトのプロパティを開き、「ビルド」の「詳細設定」

    の中で「mscorlib.dllを参照しない」を有効/無効にする項目があると、MSDNのドキュメント

    にあるのですが、私の環境では当該のダイアログの中にはそのような項目がありません。

    たしかにMSDNに記載がありますが…手元の環境でも見当たりませんでした。
    上から「VS2005 Team System」「VS2008 Team Development」「VS2010 Ultimate」「VS2012 Ultimate」です。

    mscorlib.dll を参照しない

    2013年5月30日 7:02
  • 64ビットライブラリのみを参照するようにしたいのです(オブジェクトブラウザで見ると、参照先のmscorlibは32ビットライブラリなので参照対象から外したい。もしくは参照先を64ビット版のmscorlibにしたい)。
    32bit版を使っているように見えるのは、「Visual Studio」自体が32bit版だからなだけです。64bit版でビルドすれば自動的に64bit版のDLLにリンクされます。
    • 回答としてマーク SG-TOM 2013年5月31日 0:55
    • 回答としてマークされていない SG-TOM 2013年6月3日 8:16
    2013年5月30日 8:24
  • わかりました。アクティブ構成を「Debug|x64」にしてビルドすれば、リンクされるmscorlib.dllも

    自動的に64ビット版になるということですね。どうもありがとうございました。

    2013年5月31日 0:59
  • 質問そのものの「mscorlib.dllを参照しない」の件ですが、簡単なことでした。

    通常のコンパイルで既に /noconfig /nostdlib+ が付けられるようになっているため、オプションは無効、常にONでした。

    2013年6月1日 3:46
  • どんなコンパイルでも必ず /nostdlib がつくということは、オブジェクトブラウザで見ると

    mscorlib(x86) の項目が残ってはいるものの、実際にこれがリンクされることはもうない

    という認識で間違いないでしょうか。

    2013年6月3日 7:06
  • 全くの見当違いです。

    オブジェクトブラウザはアセンブリの内容を参照するためのツールであり、ビルドオプションには無関係です。
    # そもそもプロジェクトを開かなくてもオブジェクトブラウザを起動可能なことからも。

    ソリューションエクスプローラーでプロジェクト配下に「参照設定」がありその配下に「mscorlib」があるはずです。CSC.EXEのコンパイルオプションに/noconfig /nostdlib+が付けられることで暗黙的にmscorlibに参照することはなく、この「参照設定」に忠実に従うということです。

    とはいえ、mscorlibを参照しない場合、System.Int32もSystem.Stringも何もない状態になるので、質問者さんがプログラムを記述できるとはとても思えません。

    2013年6月3日 8:15
  • その後、試しに参照先のmscorlib.dll(x86)を退避(リネーム)してみたところ、

    ビルドエラーになりました。やはりこのDLLは(依然として)参照されているようです。

    2013年6月3日 8:23
  • 念のためですが、ビルド時に参照しているからと言って、実行時に参照するということの証明にはなりません。
    .NET Framework 標準のアセンブリは、ビルド時に x86 のアセンブリを参照していたとしても、実行時に適切なプラットフォームを選択するなどの振る舞いがあるはずです。

    2013年6月3日 13:15
    モデレータ
  • 目的は何でしょうか? 何をしたら何のエラーが出て、それは何が原因だとお考えでしょうか?

    Visual Studioが32bitであり、ビルド前に参照したりします。ビルドエラーになることと、生成されたバイナリが当該ファイルを参照することとは必ずしも一致しません。

    そもそも32bit版を参照したくないのはmscorlib.dllだけですか? 他のSystem.dllなどは32bit版でも構わないのですか? どうみても目的を見失っています。

    2013年6月3日 22:44
  • 本来の目的に立ち返ると、

    SPWeb mySite = Microsoft.SharePoint.SPContext.Current.Web;

    といったコードを含むSharePoint2013用アプリ(自動ホスト型)を、SharePointサイト

    上で実行させることです。これを、デフォルトの「Debug|Any CPU」構成でデバッグ実行

    すると、上記箇所にてPlatformNotSupportedException(メッセージ「Microsoft

    SharePoint は 32ビット処理でサポートされていません。64 ビット実行可能ファイルを

    実行していることを確認してください。」)で引っかかります。そもそもは、この問題の解消

    方法を知りたいのです。よろしくお願いします。


    • 編集済み SG-TOM 2013年6月4日 1:14
    2013年6月4日 1:13
  • ようやく「解決したいこと」を質問しましたね。今までの説明と全く異なる話題になります。

    今までの質問文で、この話題を求めていると察してあげるのは無理でしょう。質問者が一番答えに近い存在だということを理解してほしいです。

    「Any CPU」の場合、単一のバイナリで32bit / 64bitどちらでも動作します。その上で、ビルドオプションの「32ビットの優先」にチェックが付けられているために32bitで動作しています。これが原因です。

    対策としては単純には「32ビットの優先」のチェックを外すことですが、今回の場合、64bit動作を強制したいわけですから、もっと直接的にプラットフォームターゲットを「x64」に変更すべきです。

    2013年6月4日 4:13
  • 本来の意図からかけ離れた質問内容から始めたことで遠回りしてしまい、申し訳ありませんでした。

    ご指摘を受けて、プロジェクトのプロパティからビルドの項目を見たのですが、プラットフォームを「Any CPU」と「x64」のいずれに指定しても、「32ビットの優先」項目がグレーアウトかつチェックが入っていない状態です。この場合、SharePointアプリのバイナリにおいては、プラットフォームによる 32bit / 64bit 動作モードの選択はどのように行なわれていると考えればよいでしょうか?

    私の考えではこの場合、実行されたプラットフォームが 32bit なら32bit モードで、64bit なら必ず64bitモードで動作するものだと思うのですが・・・。


    • 編集済み SG-TOM 2013年6月4日 6:07
    2013年6月4日 6:05
  • 直接的にプラットフォームターゲットを「x64」に変更すべきです。

    先月末の投稿

    アクティブ構成を「Debug|x64」にしてビルドすれば

    と書いておられたので、それは既に変更してあるのかと思っていました。

    ちなみに、「32bit優先の AnyCPU ビルド」では、32bit OS でも 64bit OS でも 32bit で動作することになります。その点においては x86 ビルドに近い動きとなりますが、x86 ビルドとは異なり、ARM プロセッサーでも動作するという特徴があります。

    http://msdn.microsoft.com/ja-jp/library/vstudio/zekwfyz4.aspx

    2013年6月4日 6:07
  • 「Any CPU」と「x64」のいずれに指定しても、「32ビットの優先」項目がグレーアウトかつチェックが入っていない状態です。

    「32ビットの優先」は、AnyCPU ビルド+.NET 4.5+EXEファイルという組み合わせでのみ使用可能です。

    通常、AnyCPU ビルドされたアプリケーションは、32bit OS では 32bit動作、64bit OS では 64bit 動作となりますが、「32ビットの優先」が付与された場合、32/64bit いずれの OS においても、常に 32 bit 動作することになります。

    この場合、SharePointアプリのバイナリにおいては

    SharePoint 開発は未経験なので、こっちの回答は他の人にお任せ…。

    必ず64bitモードで動作するものだと思うのですが・・・。

    x64ビルドを選択されているのであれば、本来は64bit向けのアセンブリになっているはずです。

    生成されたアセンブリを CorFlags.exe に渡すと、そのファイルが 32bit用なのか64bit 用なのかが分かりますので、念のため確認してみては如何でしょうか。「32BIT : 1」と表示されるようであれば、それは 64bit 向けの物ではありません。

    2013年6月4日 6:22
  • プログラムを32bitで動作させるか64bitで動作させるかを決めるのはexeファイルです。「32ビットの優先」がグレーになっているのはきっとDLL(クラスライブラリプロジェクト)だからです。

    exeの設定を変更する必要があります。

    2013年6月4日 7:21
  • 「32ビットの優先」がグレーになっているのはきっとDLLだからです。

    最初の質問にて、『SharePoint 2013用アプリ』の開発であると書かれていました。

    SharePoint アプリの概要によれば、『SharePoint 用アプリ の最も基本的な形式は、アプリ マニフェストとともに SharePoint に登録される Web アプリケーションです。』だそうです。当方には SharePoint が無いため、それがどのようなプロジェクトなのかは確認できなかったのですが、これはクラスライブラリに相当するものなのでは無いでしょうか。

    exeの設定を変更する必要があります。

    ASP.NET の場合ですと、IIS 管理ツールで[アプリケーション プール]-[詳細設定]-[32 ビット アプリケーションの有効化]で、64bitから32bitに変更できるようになっていますね。今回の件とは関係あるかどうかは別として。

    SharePoint 開発の情報は、SharePoint フォーラム の「SharePoint - 開発とプログラミング」の方が具体的な情報が得やすいかも知れません。(既に「SharePoint 2013」のフォーラムに、関連質問を投稿されているようですが)

    • 回答としてマーク SG-TOM 2013年6月5日 0:37
    2013年6月4日 9:12
  • SharePoint に特化した質問であり、さらに別途スレッドが存在することから、そちらに集約するべきだと、私も思います。

    2013年6月4日 13:29
    モデレータ
  • 了解しました。以後は SharePoint 2013 のフォーラムのスレッドにて解決をはかっていくことにして、本スレッドはここまでにしたいと思います。ここまでどうもありがとうございました。
    2013年6月5日 0:37