

当該環境はいくつかのdllに分かれており、修正対象となったdllだけ載せ替えて機能の修正を行いたいのですが、サーバ環境へ作成したdllをdeployしたところ以下のようなerrorが発生しました。

[code]

    ファイルまたはアセンブリ 'Oracle.DataAccess, Version=2.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342'、またはその依存関係の 1 つが読み込めませんでした。指定されたファイルが見つかりません。
    
[/code]

原因としては、開発環境で使っていたOracle.DataAccessのversionとサーバ環境のversionに差異があったためだと思っています。

とりあえず、実行環境のversionを把握して、同versionを開発環境に入れてbuildすれば良いのだと思うのですが...仮に、そのversionが提供されなくなったら？という不安がよぎります。  
そこで質問なのですが、開発環境と実行環境でOracle.DataAccessのversionが違っても実行時にerrorが発生しないようにできるのでしょうか？  
サーバ環境の変更は許容されないと思うため、開発環境側でなんとかできないかな？と思った次第です。

しばらく調べてるんですが、どのように対処するのが良いのか分からず、解法が見つかりません。  
何か情報を提供いただけると幸いです。よろしくお願いします。

**サーバ環境**  
・Windows Server 2008R2  
・IIS7  
・ASP.NET .NET Framework 3.5  
[![サーバ環境assembly](https://i.stack.imgur.com/ywhoc.png)](https://i.stack.imgur.com/ywhoc.png)

**開発環境**  
・Windows 7 Professional (64bit環境)  
・Visual Studio 2008 Professional  
・IIS Express  
・ASP.NET .NET Framework 3.5  
[![開発環境assembly](https://i.stack.imgur.com/IsPfK.png)](https://i.stack.imgur.com/IsPfK.png)


CC BY-SA 3.0
2015-11-10T01:40:33.277
18596
2015-12-04T00:12:36.487
2015-11-10T02:58:18.030
2383
2383
question
visual-studio asp.net oracle iis
開発環境とサーバ環境のdllのversion違いを吸収するには？


遅延バインディングですかねぇ。

参考URL:  
<http://urashita.com/archives/1760#C>  
<http://ufcpp.net/study/csharp/sp4_dynamic.html#late_binding>

WinFormsでExcelを扱う際に、複数バージョンのExcelに対応しようとして  
遅延バインディングを使ったことがあります。  
ASP.NETでも使えると思います。

ただ、遅延バインディングにするとVisual Studio上でIntelliSenceが効かなくなるので、  
開発がちょっとやりづらくなりますね。


CC BY-SA 3.0
2015-11-10T08:14:04.997
18614
2015-11-10T08:14:04.997
9801
18596
answer


バージョンリダイレクトって機能があるので、それで動かせるんじゃないでしょうか  
<https://msdn.microsoft.com/ja-jp/library/7wd6ex19(v=vs.110).aspx>


CC BY-SA 3.0
2015-11-10T08:45:04.417
18616
2015-11-10T08:45:04.417
9811
18596
answer


開発環境では 2.112.3 をお使いで、実行環境では 2.112.1 をお使いだということですが、改修対象となっている新しい機能は 2.112.
**3** に依存しているでしょうか (2.112. **1** では動かないことが明確ですか)。

もし **そうでない** ならば、Visual Studio のソリューション
エクスプローラで今問題になっているプロジェクトの「参照」ノードを展開し、Oracle.DataAccess を選択して、プロパティ
グリッドに表示される「特定バージョン」を False にしてみてください (Oracle.DataAccess は既定で True
になっていると思います)。

[![アセンブリ参照の設定](https://i.stack.imgur.com/oMfT7.png)](https://i.stack.imgur.com/oMfT7.png)

画像では手元の PC に Visual Studio 2008 と Oracle DAC が入っていないので、Visual Studio 2015 上で
System.Core に対する設定で例示していますが、Visual Studio 2008 上で Oracle.DataAccess
に対してまったく同じ操作ができるはずです。

この方法は、改修対象のアプリケーションが古い DLL に合わせるパターンで、実行環境上の既存のアプリケーション群に迷惑をかけることはないはずです。

もし、改修対象のアプリケーションが 2.112. **3** に依存していて既存のアプリケーション群と改修対象のアプリケーションが **同じ bin
フォルダに配置されていない** のであれば、先ほどの「特定バージョン」は True のまま、「ローカルにコピー」を True にしてみてください。

.NET のアプリケーションは外部アセンブリへの参照を解決する際に、自分の bin フォルダ内に合致するものがないかを調べるので、GAC
内のアセンブリとは違うバージョンのアセンブリを自分の bin フォルダに含める (「ローカルにコピー」する) ことで解決できる可能性があります。

もし既存のアプリケーションと bin フォルダを共有していたとしても、外部アセンブリの検索方法は config で変更できたと思います
(うろ覚えですし、やったことはありません)ので、「プロービング (probe / probing)」をキーワードに調べてみてください。


CC BY-SA 3.0
2015-12-04T00:12:36.487
19609
2015-12-04T00:12:36.487
13511
18596
answer