ASP .NET Application Using Incorrect Assembly Version

[jehugaleahsa]

Hello:

We are publishing an application to our web server, it tries to use
the wrong assembly version.

This is the line in the web.config file:

<add assembly="Oracle.DataAccess, Version=2.102.3.3, Culture=neutral,
PublicKeyToken=89B483F429C47342"/>

However, the web server tries to find version 2.111.6.20. We did some
research and this is for Oracle 11g. The 11g client isn't installed on
the web server. However, it is installed on our development machines.
How does that affect anything?

Why is ASP .NET trying to use a different assembly version than I
specify? How do I tell it to stop?

Any help would be great.

Thanks,
Travis

 

[Jeroen Mostert]

We are publishing an application to our web server, it tries to use
the wrong assembly version.

This is the line in the web.config file:

<add assembly="Oracle.DataAccess, Version=2.102.3.3, Culture=neutral,
PublicKeyToken=89B483F429C47342"/>

However, the web server tries to find version 2.111.6.20. We did some
research and this is for Oracle 11g. The 11g client isn't installed on
the web server. However, it is installed on our development machines.
How does that affect anything?

Your web application assemblies are referring to this version of the
assembly, not the intended version. What you put in your web.config only
applies to assembly references in dynamic compilation, e.g. code in .aspx
pages (not the code-behind).

One trivial way of fixing it is to upgrade the server's client, but I assume
you've already ruled out that option.

The other way is to install the same version of the assembly on your
development machine and build against that. You may be able to do this
without uninstalling everything by copying the right version of the assembly
(2.102.3.3) and any dependencies it has to somewhere other than your
project's \bin directory and reference it there. Be aware that this may fail
if version 2.102.3.3 relies on things created by an installation procedure
(like registry settings) that the install of 2.111.6.20 handles differently.
If this is the case, you really need to set up a development environment
that *is* representative, otherwise there's no way you'll have a
representative test.

When the application is copied to the server, delete the 2.102.3.3
assemblies from your project's \bin so they will be resolved in the GAC --
or leave them there, but they'll eat up size.

There are other ways of solving this (like converting your project to a web
site or using the <assemblyBinding> element to redirect the *new* version to
the *old* version), but this is the most obvious and least prone to breaking.

 

[jehugaleahsa]

Your web application assemblies are referring to this version of the
assembly, not the intended version. What you put in your web.config only
applies to assembly references in dynamic compilation, e.g. code in .aspx
pages (not the code-behind).

One trivial way of fixing it is to upgrade the server's client, but I assume
you've already ruled out that option.

The other way is to install the same version of the assembly on your
development machine and build against that. You may be able to do this
without uninstalling everything by copying the right version of the assembly
(2.102.3.3) and any dependencies it has to somewhere other than your
project's \bin directory and reference it there. Be aware that this may fail
if version 2.102.3.3 relies on things created by an installation procedure
(like registry settings) that the install of 2.111.6.20 handles differently.
If this is the case, you really need to set up a development environment
that *is* representative, otherwise there's no way you'll have a
representative test.

When the application is copied to the server, delete the 2.102.3.3
assemblies from your project's \bin so they will be resolved in the GAC --
or leave them there, but they'll eat up size.

There are other ways of solving this (like converting your project to a web
site or using the <assemblyBinding> element to redirect the *new* versionto
the *old* version), but this is the most obvious and least prone to breaking.

Turns out Oracle uses Policies that redirect older versions of the
Assembly to the newest version. While I reference the 2.102.3.3
version, the Policy moves it up to 2.111.6.20. I tested this by
checking the assembly version on my dev machine.

Somehow, this assembly version information is pushed to IIS when I
publish. My guess is that the precompile somehow is holding a
reference. Beats me on the details.

For now, I just uninstalled the 11g client. I'm not sure whether to
kick Oracle or my lead developer for moving us to a newer client. The
woes of a developer...