none
ASP.NET4.0からASP.NET4.6 へ 移行中のWebサイト、 サーバ上で 型付データセットのパーサエラーが発生 RRS feed

  • 質問

  • 開発環境:Windows10/VS2017 本番環境:WindowsServer2016/IIS10.0

    昨日VS2017上で ASP.NET4.6の動作を確認できたあと、一連をWindowsServer2016へ配置しました。

    サーバ上で当該Webサイトをブラウザ実行すると、下記エラーを招いてしまいます。

    何をよりどこりに調査を進めるべきか悩みどころの、パーサエラーが発生しました。

    問題と思われる 型付きデータセットは OracleDatabaseのスキーマからこしらえられたものです。

    【自分の中で、不安視・関係しているかもと思う部分を以下に記載します】

    ・IISが有効になっていながら、当該サーバに.NetFramework4.6が当初セットアップされていませんでした。先にOracleDataBaseを参照するための手続き(ODP.NETのOracle.DataAccess)を優先してしまったので GACに配置されているべきこのdllが 存在していませんでした。なんとか、こちらの記事を参考に慌ててリカバリしました。

    ・Webフォーム同様、App_Codeフォルダ内のDataSet1.xsd(型付データセット)も、当初VS2012で構築した一連としてVS2017へ複写したものです。上記オレンジの枠線内で .NetFramework=4.0 / ASP.NET=4.7と表示されている点は やはり気になっています。 たとえ開発環境(VS2017=IISExpress64でのデバッグ実行)が 正常に動作しようと 新たにデータセットを作り直すことがベターなのでしょうか?

    状況を進展させるため考えられる対策・アドバイスを頂けたら助かります、何卒よろしくお願い申しあげます。

    VS2017の環境(ODAC)

    • 編集済み saya24 2019年10月16日 5:43 開発環境のODAC状況立証
    2019年10月15日 9:23

回答

  • まとめると

    (1) 実行環境で .NET Framework 4.6 を有効化する前に Oracle Client をインストールしてしまった。そのため ODP.NET が正常にインストールされなかった。

    (2) .NET Framework 4.6 を有効化してリカバリしたが、手順に不足があったため、machine.config に必要な情報が書き込まれず、型付データセットのパーサエラーが発生していた。

    (3) machine.config に必要と思われるパラメータを書き込んだら解消した。

    ということでいいんですかね?

    あとは別件と思われるのでクローズしていいと思います。

    ※ 管理対象ドライバは Oracle Client のイントールが不要で、AnyCPU なので 32bit/64bit を気にしないで済みますから、移行するつもりがあれば、お勧めしておきます。


    • 編集済み KOZ6.0 2019年10月21日 0:40
    • 回答としてマーク saya24 2019年10月21日 6:14
    2019年10月21日 0:18
  • まとめると、以下の通りと理解していますがよろしいですか? 理解が違っていたら指摘ください。

    根本的な原因は:

    (1) 運用環境のサーバーの machine.config の DbProviderFactories に Oracle.DataAccess.Client が設定されていなかった。

    (2) 運用環境のサーバーの web.config の connectionStrings セクションの Oracle 用の接続情報で providerName を Oracle.DataAccess.Client とすべきところが、Oracle.ManagedDataAccess.Client になっていた。

    何故エラーになったかと言うと、推測混じりですが:

    (a) 2019年10月19日 4:16 の質問者さんのレスの画像にある「要求された .Net Framework データプロバイダーが見つかりません。これは、インストールされていない可能性があります。」というエラー

    ・・・上記 (1) が原因。そのページで使っている SqlDataSource が GetFactory メソッドで DbProviderFactory を取得できなかった為のエラーと思われる。

    (b) 上記 (1) を処置した後に出てきた「登録されている .NET Framework データプロバイダーが見つからないか、読み込めませんでした」というエラー

    ・・・上記 (2) が原因。web.config の providerName に設定されている Oracle.ManagedDataAccess.Client を探しに行ったと思われる。

    (c) このスレッドの一番最初の質問のパーサーエラー

    ・・・デプロイ後の一番最初の要求で、サーバーが web.config の接続情報に基づき DB に接続して型付 DataSet + TableAdapter のコードを自動生成するが、上記 (1), (2) の問題で DB に接続できなかったためと思われる。

    対処方法は:

    問題なく動く開発マシンの machine.config から運用環境のサーバーの machine.config に差分をコピー。運用環境のサーバーの web.config の接続情報の providerName を Oracle.DataAccess.Client に訂正。

    結果、上記 (a), (b), (c) のエラーは解消。

    上記理解が合っていたら早急にクローズしてください。
    • 編集済み SurferOnWww 2019年10月21日 2:31 誤字訂正
    • 回答としてマーク saya24 2019年10月21日 6:15
    2019年10月21日 2:00

すべての返信

  • 質問者さんは Teratail のスレッド https://teratail.com/questions/216797 で質問している人ではないのですか? もし違ったら失礼しました。でも、同一人物だとすると、Teratail のスレッドは放置・放棄ですか?
    2019年10月15日 9:31
  • SurferOnWwwさん お世話になります。同一人物です。混乱を与え申し訳ございません。

    放置するつもりはないのですが、Teratail側の内容は壁にぶつかる以前の問合せで具体性がない・解決したい課題が幅広く回答しにくい、と解釈しまして 分割させて頂きました。

    とるべき行動が明らかになったらお役に立てるよう 自分の作業過程を追記してクローズしようとは思っていました。

    2019年10月15日 9:57
  • 今 エラーが表示されているDataSet1.xsdは ReportViwerのデータソース=ObjectDatasourceに適用しているDataSetです。もしやこれを作り直す必要があるのでは??と、新たにツールボックスから貼り付けて生成し ObjectDataSourceへ適用しなおしました。

    しかし状況はかわらず 同じパーサエラーを招いています。一応IISは再起動しましたが。

    サーバのセットアップに問題があったのか、構築物に問題があるのか せいぜい見極めたい ところなのですがねぇ....

    2019年10月15日 11:36
  • https://codeday.me/jp/qa/20190327/483752.html 現在現れている事象と大変似た記事をみつけました。私がパーサーエラーの具体的内容を把握できていないのは、ここで紹介されたようなログの所在を把握していない為です。 どこをみればこのようなログを確認できるのでしょうか?イベントログ?
    • 編集済み saya24 2019年10月16日 0:41 誤記
    2019年10月16日 0:40
  • > とるべき行動が明らかになったらお役に立てるよう 自分の作業過程を追記してクローズしようとは思っていました。

    「お役に立てるよう」というのは誰のお役に立てると考えておられるのでしょう?

    質問者さんは以前から放置する・・・とまでは言わなくても長期間音沙汰無しにする・・・ということが多かったと記憶しています。

    私に配慮いただけるなら、そういう点を直していただけると、大変「お役に立てる」のですが。

    Teratail の方からこちらに Q&A の場を移すことには異論はありませんが、そうするのであれば Terateil の方にはその旨書いてクローズしてください。
    • 編集済み SurferOnWww 2019年10月16日 1:59 誤字訂正
    2019年10月16日 1:41
  • 6 年前に全く同じ問題に遭遇したのでは?

    コードを生成できませんでした。種類 'System.Data.Design.InternalException' の例外がスローされました。XSDがらみのエラー
    https://social.msdn.microsoft.com/Forums/ja-JP/afbcfa4e-9be4-45d6-971b-6b13141eba0d/12467125401248912434299832510412391123651241412379124351239112?forum=aspnetja
    2019年10月16日 1:49
  • Oracle.ManagedDataAccess ではなく、Oracle.DataAccess なのですね。

    新規に、『SELECT * FROM DUAL』するだけの 型付 DataSet を持った ASP.NET アプリケーションを作成した場合、それは動作するのでしょうか。

    動作しない場合はサーバー環境の問題である可能性が高まりますし、動作するなら現在のプロジェクト固有の問題である可能性が考えられます。 

     

    また、エラーメッセージで検索してみたところ、デザイン時の話ではありますが、このような情報がありました。blog システムの都合で XML が不可視になっていますが、HTML ソースを読んでみると、どうやら <Connections><Connection ~/></connections> を、一時的に <connections /> に変更するということのようです。

    ここでいう Connection 要素は、web.config 内の <connectionString> のことではなく、型付 DataSet の xsd 内に埋め込まれている情報であることに注意してください。xsd 内の Connection の場合は PropertyReference 属性を含んでいるため、ターゲット フレームワークの更新時にプロジェクト名を変更していた場合、PropertyReference の更新漏れが発生してしまっているかもしれません。

    2019年10月16日 1:51
  • 魔界の仮面弁士さん ご見解ありがとうございます。

    一応VS2012から移行してきたデータセットとは別のデータセットをこしらえ、それをObjectDataSetに適用してサーバへDeployしてみましたが(VS2017上ではなんら問題なく動作します)、同じパーサエラーを招いています。

    ですが、仰られたこと、本日確かめてみようと思います。後ほど返答を改めます。

    下段で述べられていること、難しそうで まだ当方理解ができていません...。先に分かりやすいところから潰しますね。

    2019年10月16日 2:41
  • IISが有効になっていながら、当該サーバに.NetFramework4.6が当初セットアップされていませんでした。

    Windows Server 2016 には既定で .NET Framework 4.6.2 が同梱されていますが、それが有効化されていなかったということですね。(Windows Server 2016 に対して、.NET Framework の 4.7 / 4.7.1 / 4.7.2 / 4.8 を上書きインストールすることもできます)

     

    一応VS2012から移行してきたデータセットとは別のデータセットをこしらえ、それをObjectDataSetに適用してサーバへDeployしてみましたが(VS2017上ではなんら問題なく動作します)、同じパーサエラーを招いています。

    既存プロジェクトに DataSet を作るのではなく、新規プロジェクトでも失敗しているのであれば、ソースではなくサーバー側の環境構築上の問題かもしれません。確証は持てませんけれども。

     

    それと、Oracle Database Server のバージョンと Oracle.DataAccess のバージョンが分かれば、念のためにそれらも教えてください。

    また、Oracle.DataAccess の場合は Web サーバー上に Oracle Client が必要かと思います。Oracle のライブラリは 32 bit / 64 bit とで別管理となっていますので、その違いにも気をつけてみてください。(念のため、VS2017 上と実環境とで IntPtr.Size の値を確認しておいた方が良いかも知れません)

    2019年10月16日 3:14
  • 気にかけて頂き、本当にありがとうございます。

    >Oracle Database ServerとOracle.DataAccess のバージョン

    DB(WindowsServer2008R2): 11g 11.2.0.1.0

    DataAccess(開発環境Windows10=VS2017): 12.2.0.1.0を、x86とx64の両方、この点 本文末尾に画像を追加致しました。

    DataAccess(運用環境WindowsServer2016): 12.2.0.1.0、こちらはwinx64_12201_clientのsetup.exeを管理者として実行して入ったものです。このServerから別筐体である11gDBへの接続はSQLPLUSで接続を確認できています。逆にいうと、.NETFramework有効化の忘却がまさにその現れですがこれを活用した接続に未だ確証を得ていない、ということだと思います....

    あるWebフォームのコードに、以下コードを織り交ぜて、VisualStudioでデバッグして、64bit動作していることを確認しました。(ステップ実行で開発環境:VisualStduioでは通過点を見極めました。本来 どこにこの結果は表されているのでしょう、差し支えなければ教えてください。いつもSystem.Diagnostics.Debug.Print()で出力子画面に現れるようにしています。 ま、IntPtr.Sizeというキーワードで検索し即効コピペしたわけで)

    If IntPtr.Size = 4 Then
        Console.WriteLine("32ビットで動作しています")
    ElseIf IntPtr.Size = 8 Then
        Console.WriteLine("64ビットで動作しています")
    End If

    運用環境:WindowsServer2016での上記コーディングの結果を知るには どこを確認すれば分かるのでしょう?質問がズレてすみません。



    • 編集済み saya24 2019年10月16日 5:46 誤記訂正
    2019年10月16日 5:40
  • DataAccess(開発環境Windows10=VS2017): 12.2.0.1.0を、x86とx64の両方、この点 本文末尾に画像を追加致しました。

    うまく挿入できていなかったようですが、こちらの画像ですね?
    https://social.msdn.microsoft.com/Forums/getfile/1493244

    …失礼しました。返信部の本文末尾ではなく、最初の質問の本文末尾ということだったのですね。

     

    Console.WriteLine("64ビットで動作しています")

    実際の IIS 環境で試すのであれば、Console を使うのではなく、結果を Response.Write するための実験用の Web ページを用意した方が手っ取り早いでしょう。判定結果を返却する Web API を用意する形でも良いですが。


    2019年10月16日 6:11
  • 一応確認させて頂けないでしょうか?
    新規Webページでの検証(x64動作 VS x86動作の見極め)は
    VS2012からVS2017へ移行してきた問題のプロジェクト内に設けて行うのが妥当か?新規プロジェクト内で行うのかが 分からなくなってきました。

    新規プロジェクト内で一先ずOracleDBの成果物(SELECT * FROM DUAL云々)を作ってみる、というチャレンジをご提案頂いており
    こちらと混乱してきてしまっていて...。

    (でも...64マシンで32bit動作している点もあり得なくない、という払拭を晴らすとなれば
    魔界の仮面弁士さんは 既存プロジェクトに焦点を宛てていることになるなぁ)

    ごめんなさい、突如心に浮かびましたもので 記載します。
    IISのDefaultAppricationPoolが、.NetFramework4.6になっているのか 多少気になります....この点含め返答改めます。

    2019年10月16日 6:49
  • 上記オレンジの枠線内で .NetFramework=4.0 / ASP.NET=4.7と表示されている点は やはり気になっています。

    前半部が 4.0.30319 になることは正常かと思います。

     

    新たにデータセットを作り直すことがベターなのでしょうか?

    既存の Web サイトに作り直すのではなく、新規に実験用の Web サイトを作り直し(ReportViewer も使わない)、そこで実験しても同じエラーになったとのことでしたので、単純に .xsd を作り直すだけでは、また同じ結果になりそうです。

     

    デプロイ先サーバーのデスクトップにアクセスする権限がある場合は、現在の「IIS + 型付 DataSet」の構成を試す前に、「コンソールアプリケーション + 素の System.Data.DataSet 」での接続実験をそれぞれ行って、.NET Framework からの接続が行えていることを確認しておいてください(C# でも VB でも良い)。これが NG なら、本番環境の設定を見直す必要があるでしょう。

    素の DataSet ではアクセスできるようであれば、それを型付 DataSet に差し替えてもう一度実行し、System.Data.Design.InternalException が再現するかを確認してみてください。ここで再現しないなら、IIS からアクセスした場合の固有の問題(たとえば権限とか)が原因かもしれません。

    2019年10月16日 6:52
  • こちらにも図が貼れるのですね、大変失礼しました。
    また、ご提案の確認作業の順番が前後して申し訳ありません。取り急ぎ、先に伝えたIISのDefaultAppPoolの状況です。
    これってやはりまずいんでしょうか? 全然4.6という文字が見受けられませんね。
    この度VS2017からアップしたASP.NETのWebサイトは DefaultAppPoolを選択しています。

    八次納屋にこちらから上記を伝えてしまいましたが、仰られることがよく理解できました。
    いきなりピカシンのIISで、難易度高め?!の型付データセットを有すサイトの移行から手をつける必要はなかったかも知れませんね。
    自分の中に時間のかかる課題という認識があって、先に着手したのですが、
    コード内でデータセットを仕上げるタイプの成果物がうまく動作しない環境で、型付データセットの成果物などうまくいく筈がありませんね。納得!

    一先ず、図をご確認頂いて コメントを頂けたら幸いです。

    2019年10月16日 7:51
  • 全然4.6という文字が見受けられませんね。

    その点は問題無いと思います。

    今回貼っていただいた画像の列タイトル部を見ると「.Net CLR バージョン」と書かれているかと思います。(Server 2012 などでは、「.NET Framework バージョン」だったのですが)

    アプリケーション プールで指定されるのは、実際には .NET Framework のバージョンではなく、CLR(共通言語ランタイム)のバージョンとなります。手元に Server 2016 環境が無いので確認できませんが、指定できるのは恐らく以下のいずれかだけでしょう。

    • "v4.0" もしくは ".NET Framework v4.0.30319"
      もしくは ".NET CLR バージョン v4.0.30319"
    • "v2.0" もしくは ".NET Framework v2.0.50727"
      もしくは ".NET CLR バージョン 2.0.50727"

     

    -- 追記 --

    手元に IIS 10.0 環境が無いので、IIS 8.x 環境で確認してみました。
    現在のバージョンでは「CLR」表記で統一されているのではないでしょうか。


    2019年10月16日 8:00
  • 即答ありがとうございます、励みになります。

    それではコーディングによるデータセット生成からデータを表す何かを作る検証に注力していきます。
    (IISの不安は 回答いただく迄 気が散っていました...)


    たしか過去に作ったことのあるコンソールアプリが幾つかあった筈...これを動作環境で動かしてみます。

    MS SQLServerだけをDBに利用したコンソールアプリ①を運用環境で動作させてみる。
    うまくいったら、続いてOracleもDBに利用したコンソールアプリ②を運用環境で動作させてみる。
    うまくいったら、MS SQLServerだけをDBに利用した簡易ASP.NETサイトを作って様子をみてみる
    (DownDownListかGridViewなどでデータを表す)
    ... こんな感じで やっていきます。

    2019年10月16日 8:32
  • 途中経過を報告します。.NETFramework4.6のコンソールアプリケーションとして

    ①MSSQLのみををDBに利用したものを運用環境で実行、->成功

    ②OracleDatabaseも利用したものを運用環境で実行、 ->一時失敗も最終的に成功。

    当初の実行でx86のODACを読み込もうとする雰囲気のエラーを出力。VS2017で再度 参照追加をやり直し無事問題を回避。
    (VS2017でODACを参照追加した際、参照マネージャの選択可能アセンブリに表れるのは基本x86のみであることを悟る。
    あえてx64アセンブリの所在を指定する方式で参照追加をやり直し&リビルドして、運用環境で実行したら成功した)

    ③問題のASP.NETのプロジェクトで、上記②の教訓を元にODACの参照を確認すると、案の定同じミスをしていた。
    即座に参照をx64に切り替え、運用サーバにDeployしなおす、->失敗、パーサーエラーの表示。IISと電源再起動も同様。

    ④VS2017で、別プロジェクト名のWebサイトを再作成。ODACの正しい参照追加に気を付け、
    型付きデータセットを作り直して、ObjectDataSource(ReportViewer)に適用。開発環境VS2017でのデバッグ実行、->成功。
    運用環境での実行->失敗、パーサーエラーの表示。IISと電源再起動も同様。

    ②で明らかな問題点を発見して、調子にのり、OracleDatabseを型付きデータセットで参照するASP.NETに再チャレンジしましたが
    そうは問屋が卸さず失敗しました。
    今日はこの辺りで...

    ASP.NETの詳細なログは どこかに表れているのでしょうか? この方は取得されているようですね機械翻訳っぽい
    ちなみに、運用環境での実行、初期ページさえも表すことができないのが私の状況です。初期ページはOracle利用していません。

    2019年10月16日 16:31
  • > ④VS2017で、別プロジェクト名のWebサイトを再作成。ODACの正しい参照追加に気を付け、
    > 型付きデータセットを作り直して、ObjectDataSource(ReportViewer)に適用。
    > 開発環境VS2017でのデバッグ実行、->成功。
    > 運用環境での実行->失敗、パーサーエラーの表示。IISと電源再起動も同様。

    結局一番最初の質問に戻ったという感じですね。

    現在の運用環境の 2008R2 は 64-bit OS しかないので、②、③は現状で対応できていたはず、即ち分かっていたはずのこと。迷走していませんか?

    一番最初の質問の問題は、上の私のレスで、質問者さんが 6 年前に遭遇した 2008R2 への移行時の問題(URL 下記に再掲)と同じと指摘しましたが読みましたか?

    コードを生成できませんでした。種類 'System.Data.Design.InternalException' の例外がスローされました。XSDがらみのエラー
    https://social.msdn.microsoft.com/Forums/ja-JP/afbcfa4e-9be4-45d6-971b-6b13141eba0d/12467125401248912434299832510412391123651241412379124351239112?forum=aspnetja

    そのスレッドのやりとりは結局話が噛み合わなくて、私の回答が当たりだったかどうかは不明ですが、App_Code を使っているということは Web サイトプロジェクトを使っているはずで、上のスレッドで私が指摘したことは十分可能性があると思うのですけど。

    ハズレだったとしても、とにかく問題は解決できて、その時の課題の「Webサイトを2008R2のWebサーバーに移行」はできたから今があるのですよね。(Teratail の話は「運用環境の移行として、WindowsServer2008R2からWindowsServer2016」と言うことで、今は 2008R2 で無事運用できていると理解)

    であれば、6 年前の 2008R8 への移行時に取った対応を思い出せば良いのでは?

    レスにフィードバックしないということは無視=不要ということ? それならそれで良いので、その旨フィードバックできませんか?


    • 編集済み SurferOnWww 2019年10月17日 1:38 訂正
    2019年10月17日 1:35
  • SuferOnWwwさん いつもお世話になっております、過去から現在に亘り、幅広いご支援 本当に感謝しています。

    どういう解決策をとったのか思い出せず、後回しにして 関係性を見出そうとしなかったのは事実です。決して無視をしたのではないのですよ、目前の課題・見極めに夢中になってしまったのです。ご容赦ください。

    冷静になって当時 どう解決したか記憶を辿ると...WindowsServer2008R2:64bit筐体ながら、型付データセットを含むASP.NET4.0サイト運用のため、私のほうでODACを やむなく32bitを追加セットアップしたことを思い出しました。

    また、その後暫くして 当該筐体がSQLServerを兼ねていることもあり、こちらからOracleのデータ取得を行う手続きを開発した際に、敢えて32bit挙動を選択する必要があることに気が付けづ 非常に悩まされたことも覚えています。

    当時私は解決策=型付きデータセットを含むASP.NETサイトの運用でも、32bitのODACは当該環境に不要、という追求を諦めたのですが

    これは必然の結果だったのでしょうか? 希望はx86のODACを追加セットアップしない運用ですが、方策はあるのでしょうか....ご存知であれば ご見解をお願いします。

    2019年10月17日 3:53
  • > 目前の課題・見極めに夢中になってしまったのです。ご容赦ください。

    「レスはもらった、今別の検討をしているのでちょっと待ってほしい」ぐらいの返事はできるのでは?

    レスにはきちんとタイムリーにフィードバックを返さないなら、今後は当方から無視させてもらいます。


    > これは必然の結果だったのでしょうか?

    分かりません。

    が、少なくとも、6 年前のスレッドと今回のスレッドのパーサーエラーの原因と、質問者さんが気にしている ODP.NET の 32/64-bit の話は関係ないと思います。そこは自信度 99% ぐらい。

    Web サイトプロジェクト(ですよね?)は、最初の要求を受けたときにサーバー側でコンパイルします。上のレスで質問者さんが「運用環境での実行、初期ページさえも表すことができない」と言っている理由は、たぶんコンパイルすらできてないからでしょう。

    ODP.NET の 32/64-bit の件はコンパイルできてからの問題です。コンパイルできて実行できて、Web アプリから ODP.NET を使って Oracle にアクセスに行ったときに、もし 32/64-bit の不整合があれば、そこで初めて出る問題です。

    Web サイトプロジェクトでは .xsd ファイルを App_Code フォルダに置きますが、初回アクセス時にサーバーで .xsd ファイルから型付 DataSet + TableAdapter のコードを生成して Temporary ASP.NET Files に配置し、コンパイルして .dll を作成という操作を行います。ソリューションエクスプローラーに .Designer.cs というファイルは見当たらないでしょ? 開発マシンの Temporary ASP.NET Files を探せばそこに見つかるはず。

    型付 DataSet + TableAdapter のコードを生成する際 DB に接続して必要な情報を得ます。しかし、運用環境では、その時、接続文字列の不正その他何らかの問題で DB に接続できずパーサーエラーとなったと思われます。

    結果、それ以外のファイルもコンパイルできず「運用環境での実行、初期ページさえも表すことができない」ということになっているのではないかと思います。

    まずはそのあたり、特に「接続文字列の不正その他何らかの問題で DB に接続できず」を確認するのがまず第一に質問者さんがやることだと思います。

    他に、型付 DataSet + TableAdapter を Web アプリと同じソリューション下に別プジェクトとして作り、それを Web アプリのプロジェクトから参照設定してみるという手もあるかと思います。

    そうすれば、型付 DataSet + TableAdapter のコードは .Designer.cs に Visual Studio で生成され、コンパイルされ、その .dll が Web アプリの bin フォルダにコピーされて配置されるので、少なくとも今回のパーサーエラーは回避できると思います。

    試してみてはいかが?


    • 編集済み SurferOnWww 2019年10月17日 7:15 誤字訂正
    2019年10月17日 7:03
  • 度重なる不手際申し訳ございません、早速返信まで時間を要してしまいお詫び申しあげます。

    >ODP.NET の 32/64-bit の話は関係ないと思います。そこは自信度 99% ぐらい。

    頼もしいご意見で、絶望感から救われた気持ちになりました。勝手に期待してしまう私ですが。

    >Web サイトプロジェクト(ですよね?)

    ファイル->新規作成->プロジェクト->画面左からVisualBasic/Web/以前のバージョン->ASP.NET空のWebサイト を選択して作成しだした.NETFramework4.6のプロジェクトです。

    >ソリューションエクスプローラーに .Designer.cs というファイルは見当たらないでしょ?

    見当たりません、自分はVB.NETですが、.vbでもらしきファイルは確認できません。

    >開発マシンの Temporary ASP.NET Files を探せばそこに見つかるはず。

    開発マシンで当該名のフォルダは3つ確認できました。中身が入ったフォルダはこのうちの一つ、皆まで書きませんがC:\ユーザー\XXXXXXX\App_Data\local\Temp内の一つでした。一応ご報告します。

    >型付 DataSet + TableAdapter のコードを生成する際 DB に接続して必要な情報を得ます。しかし、運用環境では、その時、接続文字列の不正その他何らかの問題で DB に接続できずパーサーエラーとなったと思われます。

    調査範囲を狭めることに手をこまねき、中々解決へ結びつく行動・見極めを行えない私にしてみれば非常に有りがたいご見解です、たとえそれが確定情報でないにせよ。

    >特に「接続文字列の不正その他何らかの問題で DB に接続できず」を確認するのがまず第一に質問者さんがやることだと思います。

    内容了解しました。パーサエラーに現れたDataSet1の接続文字列=Web.Configに定義された接続文字列について 確認を行っている最中です。 SQLPLUSという.NETとはかけ離れたOracleClient側のユーティリティでは 無事OracleDatabaseへの接続を確認できました。これで接続できてもねぇ....という状況なのですよね???

    正直申しあげます、ご提案を頂きました 最後の

    型付 DataSet + TableAdapter を Web アプリと同じソリューション下に別プジェクトとして作り、それを Web アプリのプロジェクトから参照設定してみるという手

    は 私の理解力では 難しく まだ手が出そうにありません。もう暫く、接続部分で誤った定義がないか確認を重ねてみます。すみません

    2019年10月17日 10:19
  • > ファイル->新規作成->プロジェクト->画面左からVisualBasic/Web/以前のバージョン->ASP.NET空のWebサイト を選択して作成しだした.NETFramework4.6のプロジェクトです。

    自分の VS2015 で「ファイル->新規作成->プロジェクト」という手順だと「Web アプリケーションプロジェクト」が生成されます。

    最後に出てくるという[ASP.NET空のWebサイト]は、自分の VS2015 では[ファイル]⇒[新規作成]⇒[Web サイト]という「Web サイトプロジェクト」を作る手順で出てくるものなので、VS2017 では手順が違うのかもしれませんが。

    手順を書かれても分かりません。質問者さんの環境で生成された結果としてのプロジェクトを見て「Web サイトプロジェクト」なのか「Web アプリケーションプロジェクト」なのか確認してください。

    もし、質問者さんが VS2017 で作っているのが「Web アプリケーションプロジェクト」であるとすると、一番最初の質問に書いてあった、

    > App_Codeフォルダ内のDataSet1.xsd(型付データセット)も、当初VS2012で構築した一連としてVS2017へ複写したものです。

    がそもそもの間違いです。

    「Web アプリケーションプロジェクト」では App_Code フォルダは使いません。二重コンパイルの問題があるので。

    それでも .xsd ファイルだけコピーして開発マシンでは動いたということであれば、摩訶不思議ですが。

    何にせよそういう普通でないことをしてそれをベースに話をしても仕方がないので、質問者さんが VS2017 で作っているのが「Web アプリケーションプロジェクト」であれば App_Code フォルダは削除して DataSet はアプリケーションルート直下にでも新たに作り直すか、「Web アプリケーションプロジェクト」で開発するのは止めてゼロから「Web サイトプロジェクト」を作るところからスタートしてください。

    話はそれからにした方がよさそうです。
    2019年10月18日 3:27
  • OracleDatabaseの接続に関する異常を見つけられず、今朝から新規Webサイトのプロジェクト:GridViewを配置しただけのWebページで検証を開始しています。
    只今検証を終えたので、それら結果を一応に共有させて頂きます。ご見解を頂けたら幸いです。

    検証①:
    新規プロジェクトAに、GridViewを配置したWebフォームを用意。当該GridViwerのデータソースはSQLDataSource。
    そのSQLDataSourceは MSSQLServer内のあるDBのある一テーブル全行表示するもの。ウィザードに従い簡易作成。
    【結果】
    開発環境(Windows10/VS2017:デバッグをIISExpress 64bit実行)--->無事画面に結果現れる。
    運用環境(WindowsServer2016/IIS10.0))--->無事画面に結果現れる。

    検証②:
    新規プロジェクトBに、GridViewを配置したWebフォームを用意。当該GridViwerのデータソースはSQLDataSource。
    そのSQLDataSourceは OracleDatabase11g内のあるDBの一テーブル全行表示するもの。ウィザードに従い簡易作成。一度運用環境へDeployしての実行時、プロバイダ見つからないのエラーが出たのでプロジェクトにOracle.DataAccess.dll x64を参照追加。

    【結果】
    開発環境(Windows10/VS2017:デバッグをIISExpress 64bit実行)--->無事画面に結果現れる。
    運用環境(WindowsServer2016/IIS10.0))--->下記画面のエラー。

    運用環境で表示に失敗するWebフォーム.aspxは以下です。接続文字列:ConnectionStiringはWeb.Configに記載してあります。

    <%@ Page Language="VB" AutoEventWireup="false" CodeFile="Trial.aspx.vb" Inherits="Trial" %>
    
    <!DOCTYPE html>
    
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head runat="server">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
        <title></title>
    </head>
    <body>
        <form id="form1" runat="server">
            <div>
                <asp:Label ID="LB01" runat="server" ForeColor="#FF3300" Width="200px"></asp:Label>
                <br />
                <asp:GridView ID="GridView1" runat="server" AllowPaging="True" AllowSorting="True" AutoGenerateColumns="False" CellPadding="4" DataKeyNames="保冷区分" DataSourceID="SDS01" ForeColor="#333333" GridLines="None" Width="438px">
                    <AlternatingRowStyle BackColor="White" />
                    <Columns>
                        <asp:CommandField ShowSelectButton="True" />
                        <asp:BoundField DataField="保冷区分" HeaderText="保冷区分" ReadOnly="True" SortExpression="保冷区分" />
                        <asp:BoundField DataField="保冷区分名" HeaderText="保冷区分名" SortExpression="保冷区分名" />
                    </Columns>
                    <EditRowStyle BackColor="#7C6F57" />
                    <FooterStyle BackColor="#1C5E55" Font-Bold="True" ForeColor="White" />
                    <HeaderStyle BackColor="#1C5E55" Font-Bold="True" ForeColor="White" />
                    <PagerStyle BackColor="#666666" ForeColor="White" HorizontalAlign="Center" />
                    <RowStyle BackColor="#E3EAEB" />
                    <SelectedRowStyle BackColor="#C5BBAF" Font-Bold="True" ForeColor="#333333" />
                    <SortedAscendingCellStyle BackColor="#F8FAFA" />
                    <SortedAscendingHeaderStyle BackColor="#246B61" />
                    <SortedDescendingCellStyle BackColor="#D4DFE1" />
                    <SortedDescendingHeaderStyle BackColor="#15524A" />
                </asp:GridView>
                <asp:SqlDataSource ID="SDS01" runat="server" ConnectionString="<%$ ConnectionStrings:ConnectionString %>" ProviderName="<%$ ConnectionStrings:ConnectionString.ProviderName %>" SelectCommand="SELECT * FROM &quot;C_HORE&quot;"></asp:SqlDataSource>
            </div>
        </form>
    </body>
    </html>

    取り急ぎご報告させて頂きます。先日コンソールアプリケーションでOracle.DataAccessを利用したアプリの実行に成功していますが、ASP.NETでの検証がまだでしたので行いました。今回SQLDataSourceの内容設定をデザイナで仕上げてしまいましたが、コーディングで設定するパターンも試そうか 迷っているところです。

    運用環境となるWindowsServer2016は まだ一つのサイトもアプリも載っていない状況です。ODACと.NETFrameworkの設定順序を誤った経緯を考慮すると、環境構築しなおしも「あり」でしょうか....

    有識者の皆様、ご助言を頂けましたら幸いです。もう心が折れそうで....


    • 編集済み saya24 2019年10月18日 3:40
    2019年10月18日 3:35
  • SuferOnWwwさん、大変失礼しました。 たった今、お返事を頂いていたことに気がつきました。一番下ばかりみていて、、、、 ずばり自分のプロジェクトが、Webサイトプロジェクトなのか、Webアプリケーションプロジェクトなのか分かっていない為に手順を記載したわけですが、相変わらず分かっていない人物だとバレてしまいましたね。(この質問は過去にもよく登場しています、とても大事なことなのでしょうね) 分かりやすくVS上で記されていると良いのですが。まず、この点を確認します。たしか…、新規プロジェクトとして作り直す方法もトライしていた中で、データセットを一から作ることもチャレンジして この時に当初ソリューションエクスプローラに表示されていなかったApp_Codeのフォルダが自動でできたような記憶が。「そのコントロールは特殊のため〜」云々のメッセージが現れて ここに収まった記憶があります。 下で検証した簡易なWebフォームのみのプロジェクトも、同じ操作から作成したものです。WebフォームにGridVIewとそのSQLDataSourceがあるだけのデザインです。まだこのプロジェクトのソリューションエクスプローラにはApp_Codeのフォルダがありません。今からこのWebフォームのデザインにDataSetを貼り付けてみます。ひょこっとこのフォルダが現れば「Webサイトプロジェクト」という判断でよろしいでしょうか?? 確認後のお返事は明日になってしまいそうです。まずはご見解に対する御礼と、対応遅延のお詫びまで
    2019年10月18日 14:46
  • 2点確認してみてください。

    (1) %windir%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config に
    「oracle.dataaccess.client」の記述はありますか?

    configSections と DbProviderFactories の2個所に記述があるはずです。

    参考にされた URL
    「ODP.NETのGAC登録」
    http://www.meeks.jp/archives/5907

    では .NET 2.0/3.5 用 ODP.NET の登録しかしていません。

    存在しないようであれば ORACLE_HOME の ODP.NET\bin\4 フォルダに対しても同様の操作が必要になります。

    (2) 接続文字列の Data Source を「DBサーバの IPアドレス/SID 名」(例:192.168.0.1/ORCL) にするとうまくいかないでしょうか?

    外していたらごめんなさい
    2019年10月18日 16:25
  • > 検証②:
    ・・・・
    > 運用環境(WindowsServer2016/IIS10.0))--->下記画面のエラー。

    状況が悪くなっているようですね。

    このスレッドの一番最初の記事では、(1) ブラウザから Web サーバーに接続でき、(2) ブラウザは要求を Web サーバーに送ることはできており、(3) Web サーバーは要求を受け取って処理を始めています。処理しているときにエラーになって望む結果は返って来なかったということではありますが。

    「下記画面のエラー」の内容から見ると (1) すらできていないようで、Web アプリの作り方がどうの ODP.NET がどうの以前の問題があるようです。

    エラーメッセージの「このページは表示できません」でググって調べて対処して、とにかく (1) ができるようにしてください。

    • 編集済み SurferOnWww 2019年10月19日 0:41 誤字訂正
    2019年10月19日 0:41
  • 「Web サイトプロジェクト」と「Web アプリケーションプロジェクト」の違いについては以下の記事を見てください。(前にも紹介したような気がしますけど・・・)

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

    記事に書いてありますが、プロジェクトファイルの構造の違いとして「Visual Studio プロジェクト ファイル (.csproj または .vbproj) 」の有無があります。質問者さんの環境で生成された結果としてのプロジェクトを見て調べてください。

    ソリューションエクスプローラーを見ても分かると思います。以下の画像の赤枠で囲ったフォルダ・ファイルがあれば「Web アプリケーションプロジェクト」です。無ければ「Web サイトプロジェクト」です。


    • 編集済み SurferOnWww 2019年10月19日 1:23 リンク設定
    2019年10月19日 1:18
  • お待たせして申し訳ございませんでした。また、プロジェクトの種類の見極め方法を分かりやすく提示頂きましてありがとうございます。早速ですが、
    下記で検証しているコンパクトなプロジェクトも、話しの発端となっているプロジェクトも、
    Webサイトプロジェクトという判断を下して良さそうです。下の画像ご確認頂けたら幸いです。今から運用環境側で「ページが表示されません」の要因を調べてみます。
    混乱してURL違いとか起こしてたりしないか...

    2019年10月19日 3:27
  • 早速お詫びしなければならない点を見つけました。IISを見たら正常な表示をしていません。今から詳細確認させて頂きます。「再起動」との表示で、IISは稼動していると、安心しきっていましたが 何か問題がある様子
    取急ぎ、状況が悪くなっていると、ご心配をおかけしてしまったことに対しお詫びとご報告です。


    • 編集済み saya24 2019年10月19日 3:41 追記
    2019年10月19日 3:39
  • 「何をやっているの?!」と皆さんにご指摘を頂きそうです、DefaultWebSiteを右クリックして、
    Webサイトの管理 -> 開始 を選択したことで無事再開しました。
    ページが表示されなかったのはSuferOnWwwさんの仰られるとおり「ODP.NET以前の問題」でした。(これはMSSQLServerのみをDBとした検証用のコンパクトなWebサイトさえも表示されなかった筈、OracleDataBase用の検証用Webサイトを試しだす際に停止したと思われます)

    で、検証用のWebサイト(OracleのみをDBとしたWebサイト、GridViewを配置した一つのWebフォーム。GridViewのデータソースはSQLDataSourceで Oracleの一表のSELECT文からデザイン)、運用環境でブラウザ実行した結果は 以下のとおりです。

    上記の検証結果を伝えている枠内で当方 開発環境側でOrcle.DataAccessの参照追加を漏らしたまま運用環境にDeployしてしまったので
    参照追加を果たしてDeployしなおしたと記載しています。 この作業の有無は関係ないのか....?!!  そもそも開発環境で参照追加しないまま GridViewの実行ができたのなら、運用環境でも参照追加せずとも 実行できるべきなのでしょうか?SQLDataSourceからのデータ取得方法・プロバイダとの位置関係が良く分からない...。

    論点が変わってきてしまいますかね、SQLDataSourceであればOracle.DataAccess.dllを参照追加せずとも、実行できるはず というのは

    でも、これがYesであるなら、型付データセットでプロバイダを読み込めない問題に話しは繋がってくるのでしょうか。

    矢継ぎ早にコメントして すみません。 今からKOZ6.0さんご提案の確認に入ります。
    2019年10月19日 4:16
  • KOZ6.0さん、ご見解頂きながら 時間を経過させてしまい申し訳ありません。
    一先ず、(1)について確認しました。

    2箇所どころか1箇所もありません。上記画像のとおりです、ちなみに’oracle’の文字検索ではsystem.oracleclientのみが対象となりました(関係ないもの)。
    ご紹介の記事ですが、このスレッド頭で、運用環境について.NETFrameworkとODACのセットアップ順序を間違えたことに対し、リカバリをとったと言及し、この際に参考にさせて頂いた記事がこちらになります。
    リカバリがしっかり行われていないということですかね??? 心配になってきましたぁ....
    一先ず、何をすべきか定かでないので手を止めています。

    (2)ですが、上記結果が思いのほか悪い診断結果(この検証をやる以前の問題)だと、やっても無駄な行為でしょうか...。こちらの掲載後に一応やって改めた報告をします。


    • 編集済み saya24 2019年10月19日 5:00 助詞の違い
    2019年10月19日 4:58
  • KOZ6.0さん (2)の確認ただ今終了しました。

    仰られたとおり作業してから気が付きましたが、tnsname.oraが正しい記述になっているかを確認されたのですかね。

    で、結果ですが...要求された .Net Framework データ プロバイダーが見つかりません。これは、インストールされていない可能性があります。

    というSuferOnWwwさん向け返信に貼り付けたスクリーンショット同様の結果を招いています。

    Oracle.DataAccess.dllをコーディング頭でimpotrtしたコンソールアプリケーションの動作が当該環境で成功していようと、ASP.NETとしては まだ不十分にある ということなのでしょうかね?

    2019年10月19日 5:14
  • 開発環境であれば、

    > 開発環境(Windows10/VS2017:デバッグをIISExpress 64bit実行)--->無事画面に結果現れる。

    なのですよね。

    エラーメッセージを見ると、ODP.NET が Windows Server 2016 に一切存在しないということではないのですか? 実際、machin.config を見て ODP.NET がインストールされた痕跡は見当たらなかったのですよね。

    よくある問題としては、インストールしてある ODP.NET が 32-bit 版でワーカープロセスが 64-bit 動作(もしくはその逆で ODP.NET が 64-bit、ワーカープロセスが 32-bit)ということがあるのですが、その問題ならエラーメッセージは以下の記事のようになるはずで、今回の質問者さんのケースとは違うような気がします。

    IIS Expressを64bitモードで動かす
    https://blog.xin9le.net/entry/2014/05/07/220837

    開発マシンでは動いたとのことですので、上記のあたりに着目して、違いを調べてみてはいかがですか?

    2019年10月19日 6:03
  • 引き続きのご見解ありがとうございます。

    >エラーメッセージを見ると、ODP.NET が Windows Server 2016 に一切存在しないということではないのですか? 実際、machin.config を見て ODP.NET がインストールされた痕跡は見当たらなかったのですよね。

    こちらに見当たらなかったことは事実です。リカバリ策をとったといえ、それが万全であったか否かを問われると正直確証がもてません...。OracleからSQLServerへデータ転記するコンソールアプリを当該環境で動作させ、その無事をみて、リカバリは成功しているという解釈をしました。(そのコンソールアプリ、頭でImports Oracle.DataAccess.Client の記述があり、それが作用して動作しているものと認識しています。この記述ないと、VS上でもSyntaxエラーになるし)

    運用環境想定で、VisualStudio上のASP.NETサイトもIISExpress64で実行させることがベターなこと、以前教えて頂きました。terateil側で鮮明に記憶に残っています。開発環境での検証用サイトの実行状況は以下の感じで、この構築物一式を運用環境へもっていくと、先のエラーを招くということです。  違い...ですか。 サーバ再構築か、ODACの再セットアップで進展を望めそうならチャレンジしたいのだけれど、そう甘くないですかねぇ。すみません、泣き言を言いまして

    2019年10月19日 7:07
  • KOZ6.0さん 失礼致しました。当方が参考にさせて頂きました記事の、適用方法を誤っていないかの注意喚起のコメントだったのですね。リカバリ方法として重複した記事の紹介と勘違いして受止めていました

    参考にされた URL
    「ODP.NETのGAC登録」
    http://www.meeks.jp/archives/5907
    では .NET 2.0/3.5 用 ODP.NET の登録しかしていません。
     存在しないようであれば ORACLE_HOME の ODP.NET\bin\4 フォルダに対しても同様の操作が必要になります。

    自分が運用環境(サーバ)で記事を参考に行ったリカバリ手続きですが、Oracle.DataAccess.dllのありか・パスを適宜変更して、ここで紹介されていたoraprovcfg /action:gacのコマンドを実行した程度です。実行したコマンドプロンプトの画面にはsuccesfullyと現れていた記憶があります。これで万事解決と解釈していたのですが 予め他に何かしておかないと、実は功を奏さないのでしょうか? 申し訳ありません...せっかく記載いただいたコメントが理解できなくて。

    改めてこちらの記事を読み返して気が付きましたが、静的参照でOracle.DataAccessを利用する場合に失敗する、と言及されている点が 非常に気になるところです。

    コーディング頭で当該dllをImportsする 私が試したコンソールアプリケーションは動的参照に位置づけられる。その反面、Webフォーム上のコントロール=SQLDataSourceなりObjectDataSource(DataSet)は Web.configから接続情報を参考にするタイプであり この部類は 静的参照に位置づけられる。ということでしょうか??? もしそうなら今まさに経験している事象は 記事に当てはまっていると思えました。如何でしょう??

    もし...そうだとしたら 私 どうすれば 良いのでしょう...






    • 編集済み saya24 2019年10月19日 9:56 日本語らしく
    2019年10月19日 9:33
  • 紹介された記事では ORACLE_HOME の ODP.NET\bin\2.x に対してしか処理を実行していないですよね。

    ODP.NET\bin\4 に対しても同じ処理をしないといけません。

    成功すれば machine.config に oracle.dataaccess が追加されます。

    • 編集済み KOZ6.0 2019年10月19日 12:21
    2019年10月19日 12:19
  • 早速の反応誠にありがとうございます、助かります。

    紹介された記事では ORACLE_HOME の ODP.NET\bin\2.x に対してしか処理を実行していないですよね。


    Yes、記事の紹介者はASP.NET2.0の利用者だったのだろう。私はASP.NET4.6なのだから、という解釈をして-----> 「4」のフォルダ・パスを選択した実行を行いました。「2」のフォルダ・パスを指定した実行は行なっていません。 ”パスは適宜編集してください”と記事上の記載、私ひょっとして誤って解釈していますか??? 「2」もやる必要があるのでしょうか? しかも先に「2」が処理されているべき、とか仰られると辛いのですが……

    ODP.NET\bin\4 に対しても同じ処理をしないといけません。


    “も”ってコメントされているということは、やはり?! 両方なのですか?? お手すきの際で構いません、コメント頂けたら幸いです。

    • 編集済み saya24 2019年10月19日 13:25 脱字対応
    2019年10月19日 13:21
  • machine.config に値が入っていないので、2.x のほうしか実行していないのかなと思っただけです。
    2.x のほうは不要です。

    Framework 4.6 を有効化する前に実行したのでは?

    ともあれ、machine.config  に値が入っていないのが原因のひとつではあるので、もう一度実行してみてください。

    • 編集済み KOZ6.0 2019年10月19日 15:14
    2019年10月19日 13:50
  • ご返信誠にありがとうございます。

    Framework 4.6 を有効化する前に


    何を尋ねておられるかというと、OracleClientのインストールについてですね??そうです。win64_12201_clientのsetup.exeを、Framework 4.6の有効化前に行ってしまったのです。 実は記事に紹介されたOraProvCfgの実行、失敗していたのかなぁ??? 本来ならmachine.configにあらわれるのですよねぇ? 明日になりますが、もう1回やってみますかねぇ? 迷う...
    • 編集済み saya24 2019年10月19日 15:56 脱字対応
    2019年10月19日 15:36
  • KOZ6.0さん 迷いを払拭させるコメント、ありがとうございました。 早速記事のコマンド、やりなおしました。以下のとおりです。

    結論から申し上げると、コマンドを実行して、確かにGACに登録されたというメッセージが画面に返ってくるも macine.configに登録されません。

    一応 再起動後に反映??なんて素人考えをしまして、当該サーバを再起動して再度ご提示のmachine.configを確認したわけですが、やはりsystem.data.oracleclient以外 ’oracle’の文字をみつけられません。

    多分前回の実施もこうだったのかもしれませんね。実は行っているコマンド実行は意味をなしていない...

    困ったな...なにか次の行動をご提案頂けたら助かります。

    OracleClientのインストーラの再実行ですかね?Clinet_2ができて ちょっと汚れる雰囲気ですが



    • 編集済み saya24 2019年10月20日 1:29 誤記訂正
    2019年10月20日 1:22
  • > 確かにGACに登録されたというメッセージが画面に返ってくるも macine.configに登録されません。

    であれば、GAC を確認してはいかがですか?

    GAC に ODP.NET の .dll があって、それが適切なものなら ASP.NET Web アプリは動くと思います。

    ASP.net assembly loading from GAC or Bin
    https://blogs.msdn.microsoft.com/pranav_rastogi/2010/10/17/asp-net-assembly-loading-from-gac-or-bin/
    2019年10月20日 2:57
  • <https://pie001.hatenablog.com/entry/2016/12/22/121509> この方はmachine.config直接修正していますかね??
    2019年10月20日 3:06
  • SuferOnWww様 おはようございます。GAC確認しました。以下のとおり登録されています。あのコマンドはGACに登録するだけのことで、machine.configには登録しないということかも知れませんね。運用環境で検証用の例のサイト(Gridviewのみ)を一応再実行を試しましたが、状況は変わりありません。

    静的参照も大丈夫なのですかね???

    この記事をご紹介頂いた主旨は もうBINに入れたら??という提案を含んでいますか。最終的には自己判断ですよね。

    machine.configを触っている人がいましたね。


    • 編集済み saya24 2019年10月20日 3:36 追記
    2019年10月20日 3:28
  • 一回 運用環境のBINフォルダに、先程GACの登録状況に示したdllを入れて実行すれば 妥当なdllか分かりますかね。妥当であればBINフォルダから当該dllを外して、machine.configの直接修正、というのが 考えられる策でしょうかねぇ。


    • 編集済み saya24 2019年10月20日 3:53 追記
    2019年10月20日 3:48
  • OraProvCfg をパラメタ無しで起動すると使い方が出て来ますね。

    2. Machine.config
    
    Example: Configuring ODP.NET with .NET Framewework 4.0 machine.config
    
        OraProvCfg /action:config /force /product:odp
                   /frameworkversion:v4.0.30319
                   /providerpath:<provider path>
    
        NOTE : /productversion:<product version> can also be used in place
               of /providerpath:<providerpath>.
    

    /action:config とする必要があるみたいです。

    ひょっとすると管理者権限が必要かもしれません。


    • 編集済み KOZ6.0 2019年10月20日 4:02
    2019年10月20日 4:00
  • KOZ6.0さん お手を煩わせて申し訳ありません、試して頂けたのですね。感謝感激。 なるほど、/action のパラメータを変えてやることに価値があるかもしれない、とのことですね??今からやってみます。
    2019年10月20日 4:20
  • いちいちすみません。エラーになったのですが、IISを停めてINUSE状態を解除する必要がある、とかそういうことでしょうか?

    これさえうまくいけば、なんとかなるような気がしています。勝手な解釈ですが

    2019年10月20日 4:41
  • > 運用環境で検証用の例のサイト(Gridviewのみ)を一応再実行を試しましたが、状況は変わりありません。

    依然として「要求された .Net Framework データ プロバイダーが見つかりません。これは、インストールされていない可能性があります。」というエラーになるということですね。

    GAC には存在するということですから、以下のスレッドのように GetFactory メソッドを使ってるということはないですか?

    System.Data.Common.DbProviderFactories.GetFactoryメソッドでオラクルに接続する際
    https://social.msdn.microsoft.com/Forums/ja-JP/cf297b0e-3ece-4bb8-b2e0-7beb04c06af7/systemdatacommondbproviderfactoriesgetfactory?forum=csharpgeneralja

    そうだとすると、上の記事に書いてあるように machine.config の DbProviderFactories に Oracle.DataAccess.Client の設定がない、即ち質問者さんの現在の状況なのかもしれません(実際見当たらないのですよね?)。

    単なる想像ですが、SqlDataSource の ProviderName が気になります。

    <asp:SqlDataSource 
      ID="SDS01" 
      runat="server" 
      ConnectionString="<%$ ConnectionStrings:ConnectionString %>" 
      ProviderName="<%$ ConnectionStrings:ConnectionString.ProviderName %>" 
      SelectCommand="SELECT * FROM &quot;C_HORE&quot;">
    </asp:SqlDataSource>

    上に紹介した記事に「GetFactoryじゃなく、普通にOracle.DataAccess.dllを参照しての接続はできます」とあるので、SqlDataSource を使わないで ADO.NET で DataTable を取得するコードを書いて試してみてはいかがですか?

    その前に、先のレスでアドバイスしたように、問題ないという開発環境との比較をするのが先だと思います。GAC と machine.config だけでも比較してみましょう。

    ちなみに GetFactory メソッドをどのように使うかは以下の記事の「Oracleへの接続確認」の DbFactory クラスを利用したコード例を見てください。SqlDataSource が見えないところで GetFactory を使っているのかもしれません(想像です。ハズレかもしれません)

    .NETアプリケーションからOracleに接続する
    https://codezine.jp/article/detail/1200

    > この記事をご紹介頂いた主旨は もうBINに入れたら??という提案を含んでいますか。

    いえ、そういう提案はしてません。GAC にあれば問題なくロードできるはずという説明のみです。


    • 編集済み SurferOnWww 2019年10月20日 4:58 追記
    2019年10月20日 4:51
  • SuferOnWww様 ありがとうございます、強調して頂かなければ、GACとmachine.configについて 開発環境との比較へ着手しませんでした。何から何まですみません。結果報告は夕刻過ぎを予定します。
    2019年10月20日 5:16
  • なんでしょうね?

    成功すると以下のようになります(Windows 8.1 + Oracle 12.1c)。

    何か原因があるのでしょうけど、それはこちらではわかりません。


    • 編集済み KOZ6.0 2019年10月20日 5:39
    2019年10月20日 5:35
  • GAC上のdllで、運用環境と開発環境に違いを発見しましたので、ご報告致します。馬鹿モンと仰られる結末かも知れません。

    開発環境x64のODP.NETはODACというパッケージのsetup.exeで実装しました(それにプラスして、x86のODACとしてODTwithODAC=VisualStudioでの開発に長けたライブラリを含むODACを追加実装)。かたや運用環境はwinx64_12201_clientという、OrcleClient丸々のsetup.exeを実装しています。この違いで、互いのdllで製品ヴァージョンやサイズが異なってしまっています。

    やはりこれが 問題でしょうか。 皆様を混乱に落とし入れた要因がこれと思うとお腹が痛くなってきました...

    取り急ぎご報告致します。

    2019年10月20日 6:02
  • machine.config は調べたのですか?

    > 皆様を混乱に落とし入れた要因がこれと思うと

    そういうことではなくて、何かあるとそちらに目が行って違う方向に走ってしまう ⇒ 調べ方が中途半端になって回答者が付いていけなくなってしまう・・・のが混乱の要因という感じがしてます。

    なので、

    > 取り急ぎご報告致します。

    そういう途中報告は結構ですから、回答者に指摘された怪しそうなところ (machine.config の違いなど) はとにかく全部調べてから返事を書いていただくようお願いします。


    ところで、先の質問者さんのレスに、

    > OracleからSQLServerへデータ転記するコンソールアプリを当該環境で動作させ、その無事をみて、

    とありましたが、それは運用環境で、状況は今でも変わってないのですよね?

    それは GetFactory を使っていないのでは?

    だから ODP.NET 経由で Oracle に接続してデータを取得できたということで、上のようなマイナーなバージョンの違いは問題ないのでは?

    少なくとも、「要求された .Net Framework データ プロバイダーが見つかりません。これは、インストールされていない可能性があります。」というエラーとは関係ないのでは?
    2019年10月20日 7:11
  • SuferOnWwwさん、KOZ6.0さん、魔界の仮面弁士さん

    思うようにこちらの環境・事象をお伝えできないが為に、長期に亘った問合せとなってしまい大変申し訳ありません。

    また他人に関わらず問題解決に向けた支援、心より感謝申し上げます。

    (1) %windir%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config に
    「oracle.dataaccess.client」の記述はありますか?

    configSections と DbProviderFactories の2個所に記述があるはずです。

    -1つ目残回答-

    machine.configについて、開発環境と運用環境の違いを報告します。(oracle.dataaccess.clientの記述に限定して)

    開発環境:KOZ6.0さんの仰られるとおり configSections と DbProviderFactoriesの2個所に記述あり

    運用環境:なし

    -2つ目残回答-

    問題となっている運用環境で動作したコンソールアプリ(Oracle.DataAccess.dll参照追加済み)は GetFactory の手法を利用か?

    Noです。提示頂きましたCodeZineの記事とは全く違うコーディングによってOracleDataBaseへ接続しています。

    Using Cn As New OracleConnection(OraCnStr) Cn.Open() Using Cmd As New OracleCommand Dim Rd As OracleDataReader = Nothing Cmd.Connection = Cn Cmd.CommandText = ORASQL Try Rd = Cmd.ExecuteReader Do While Rd.Read VAL1 = Rd(0) VAL2 = Rd(1) VAL3 = Rd(2) VAL4 = Rd(3)

    After_Get() Loop Catch Ex As Exception Finally If Not Rd Is Nothing Then Rd.Close() End If End Try End Using Cn.Close() End Using

    次に確認すべき事項は 上記コードをGetFactoryに置き換えたコンソールアプリを手配しての 動作確認になりますでしょうか?それとも、運用環境と開発環境で、当該dllのマイナーヴァージョンの違いが、型付きデータセットのデザインに影響するかを調査して、運用環境のODAC刷新の行動へ移る感じでしょうか...ご見解頂けたら幸いです。


    • 編集済み saya24 2019年10月20日 8:27 インデント揃え
    2019年10月20日 8:22
  • > 開発環境:KOZ6.0さんの仰られるとおり configSections と DbProviderFactoriesの2個所に記述あり
    > 運用環境:なし

    上の私のレスに、「要求された .Net Framework データ プロバイダーが見つかりません。これは、インストールされていない可能性があります。」というエラーの原因は「machine.config の DbProviderFactories に Oracle.DataAccess.Client の設定がない」ことと書きましたが、それが一つ裏付けられたと思っています。

    なので、次に取るべきアクションとして自分がお勧めしたいのは、開発マシンの machine.config の「configSections と DbProviderFactoriesの2個所に記述」を運用環境の Windows Server 2016 の machine.config にコピペして試すということです。

    だだし、一番最初の質問の問題はこれとは違うようですので、「要求された .Net Framework データ プロバイダーが見つかりません。これは、インストールされていない可能性があります。」というエラーが解決できても、さらなる紆余曲折があるとは思いますが。
    2019年10月20日 9:32
  • OraProvCfg がうまく動かないのは気になりますが、machine.config を手動で編集してみては?

    開発環境から足りない2行をコピペしたら動きそうな気がします。

    • 編集済み KOZ6.0 2019年10月20日 10:06
    2019年10月20日 9:38
  • 引き続きのご支援誠にありがとうございます。開発環境と運用環境間のmachine.configで差として表れていた部分(以下)、追記しました(運用環境のmachine.configへ)。

    <section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
    <section name="oracle.unmanageddataaccess.client" type="OracleInternal.Common.CustomSectionHandler, Oracle.DataAccess, Version=4.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
    <section name="oracle.dataaccess.client" type="System.Data.Common.DbProviderConfigurationHandler, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    
    <DbProviderFactories>
    	<add name="ODP.NET, Managed Driver" invariant="Oracle.ManagedDataAccess.Client" description="Oracle Data Provider for .NET, Managed Driver" type="Oracle.ManagedDataAccess.Client.OracleClientFactory, Oracle.ManagedDataAccess, Version=4.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
    	<add name="ODP.NET, Unmanaged Driver" invariant="Oracle.DataAccess.Client" description="Oracle Data Provider for .NET, Unmanaged Driver" type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=4.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
    </DbProviderFactories>
    
    

    この後、かねてから検証用に用いてきたOracleをDBとした単純なWEBサイト・フォーム(GridView with SQLDataSource)を 運用環境再起動後、早速実行してみました。

    すると、今までのように「インストールされていない可能性があります」というエラーとは異なり、「見つからないか、読み込めませんでした」というメッセージのエラーになりました。

    これを受け、当方は この検証用のWebサイトのWeb.config・Oracle接続用のプロバイダについて再確認することにしました。今回話の発端となった4.0からの移行サイトで利用中のプロバイダ:Oracle.DataAccess.Clientを利用して こちらのサイト・検証を 行っていると信じていたのですが、実のところ違うもの:Oracle.ManagedDataAccess.Clientが ProviderNameに記述されていました(報告が遅れて大変な罪悪感があります)。

    最新のODTwithODACがセットアップされたVisualStudioで、ウィザードに従いSQLDataSourceを仕上げてしまったので、従来まで利用されてきたプロバイダとは異なるものが選択されてしまっていたようでした。

    そこで、試しにWeb.config上のこの部分を、従来のProviderName、Oracle.DataAccess.Clientへ変えて、運用環境で再実行することにしました。すると----->★無事 目的としたGridViewがデータを含めて表示されるようになりました(但し検証用のサイト)★

    このWebサイトプロジェクトには Oracle.DataAccess.Clientの参照追加を行っておらず、Web.configにaccembliesの記述は一切ありません。開発環境も本番環境もです。そう考えると...このプロジェクトのWeb.config上のProviderName記述が Oracle.ManagedDataAccess.Clientであったときに以下エラーを招いた状況がちょっと疑問です。このプロバイダによる接続は当初から追及していなかったので、混乱を避け言及すべきか多少迷ったのですが、隠し事があることを良く思わなかったので報告致します。(解決する必要ないが気になるといえば気になる)

    ★☆★話しの発端となったWebサイトを引き続き、運用環境のブラウザで実行してみました★☆★

    無事に初期ページが表れるようになりました。当初パーサーエラーを招いていた Webサイトです。(2019年10月16日 16:31に当方がコメントしている③④のWebサイト) machine.configの転記が功を奏したものと思われ、ここまで導いて頂いた皆さんに本当に感謝を申し上げたいです。ありがとうございます!

    ただ....

    初期ページからページ遷移できない問題に陥っています。ブラウザ上部のURL部分は次のページ名になっているのですが、スクリーンにその画面デザインは初期画面のまま・再読み込みされている雰囲気?!(Response.Redirect("menu.aspx", False)で、次ページに遷移される作り。多分menu.aspx側でセッション変数が空のために初期ページへ再度戻されているのでは、と推察。立上げ間もないIISだから何か設定漏れがあるのか?!と疑っている。ある程度の調査後 別掲載させて頂くかも知れません)

    このWebサイト、ReportViewerを利用しているWebフォームへ遷移・動作させないと、Oracleからの型付データセット取得を確立(OjectDataSourceに採用)できたか否か判断できないのですが、パーサーエラーは出なくなったので 本件クローズとしてよろしいものでしょうかね???

    何か名残惜しいというか、この問題のサイトで まだ一切Oracleのデータを閲覧できていないので ちょっとクローズに気がひけます。

    2019年10月20日 13:25
  • まとめると

    (1) 実行環境で .NET Framework 4.6 を有効化する前に Oracle Client をインストールしてしまった。そのため ODP.NET が正常にインストールされなかった。

    (2) .NET Framework 4.6 を有効化してリカバリしたが、手順に不足があったため、machine.config に必要な情報が書き込まれず、型付データセットのパーサエラーが発生していた。

    (3) machine.config に必要と思われるパラメータを書き込んだら解消した。

    ということでいいんですかね?

    あとは別件と思われるのでクローズしていいと思います。

    ※ 管理対象ドライバは Oracle Client のイントールが不要で、AnyCPU なので 32bit/64bit を気にしないで済みますから、移行するつもりがあれば、お勧めしておきます。


    • 編集済み KOZ6.0 2019年10月21日 0:40
    • 回答としてマーク saya24 2019年10月21日 6:14
    2019年10月21日 0:18
  • KOZ6.0さん 本当に何から何まですみません、大変御世話になりました。

    魔界の仮面弁士さんが仰られている

    新規に『SELECT * FROM DUAL』するだけの 型付 DataSet を持った ASP.NET アプリケーションを作成した場合、それは動作するのでしょうか。

    だけ 今から再確認しようとしています。結果が出るまで今しばらくお待ちください

    2019年10月21日 1:06
  • まとめると、以下の通りと理解していますがよろしいですか? 理解が違っていたら指摘ください。

    根本的な原因は:

    (1) 運用環境のサーバーの machine.config の DbProviderFactories に Oracle.DataAccess.Client が設定されていなかった。

    (2) 運用環境のサーバーの web.config の connectionStrings セクションの Oracle 用の接続情報で providerName を Oracle.DataAccess.Client とすべきところが、Oracle.ManagedDataAccess.Client になっていた。

    何故エラーになったかと言うと、推測混じりですが:

    (a) 2019年10月19日 4:16 の質問者さんのレスの画像にある「要求された .Net Framework データプロバイダーが見つかりません。これは、インストールされていない可能性があります。」というエラー

    ・・・上記 (1) が原因。そのページで使っている SqlDataSource が GetFactory メソッドで DbProviderFactory を取得できなかった為のエラーと思われる。

    (b) 上記 (1) を処置した後に出てきた「登録されている .NET Framework データプロバイダーが見つからないか、読み込めませんでした」というエラー

    ・・・上記 (2) が原因。web.config の providerName に設定されている Oracle.ManagedDataAccess.Client を探しに行ったと思われる。

    (c) このスレッドの一番最初の質問のパーサーエラー

    ・・・デプロイ後の一番最初の要求で、サーバーが web.config の接続情報に基づき DB に接続して型付 DataSet + TableAdapter のコードを自動生成するが、上記 (1), (2) の問題で DB に接続できなかったためと思われる。

    対処方法は:

    問題なく動く開発マシンの machine.config から運用環境のサーバーの machine.config に差分をコピー。運用環境のサーバーの web.config の接続情報の providerName を Oracle.DataAccess.Client に訂正。

    結果、上記 (a), (b), (c) のエラーは解消。

    上記理解が合っていたら早急にクローズしてください。
    • 編集済み SurferOnWww 2019年10月21日 2:31 誤字訂正
    • 回答としてマーク saya24 2019年10月21日 6:15
    2019年10月21日 2:00
  • SuferOnWww様 お疲れ様でございます。

    (a)も(b)も正しい記載と認識します。
    但し、それらは検証用の簡易Webサイト(GridViewのみ)を運用環境で実行した際に表れた話題だったはず...。
    やりとりの過程で、私が簡易Webサイトでの検証に切り替えてしまったため、混乱を与えましたね、すみません。
    問合せ発端のWebサイト(ASP.NET4.0->4.6移行)は途中途中の過程で検証していません。
    憶測ですが、machine.configを修正するまで 実行を試せばパーサエラーをず~っと招いたのかなぁと推察します。


    (2)で申されているProviderNameが 想定と違った記述になっていたのは 検証用Webサイトだけの話しですね。
    パーサーエラーで最初に悩まされていたASP.NET4.0から4.6へ移行しようとしているWebサイト(プロジェクト)は
    接続系設定に一切変更を加えておらず、その面のWeb.configは維持されている(最新ReportViewerのaccemblyを対応)、即ち
    パーサーエラー発生要因は (1)のみが起因していたのかな、と推察しています。

    ですので、(c)の記載に 「(1), (2) の問題で DB に接続できなかったためと思われる。」とありますが
    当初SuferOnWwwさんが仰られたように、(1)の要因でコンパイルに失敗していた、というのが 正しい解釈???
    と思いました...

    皆さんに大変御世話になった手前、自分自身の見解を述べられる立場にないのですが 如何でしょう?


    • 編集済み saya24 2019年10月21日 3:23 追記
    2019年10月21日 3:20
  • > (2)で申されているProviderNameが 想定と違った記述になっていたのは 検証用Webサイトだけの話しですね。

    自分が知り得ることはスレッドに書かれていることだけなので「検証用Webサイト」以外のサイトの設定がどうなっているかは知りませんし、「だけ」かどうかは分かりません。

    別のサイトでは (1) の問題があっただけで (2) は問題無かった(正しく Oracle.DataAccess.Client であった)と言うのであれば、そこでは (2) は関係ないということは当たり前なのですが・・・それ以上のことはエスパーでもないと分からないと思います。

    いつまでも引っ張らないでクローズしてもらえませんか。もうちょっと付き合い切れないという感じです。
    2019年10月21日 6:05