none
ASP.NET WEBサイト(VB)で、yieldが使用できない RRS feed

  • 質問

  • VisualStudio2012、FrameWork4.0、VBです。

    ASP.NET Webフォームアプリケーションでは「Yield」が使用できるのですが

    ASP.NET WebサイトのApp_Codeフォルダ内に配置したクラスでは

    「Yield」を使用すると「Visual Basic10.0は反復子をサポートしていません。」とコンパイルエラーになります。

    コンパイルエラーになる理由、使用できるようにする方法がございましたらご教示ください。

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

    2016年6月22日 5:15

回答

  • 単にWebサイト(というかASP.NET共通といっていいか)の、App_Codeの動的コンパイルに関するVisual Studioのチェックの特殊な挙動というだけじゃないですかね。

    普通の開発環境上でのVisual Studioの挙動は、前にも書きましたが、ターゲットフレームワークのバージョンにかかわらず、そのバージョンのVisual Studioが対応している言語仕様は使える、という動作です。(試された通りの挙動)

    App_Codeの動的コンパイルコードに対するチェックだけが特殊な動きをしているように見えますし、実際これは通常のVisual Studio上でのコンパイルとは仕組みが異なる(普通のビルドとはちょっと違う)ことから、仕組み上そういうことになってしまっているのだろう、と思える挙動です。

    ややこしい話ではありますが。

    ・Visual Studio上での普通のプロジェクトのコンパイル(Webアプリのこのパイルもこれにあたる)

     ⇒ターゲットバージョンによらず、Visual Studioのバージョンで使える言語仕様はコンパイルできる

    ・App_Codeに配置したコード(動的コンパイル対象)の、Visual Studioによる独自チェック

     ⇒Web.cofigのターゲットフレームワークのバージョンを見て、対応するバージョンのコンパイラでチェックしたような動作をする

    という2パターンだけ、みたいな。(VS上での挙動のパターンの話)


    • 編集済み なちゃ 2016年6月24日 7:27
    • 回答としてマーク longbridge0 2016年6月28日 5:51
    2016年6月24日 7:19
  • なちゃさんのコメントを受けて、改めて私の理解をもう少し簡潔にまとめると、以下です。

    1. 通常VSはそのVSで組み込まれたバージョンのコンパイラを基準にエラーなどのチェックを行う
    2. 「Webサイト」プロジェクトの場合、ターゲットのフレームワークに同梱されているバージョンのコンパイラを基準にチェックを行う特殊?対応を行っている
    3. 「Webアプリケーション」プロジェクトでもApp_Codeフォルダのみ「Webサイト」相当のチェックが行われている

    以下補足です。

    • 「2」 のケースではターゲットのフレームワークはWeb.Configではなくソリューションファイル内で管理されている項目で判定しているようです
    • 「Webサイト」プロジェクトの場合、App_Code配下だけでなくほかの場所のコード(例えばコードビハインド)も同様にターゲットのフレームワーク同梱バージョンのコンパイラ基準でチェックされているようです
    • 「3」 についてはMS的にも想定外のパターンの気もしますがまあ通常は実害もないですし(

    きよくらならみ

    • 回答としてマーク longbridge0 2016年6月28日 5:48
    2016年6月24日 8:53

すべての返信

  • > VisualStudio2012、FrameWork4.0、VBです。

    それは間違いないですか? VS2012 なら VB.NET のバージョンは 11.0 のはずですが。

    Microsoft Visual Basic .NET
    https://ja.wikipedia.org/wiki/Microsoft_Visual_Basic_.NET

    ちなみに、VS2012 から VB.NET でも Yield がサポートされたのは間違いないようです。

    Visual Studio 2012 における Visual Basic の新機能
    https://msdn.microsoft.com/ja-jp/library/we86c8x2(v=vs.110).aspx

    > 使用できるようにする方法がございましたらご教示ください。

    なぜ質問者さんの環境でバージョン 10.0 なのか分かりませんが、たとえば、もし、実際に使っているのは VS2010 の間違いで、そこのところが解決できなければ(VS2012 にアップグレードする等ができなければ)、その部分のみ C# を使うほかないと思います。

    App_Code フォルダを使っているということは、ASP.NET Web Forms アプリを Web サイトプロジェクトで作っていると思いますが、そうであれば部分的に C# を使う方法はいろいろあります。

    2016年6月22日 6:41
  • 間違いなくVisualStuudio2012、FrameWork4.0、VBです。

    VisualStudio2012を起動し「ファイル」 > 「新規作成」 > 「Webサイト」で

    Webサイトを作り、「App_Code」フォルダにYieldを使用したクラスを配置しても

    「Visual Basic10.0は反復子をサポートしていません。」とコンパイルエラーになります。

    Webフォームアプリケーションで「App_Code」フォルダにYieldを使用したクラスを配置しても

    「Visual Basic10.0は反復子をサポートしていません。」とコンパイルエラーになります。

    Webフォームアプリケーションで「App_Code」ではなく「AppCode」フォルダにYieldを使用したクラスを配置すれば

    コンパイル&実行できます。

    上記の事を考えると

    App_Codeフォルダ配下はVisualStudio2012であっても2010でコンパイルされるのか!?

    と疑問に思った次第です。

    2016年6月22日 7:45
  • 間違いなくVisualStuudio2012、FrameWork4.0、VBです。

    App_Codeフォルダ配下はVisualStudio2012であっても2010でコンパイルされるのか!?

    と疑問に思った次第です。

    .NET Framework 4ターゲットというのが原因かもしれません。

    Visual Studio上でのコンパイルは、ターゲットは古くてもコンパイラは新しいものを使用するため、その.NET Frameworkが出た当時ではサポートしていなかった言語機能が使えたりします。

    しかし、App_Codeの動的コンパイルでは、Visual Studioではなく、.NET Frameworkのコンパイラで動的コンパイルされるため、古い言語機能しか使えない、ということがあるかもしれません。

    それでも、.NET Framework 4.5などがインストールされていたら新しくなりそうな気もするんですが、ちょっとそのあたりはよくわかりません。

    まあ、可能性の一つということで。

    2016年6月22日 8:21
  • Visual Studio 2013で試してみたら、同じ挙動になりました。
    (Webサイト - ASP.NET Web フォームサイト )

    どうやらターゲットフレームワークの設定によってVisual Studioがチェックの対象とするコンパイラのバージョンを変えているようです。試しにターゲットフレームワークを.NET Framework 4.5に変えてみたらエラーは表示されなくなりました。
    (この動きはWeb.Condfig側ではなくソリューションファイルのTargetFrameworkMonikerの項で管理しているバージョンに依存しているようです)


    このような挙動の理由は、VBのイテレータ構文の対応とVBと.NETフレームワークのバージョンの対応が以下のようになっているかではないでしょうか。

    - VBのイテレータの構文の対応はVB 11.0 から
    - .NET Framework とVBの対応
     - VB 10.0 : .NET Framework 4
     - VB 11.0 : .NET Framework 4.5

    「Webサイト」プロジェクトと「Webアプリケーション」プロジェクトでの挙動の違いの理由は以下だと思います。

    「Webサイト」プロジェクトの場合は実行環境に.NET FrameworkとともにインストールされているVBコンパイラでコンパイルされることを考慮する必要があり、ターゲットフレームワークが4.0の場合はVB10.0のコンパイラしかインストールされていない可能性を考慮してVS側でエラーにしているのだと思います。

    一方「Webアプリケーション」プロジェクトの場合にエラーにならないのは、おそらくですが、CLR的にはイテレータ自体は.NET Framework 4.0よりも前の時点ですでに対応されているので、ビルド環境でコンパイルさえ通っていれば実行環境に問題ないからエラーにしていない、と思えます。


    きよくらならみ


    • 編集済み Kiyokura 2016年6月23日 0:33 誤字の訂正および表現の変更
    2016年6月22日 8:24
  • Web アプリケーションプロジェクト / Web サイトプロジェクトどちらで作っているのでしょうか?

    Web アプリケーション プロジェクトと Web サイト プロジェクト
    https://msdn.microsoft.com/ja-jp/library/dd547590(v=vs.100).aspx

    質問者さんの上のレスで書かれた 1 が Web サイトプロジェクト、2 と 3 が Web アプリケーションプロジェクトではないかと想像してレスします。

    App_Code フォルダのソースは、サーバーで動的にコンパイルされます。動的コンパイルに使用されるコンパイラに問題がある(バージョンが古い?)ように思われます。

    Web アプリケーションプロジェクトでは、.vb のソースファイルはすべて事前に Visual Studio で単一アセンブリにコンパイルし、その結果できた .dll はアプリケーションルートの Bin フォルダに配置されます。

    2 のようにすると、App_Code フォルダのソースも Visual Studio で他のソースと一緒に単一アセンブリにコンパイルされます。3 が問題ないということですから Visual Studio でのコンパイルは成功しているようです。しかし、実行されるときに、サーバーでさらに動的コンパイルが行われます。その時に問題が起きていると思います。

    (注)Web アプリケーションプロジェクトでは、このような二重コンパイルの問題があるので、そもそも App_Code フォルダは使いません。(一部の例外は除く)

    3 で問題がないのは、フォルダの名前を App_Code ⇒ AddCode に変更したのでサーバーでの動的コンパイルは行わなれなくなったからだと思われます。

    1 は Web サイトプロジェクトだと思いますが、そうだとすると App_Code フォルダのソースはサーバーで動的コンパイルされ、2 と同様にそこで問題が起きたのだと思います。

    2016年6月22日 9:02
  • Kiyokura さん

    自分はサーバーでの動的コンパイルに使うコンパイラのバージョンが古い (Version 10.0 ?) からではないかと思っているのですが・・・

    ASP.NET がサーバーでの動的コンパイルに使うコンパイラは .NET Framework のルート Web.config(%windir%\Microsoft.NET\Framework\framework_version\CONFIG にあります)の中の <system.codedom> 要素の <compiler> 孫要素に設定されているはずです。

    <compiler> 要素
    https://msdn.microsoft.com/ja-jp/library/y9x69bzw(v=vs.100).aspx

    ちなみに自分の環境(Vista SP2, IIS7, VS2010 Pro)では以下のようになっています。

    <system.codedom>
      <compilers>
        <compiler 
          language="c#;cs;csharp" 
          extension=".cs" 
          warningLevel="4" 
          type="Microsoft.CSharp.CSharpCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
          <providerOption name="CompilerVersion" value="v4.0"/>
          <providerOption name="WarnAsError" value="false"/>
        </compiler>
        <compiler 
          language="vb;vbs;visualbasic;vbscript" 
          extension=".vb" 
          warningLevel="4" 
          type="Microsoft.VisualBasic.VBCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
          <providerOption name="CompilerVersion" value="v4.0"/>
          <providerOption name="OptionInfer" value="true"/>
          <providerOption name="WarnAsError" value="false"/>
        </compiler>
      </compilers>
    </system.codedom>

    > 試しにターゲットフレームワークを.NET Framework 4.5に変えてみたら、エラーは表示されなくなりました。

    とのことですから、ターゲットフレームワークが .NET Framework 4 の時は上記の設定が継承され、4.5 の時はアプリケーションルートの web.config に <compiler> 要素が追加され、VB 11.0 のコンパイラがサーバーでの動的コンパイルに使われるのではないかと想像しているのですが。

    もしできましたら、そのあたりを確認していただけると幸いです。


    #ちなみに、以下のスレッドにあるように、Roslyn コンパイラを動的コンパイルに使えるようにするため、Web アプリの bin フォルダに roslyn コンパイラを配置し、サーバーでの動的コンパイルに bin フォルダの Roslyn コンパイラを使うよう、Web アプリの web.config に <system.codedom> 要素が設定されるということもあるそうです。

    ASP.NET MVCのサイトがサーバーで実行できない問題
    https://social.msdn.microsoft.com/Forums/ja-JP/0e8e781a-805c-4e74-8e13-9488dfe84a87/aspnet-mvc?forum=aspnetja

    2016年6月23日 1:50
  • SurferOnWww さん


    すみません、質問者さんの「コンパイルエラーが出る」を「VSでエラー表示になってる」に勝手に脳内で読み替えていました(自分で試しにVSでコード書いたらすぐにエラーが表示されたのでそれに引きずられました)。
    実際にIISで動かしてエラーが出るのであれば、実行環境で実行時にどのバージョンのコンパイラでコンパイルされているかに依存します。
    VSのソリューションファイルとかは関係ない話ですね。


    さて、手元の環境でIISに仮想アプリケーションとしてホストして少し試してみたのですが、実行環境においても厳密にCompilerVersionで指定されているバージョンのコンパイラで動いていないように見えます。
    私の今の手元の4.0, 4.5, 4.1.2, 4.6...と入っている環境では、Web.ConfigのCompilerVersion=4.0となっているにも関わらずYieldを利用したコードもコンパイル・実行できています。
    念のため、Webアプリ側のWeb.Configでsystem.codedomをオーバーライドしても挙動は変わりませんでした。


    .NET Framework 4.xは原則インプレースアップグレードされるので、4.5以降をインストールしたタイミングでのコンパイラ自身もインプレースアップグレードされてるのではないでしょうか。
    挙動からはそういう風に思えます。


    (念のためですが、私が先の投稿で言及していた「ターゲットフレームワークを変えたらエラーが消えた」はあくまでVisual Studioのエディタでの話です。VSのエディタ上で下線+メッセージを出すエラーチェックでは、Web.Configのターゲットフレームワークで指定ではなくソリューションファイルのターゲット指定を見てチェック対処のコンパイラの対応状況を考慮して表示している、という動作だと思います。)


    総合すると以下なのではないかと思っているのですが、今手元に.NET 4.5以降が入っていない環境がないので、2つ目以降は推測です。
    もし検証できたらまた書きます(すぐに検証できるかはちょっと不明ですが)。

    • 「Webサイト」プロジェクトの場合、実行環境に.NET 4.5以降がインストールされて「いる」のであれば、TargetFrameworkやCompilerVersionの指定が4.0であってもVBでYieldを利用したコードもコンパイル・実行できる
    • 「Webサイト」プロジェクトの場合、実行環境に.NET 4.5以降がインストールされて「いない」のであれば、VBでYieldを利用したコードはコンパイルエラーになる
    • 「Webアプリケーション」プロジェクトの場合、実行環境に.NET 4.5以降がインストールされて「いない」場合でも、ビルド環境が4.5以降であればVBでYieldを利用したコード(から生成されたアセンブリ)は実行可能



    きよくらならみ

    2016年6月23日 3:41
  • ありがとうございます。引き続きよろしくお願いいたします。

    私の環境には

    VisualStudio2005(Fw2.0)、2008(Fw3.5)、2010(Fw4.0)、2012(Fw4.5)、2013(Fw4.5.1)までが

    インストールされています。

    yieldはVisualStudio2012から使用できるようになり、Fwのバージョンは関係ないと思っていました。

    ちなみにVisualStuudio2012、Fw3.5でWindowsフォームアプリケーションを作成し

    yieldを使用するコードを書いたところ、コンパイル&実行できました。

    以上のことからApp_Codeフォルダだけが特別で

    動的にコンパイルされるため、コンパイラを推定する際に、

    Fw4.0が指定されている⇒VisualStudio2010⇒yieldはダメってなっているのか!?と思っていました。

    ※あくまでイメージ的にそう感じただけです。確たる証拠も何もありません。

    2016年6月23日 4:27
  • Kiyokura さん>

    返答いただきありがとうございました。VS2012 以降が使える環境を持ってない自分は検証できないので助かりました。

    > 私の今の手元の4.0, 4.5, 4.1.2, 4.6...と入っている環境では、Web.ConfigのCompilerVersion=4.0となって
    > いるにも関わらずYieldを利用したコードもコンパイル・実行できています。

    自分の開発マシン(Vista SP2 32-bit, VS2010 Pro., .NET Framework は下の画像のとおり)という環境で、VB のコンパイラがどうなっているかを調べてみました。

    VB のコンパイラは vbc.exe という名前で、.NET Framework のバージョン別に、以下の画像の通り 4 種類見つかりました。v4.0 用のコンパイラの製品バージョンは 12.0 になっています。(VS2010 しかインストールしてないのに、なぜ 12.0 にアップグレードされているかは不明。.NET Framework 4.5.2 との関係?)

    しかしながら VS2010 上ではエディタレベルでキーワード Iterator も Yeild も認識してくれません(例の青の波線が出ます)。もちろんコンパイルも実行もできません。

    でも、コマンドラインから上記の vbs.exe を使ってコンパイルすると、エラー無くコンパイルは完了し、実行も可能で、結果は期待通りになります。

    Web サイトプロジェクトで作った ASP.NET Web Forms アプリ(全てのコードをサーバー側で動的にコンパイル)も同様で、VS2010 上ではエディタレベルでキーワード Iterator も Yeild も認識してくれませんが、そのページをブラウザから呼ぶと動的コンパイルに成功して、実行結果は期待通りになります。

    というわけで、ここから先は想像ですが、.NET Framework のルート Web.config の中の <system.codedom> 要素の <compiler> 孫要素で、先の私のレスでアップしたように <providerOption name="CompilerVersion" value="v4.0"/> となっていると、上の画像の v4.0.30319 フォルダのコンパイラ(自分の環境では Version 12)を使用して動的コンパイルを行うということでなないかと思います。

    だから、Kiyokura さんの検証で、

    > 「Webサイト」プロジェクトの場合、実行環境に.NET 4.5以降がインストールされて「いる」のであれば、
    > TargetFrameworkやCompilerVersionの指定が4.0であってもVBでYieldを利用したコードもコンパイル・実行できる

    という結果になったのではないかと思われます。

    質問者さんの環境で何故うまくいかないかは謎ですが。

    2016年6月23日 7:59
  • longbridge0 さん

    少し状況を整理したいのですが、「コンパイルエラー」が発生したとのことですが、発生した環境は以下のどちらになりますでしょうか?

    1) VS2012がインストールされている環境(開発環境など)
    2) 上記以外の環境(インストールされている.NET Frameworkのバージョンが知りたいです)

    また環境が 1) の場合、「コンパイルエラー」はどこでどのタイミングで発生している(どこに表示されている)のでしょうか?

    1) Visual Studio 2012 上で「ビルド」を行った際にビルドエラーになる(出力ウィンドウのビルド結果に失敗として表示される)
    2) Visual Studio 2012 からF5などで「実行」を行いブラウザからアクセスしするとエラーとしてブラウザ内に表示される
    3) Visual Studio 2012 のエディタ上で該当箇所に下線とエラー内容が表示される(エラー一覧ウィンドウにもエラー表示される)
    4) それ以外(具体的にタイミングとエラーが表示されている場所ブラウザ or VS、VSであればウィンドウ名などを知りたいです)


    きよくらならみ

    2016年6月23日 8:52
  • きよくらならみ さん

    発生した環境

    1) VS2012がインストールされている環境(開発環境など)

    「コンパイルエラー」はどこでどのタイミングで発生している(どこに表示されている)

    3) Visual Studio 2012 のエディタ上で該当箇所に下線とエラー内容が表示される(エラー一覧ウィンドウにもエラー表示される)

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

    2016年6月24日 0:50
  • 先の私のレスの質問、

    > Web アプリケーションプロジェクト / Web サイトプロジェクトどちらで作っているのでしょうか?

    に答えていただけませんか? また、そのレスでの私の想像、

    > 質問者さんの上のレスで書かれた 1 が Web サイトプロジェクト、2 と 3 が Web アプリケーション
    > プロジェクトではないかと想像してレスします。

    が合っているかどうか、違う場合はどこがどのように違うか教えてください。それによって話が変わってきますので。

    2016年6月24日 3:31
  • SurferOnWwwさん

    すいません。

    > 質問者さんの上のレスで書かれた 1 が Web サイトプロジェクト、2 と 3 が Web アプリケーション
    > プロジェクトではないかと想像してレスします。

    その通りです。

    合ってます。

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

    2016年6月24日 4:03
  • > その通りです。
    >
    > 合ってます。

    そうだとすると、Web サーバー(質問者さんの場合は ASP.NET 開発サーバーまたは IIS Express だと思いますが)上で vbc.exe を使用して動的にコンパイルしているときに、そのコンパイラではサポートされていない Yield が引っかかってエラーになった以外は自分としては考えられません。(Visual Studio 上でコンパイルしている時にエラーになったのではない)

    注: Web サイトプロジェクトでは全てのソースファイルが、Web アプリケーションプロジェクトでもデフォルトでは App_Code フォルダのソースや .aspx, .ascx, .cshtml, .vbhtml ファイルは Web サーバーで動的にコンパイルされます。

    でも、質問者さんの Kiyokura さんへのレスによると、

    > 「コンパイルエラー」はどこでどのタイミングで発生している(どこに表示されている)
    >
    > 3) Visual Studio 2012 のエディタ上で該当箇所に下線とエラー内容が表示される
    >  (エラー一覧ウィンドウにもエラー表示される)

    とのことですので、Visual Studio のエディタや Visual Studio でビルドしているときに検出されたエラーということですよね。

    そうすると、上に書いた「vbc.exe を使用して動的にコンパイルしているときに、そのコンパイラではサポートされていない Yield が引っかかってエラーになった」という話ではなさそうで、どうにも不可解です。

    > 3) Visual Studio 2012 のエディタ上で該当箇所に下線とエラー内容が表示される
    >  (エラー一覧ウィンドウにもエラー表示される)

    という状況でも、先の質問者さんのレスにあった、

    > Webフォームアプリケーションで「App_Code」ではなく「AppCode」フォルダにYieldを使用
    > したクラスを配置すればコンパイル&実行できます。

    ということになるのでしょうか?

    そうだとすると、質問者さんの環境固有の問題(ファイルが壊れているとか)のように思えます。


    • 編集済み SurferOnWww 2016年6月24日 4:36 typo訂正
    2016年6月24日 4:34
  • longbridge0 さん

    であれば、私と似た良いな環境・ほぼ同じ状況ですね。

    今回、longbridge0 さんが見ている「コンパイルエラー」というのは、実際に開発環境にインストールされているVBコンパイラを通した結果出力されたエラーではなく、大雑把に言えば、Visual Studioが「プロジェクトの設定等から想定しているバージョンのコンパイラが対応しているかどうか」をチェックして出しているものです。
    なので、そこでエラーが出ていても、実際に実行してブラウザからアクセスすると実行できるのではないでしょうか。

    これまでのコメントと重複しますが、改めて以下が私の回答になります。
    (根拠になるドキュメントが見つけれてないので挙動からの推測ではありますが、自分としては矛盾点や疑問点は浮かんでこないので納得できる内容と思ってます)

    Webサイトプロジェクトの場合、Visual Studioは「開発環境にインストールされているバージョンのコンパイラではなく、ターゲットのバージョンの.NET Frameworkに同梱されているバージョンのコンパイラでコンパイルできるかどうか」をチェックしてエラーを表示していて、そのため.NET Framework 4に同梱のVB10.0コンパイラでコンパイルできない構文に対してエラーを表示しているのでしょう。
    実際にそのコードを.NET Framework 4までしか入っていない実行環境にリリースした場合、VB10.0で対応していない構文を使えば当然ですが実行時にエラーになりますから、この挙動は正しいと思います。

    対してWebアプリケーションプロジェクトの場合、ターゲットに 4.xが選ばれているればVisual Studioは(インプレースアップグレードされている)最新の4.xに同梱のコンパイラでコンパイルできるかどうかを見ており、そして開発環境に4.5がインストールされていればVB11.0でコンパイルできる構文ならエラーが出ない、ということでしょう。
    この場合はすでにコンパイル済みのアセンブリが実行環境に配置されるので、.NET Framework 4までしか入っていない実行環境にリリースした場合でも、CLR的に対応できている機能しか使っていれば問題ないでしょうから、これも正しい挙動だと思います。

    なお、Webアプリケーションプロジェクトの場合でも、試した限りは「App_Code」配下については、上記の「Webサイト」プロジェクトの場合と同じ仕様でチェックされているようです。
    通常App_CodeフォルダはWebサイトプロジェクト特有でありWebアプリケーションプロジェクトでは利用しないのでこういう動きになってるのでしょうかね(というか、そもそもあまり意図されてないので対応が適当になってるだけのような気がしますが)。
    ※一応、実際に4.5が入った環境でApp_Codeフォルダ以下のコードのビルドアクションをコンパイルに変更することで、ターゲットフレームワーク4.0でもビルドが通って実行もできることは確認しました


    きよくらならみ


    • 編集済み Kiyokura 2016年6月24日 5:14 改行を編集
    2016年6月24日 5:14
  • 質問者さんが見て問題にしているのは Visual Studio 上に表示されるエラーで、Kiyokura さんの説明では、

    > Visual Studioが「プロジェクトの設定等から想定しているバージョンのコンパイラが対応してい
    > るかどうか」をチェックして出しているものです。

    ということですね。

    Kiyokura さんの先のレスにあった、

    > 私が先の投稿で言及していた「ターゲットフレームワークを変えたらエラーが消えた」はあくまで
    > Visual Studioのエディタでの話です。

    はそれを裏付けているようですね。

    そこまでの話なら自分の頭でも理解できるのですが、質問者さんの最初の質問にあった、

    > VisualStudio2012、FrameWork4.0、VBです。
    > ASP.NET Webフォームアプリケーションでは「Yield」が使用できるのですが
    >
    > ASP.NET WebサイトのApp_Codeフォルダ内に配置したクラスでは
    >「Yield」を使用すると「Visual Basic10.0は反復子をサポートしていません。」とコンパイルエラーになります。

    と、その後の質問者さんのレスにあった、

    > ちなみにVisualStuudio2012、Fw3.5でWindowsフォームアプリケーションを作成し
    > yieldを使用するコードを書いたところ、コンパイル&実行できました。

    がどうにも腑に落ちません。

    質問者さんが問題にしているのが「Visual Studio 上に表示されるエラー」であれば、上の全てのケースでその問題が出たのではないかと思われるのですが・・・

    問題(Visual Studio 上に表示されるエラー)は出たけどコンパイルして実行することはできたから、問題にしなかったということなのでしょうか?

    でも、そもそもの問題は、↓ これなんですよね? 

    > ASP.NET WebサイトのApp_Codeフォルダ内に配置したクラスでは
    >「Yield」を使用すると「Visual Basic10.0は反復子をサポートしていません。」とコンパイルエラーになります。

    これは自分の頭ではどう考えても実行前の Web サーバーによる動的コンパイルの時の話としか思えなかったのですが、これも「Visual Studio 上に表示されるエラー」の話だったのでしょうか? これもエラーは出たけどコンパイルして実行することはできたのでしょうか?

    質問者さんが問題にしている「Visual Studio 上に表示されるエラー」は、

    > VisualStudio2012、FrameWork4.0、VBです。
    > ASP.NET Webフォームアプリケーションでは「Yield」が使用できるのですが

    と、

    > ちなみにVisualStuudio2012、Fw3.5でWindowsフォームアプリケーションを作成し
    > yieldを使用するコードを書いたところ、コンパイル&実行できました。

    では出なかったのでしょうか? 出なかったとすると Kiyokura さんの説明と矛盾するように思うのですが・・・

    2016年6月24日 6:24
  • 単にWebサイト(というかASP.NET共通といっていいか)の、App_Codeの動的コンパイルに関するVisual Studioのチェックの特殊な挙動というだけじゃないですかね。

    普通の開発環境上でのVisual Studioの挙動は、前にも書きましたが、ターゲットフレームワークのバージョンにかかわらず、そのバージョンのVisual Studioが対応している言語仕様は使える、という動作です。(試された通りの挙動)

    App_Codeの動的コンパイルコードに対するチェックだけが特殊な動きをしているように見えますし、実際これは通常のVisual Studio上でのコンパイルとは仕組みが異なる(普通のビルドとはちょっと違う)ことから、仕組み上そういうことになってしまっているのだろう、と思える挙動です。

    ややこしい話ではありますが。

    ・Visual Studio上での普通のプロジェクトのコンパイル(Webアプリのこのパイルもこれにあたる)

     ⇒ターゲットバージョンによらず、Visual Studioのバージョンで使える言語仕様はコンパイルできる

    ・App_Codeに配置したコード(動的コンパイル対象)の、Visual Studioによる独自チェック

     ⇒Web.cofigのターゲットフレームワークのバージョンを見て、対応するバージョンのコンパイラでチェックしたような動作をする

    という2パターンだけ、みたいな。(VS上での挙動のパターンの話)


    • 編集済み なちゃ 2016年6月24日 7:27
    • 回答としてマーク longbridge0 2016年6月28日 5:51
    2016年6月24日 7:19
  • はい、結局のところ、なちゃさんのおっしゃてる通りだと思います。

    (一点だけ、少なくとも手元のVS2013では VSはWeb.Configではなくソリューションファイルの TargetFrameworkMoniker 記載のバージョンで挙動を変えているように見えます。が、これも枝葉の話だと思います。)


    きよくらならみ

    2016年6月24日 8:08
  • なちゃさんのコメントを受けて、改めて私の理解をもう少し簡潔にまとめると、以下です。

    1. 通常VSはそのVSで組み込まれたバージョンのコンパイラを基準にエラーなどのチェックを行う
    2. 「Webサイト」プロジェクトの場合、ターゲットのフレームワークに同梱されているバージョンのコンパイラを基準にチェックを行う特殊?対応を行っている
    3. 「Webアプリケーション」プロジェクトでもApp_Codeフォルダのみ「Webサイト」相当のチェックが行われている

    以下補足です。

    • 「2」 のケースではターゲットのフレームワークはWeb.Configではなくソリューションファイル内で管理されている項目で判定しているようです
    • 「Webサイト」プロジェクトの場合、App_Code配下だけでなくほかの場所のコード(例えばコードビハインド)も同様にターゲットのフレームワーク同梱バージョンのコンパイラ基準でチェックされているようです
    • 「3」 についてはMS的にも想定外のパターンの気もしますがまあ通常は実害もないですし(

    きよくらならみ

    • 回答としてマーク longbridge0 2016年6月28日 5:48
    2016年6月24日 8:53
  • Kiyokura さん>

    ということは、Kiyokura さんの先のレスにあった、
     
    > 私が先の投稿で言及していた「ターゲットフレームワークを変えたらエラーが消えた」はあくまで
    > Visual Studioのエディタでの話です。
     
    というのは App_Code フォルダの中のソースに限った話で、その他の場所(例えばページのコードビハンド)ではターゲットフレームワークが 4.0 でもエラーは表示されなかったということでしょうか?

    なので、質問者さんが問題にしている「Visual Studio 上に表示されるエラー」は、

    > VisualStudio2012、FrameWork4.0、VBです。
    > ASP.NET Webフォームアプリケーションでは「Yield」が使用できるのですが
     
    と、
     
    > ちなみにVisualStuudio2012、Fw3.5でWindowsフォームアプリケーションを作成し
    > yieldを使用するコードを書いたところ、コンパイル&実行できました。
     
    では出なかった。そして、質問者さんの問題はここ ↓ にしか現われなかった。
     
    > ASP.NET WebサイトのApp_Codeフォルダ内に配置したクラスでは
    >「Yield」を使用すると「Visual Basic10.0は反復子をサポートしていません。」とコンパイルエラーになります。

    Kiyokura さんの検証結果「ターゲットフレームワークを変えたらエラーが消えた」は App_Code フォルダの中のソースに限った話ということで、矛盾はしてない・・・という理解でよろしいでしょうか?

    2016年6月24日 8:56
  • Kiyokura さん>

    レスが前後してしまいました。まとめをありがとうございます。クリアになりました。

    #Web アプリケーションプロジェクトでも App_Code フォルダを使う場合があるので(カスタム HTML ヘルパーとか)そういうケースで何かの想定があるのかもしれません。

    2016年6月24日 9:33
  • 自分の環境でも検証してみました。一部 Kiyokura さんのまとめとは違う結果「Web アプリケーションプロジェクトでは App_Code フォルダを含め Web サイトプロジェクトのような Visual Studio のチェックはかからない」になりました。

    環境の違い(自分のは VS2010)が結果の違いになっているのかもしれませんが、ご参考に自分の検証結果からのまとめを書いておきます。

    ASP.NET Web Forms アプリの Visual Studio によるエラーチェックは、Web サイトプロジェクト / Web アプリケーションプロジェクトで異なり、以下のようになる:

    (1) Web アプリケーションプロジェクト:Visual Studio のバージョンに該当する VB に準拠(VS2010 なら VB10.0)。App_Code フォルダも同様。

    (2) Web サイトプロジェクト:ターゲットフレームワークに該当する VB に準拠(FW 3.5 なら VB9.0、FW 4 なら VB10.0)


    長くなるので何ですが、上記を裏付ける検証の結果も以下に書いておきます。興味がありましたら読んでいただければ幸いです。

    ・Vista SP2 32-bit
    ・Visual Studio 2010 Professional
    ・ASP.NET Web Forms アプリ

    【Web アプリケーションプロジェクト】
    VS2010 VB10.0 からサポートされた自動実装プロパティ、コレクション初期化子のコードを App_Code フォルダのクラスファイルとページのコードビハインドに配置。

    ターゲットフレームワークが 3.5 でもエディタ上にエラーは出ない。コードビハインドでも App_Code フォルダでも同様(どこにも青の波線は出ません)。インテリセンスも働く。ビルドも通る。(下の画像参照。Class1.vb が App_Code フォルダに置いたクラスファイル。ビルドは通ってます)

    ただし、実行すると App_Code フォルダのクラスファイルの自動実装プロパティ、コレクション初期化子のところでコンパイルエラーが出る(サーバーでの動的コンパイルが web.config の complier 要素の設定に従い VB 9.0 で行われるから)。結果、サーバーエラーとなる。

    【Web サイトプロジェクト】
    ターゲットフレームワークが 3.5 では、上の Web アプリケーションプロジェクトと同様なコードがエディタレベルで VS2010 のエラーチェックに引っかかる(「Visual Basic 9.0 は 自動実装プロパティ をサポートしていません。」等のエラーメッセージが出る)。

    Visual Studio でビルドをかけると[エラー一覧]にエディタで検出されたのと同じエラーが表示される(実際に動的コンパイルはしていないと思われ)。もちろん実行もできない。

    Visual Studio で実行するのでなくブラウザから呼んでみると、Web アプリケーションプロジェクトと同様な結果となる(VB 9.0 で動的コンパイルが行われ、上の画像と同様なサーバーエラーとなる)

    ターゲットフレームワークが 4 なら一切問題なし。


    というわけで、一旦は kiyokura さんのまとめでクリアになったと思ったのですが、質問者さんが問題にしているのが Visual Studio のエラーチェックに限った話だとすると、まだ以下のところが謎です。

    > 2
    > Webフォームアプリケーションで「App_Code」フォルダにYieldを使用したクラスを配置しても
    > 「Visual Basic10.0は反復子をサポートしていません。」とコンパイルエラーになります。

    私の検証結果では(Yield ではないし環境も違いますが)、Web アプリケーションプロジェクトでは Visual Studio からはそのようなエラーは出なかったので。


    • 編集済み SurferOnWww 2016年6月25日 7:28 最初の行訂正:Visual Studio のチェックはかからない ⇒ Web サイトプロジェクトのような Visual Studio のチェックはかからない
    2016年6月25日 5:57
  • みなさま 検証までしていただいてありがとうございました。

    「App_Codeの動的コンパイルに関するVisual Studioのチェックの特殊な挙動」ということで理解しました。

    2016年6月28日 5:53