ODP.NET Publisher Policy?

  • Thread starter Thread starter llevity
  • Start date Start date
L

llevity

We recently started running into a problem. We had a .NET winform
application built with ODP.NET 9.2.0.4. We rolled out a new OS image
that had only the 10.1.200 Oracle client and ODP.NET.

The existing application stopped working, as it wanted a 9.2.0.4
client.

After doing some further research, I've discovered that publisher
policies are my answer. All our machines are currently running
10.1.0.200 of ODP.NET, however, and that build did not seem to install
or include publisher policies. 10.1.0.400 both includes, and installs
by default these policies into the GAC.

I'm hoping there's some way I can get or build publisher policies for
10.1.0.200. That way, I could get a script run that simply installs
these policies into the GAC of all machines on site. Otherwise, it
seems my other option is to uninstall all the 10.1.0.200, and reinstall
10.1.0.400.
From what I've managed to learn about publisher policies, they're done
Click to expand...
by the publisher of the component. I think I need access to the .key
file in order to generate my own, which of course, I do not have for
the Oracle.DataAccess assemblies.

Anyone know if these publisher policies are available for 10.1.0.200
somewhere?
 
We recently started running into a problem. We had a .NET winform
application built with ODP.NET 9.2.0.4. We rolled out a new OS image
that had only the 10.1.200 Oracle client and ODP.NET.

The existing application stopped working, as it wanted a 9.2.0.4
client.

After doing some further research, I've discovered that publisher
policies are my answer. All our machines are currently running
10.1.0.200 of ODP.NET, however, and that build did not seem to install
or include publisher policies. 10.1.0.400 both includes, and installs
by default these policies into the GAC.

I'm hoping there's some way I can get or build publisher policies for
10.1.0.200. That way, I could get a script run that simply installs
these policies into the GAC of all machines on site. Otherwise, it
seems my other option is to uninstall all the 10.1.0.200, and
reinstall 10.1.0.400.
Click to expand...

This won't work. You can't make code use 10.1.0.x instead of 9.2, as
these are not interchangeable. So either recompile your own code
against the 10g ODP.NET, or install the 9i ODP.NET version.

From the field: I can only give you the advice to use the ODP.NET
version designed for your database. So for 8i/9i, use ODP.NET
9.2.0.401, for 10g, use the 10.1.0.4 ODP.NET, as 10g ODP.NET version
used on 8i/9i sometimes give weird errors. So to save yourself severe
headaches, use the ODP.NET versions meant for the db, so in your
situation, if the DB is 10g, recompile against 10g, if it's 9i, install
ODP.NET 9i.
by the publisher of the component. I think I need access to the .key
file in order to generate my own, which of course, I do not have for
the Oracle.DataAccess assemblies.

Anyone know if these publisher policies are available for 10.1.0.200
somewhere?
Click to expand...

all 10g ODP.NET publisher policies redirect 10.1.x to the installed
version, though not 9i installs, as these aren't compatible.

Frans




--
 
I respectfully disagree. Version 10.1.0.400 of ODP.NET by default
installs two publisher policies. One points requests for 10.1.x to the
installed 10.1.0.400 Oracle.DataAccess, the other points requests for
9.2.x also to the installed 10.1.0.400 Oracle.DataAccess. I've tested
it, and it works.

My problem is that we've already deployed 10.1.0.200 ODP.NET to around
~2,000 PCs, which did not by default install or even include a
publisher policy. I don't know if its a bad install done on the PC
image, or that Oracle didn't think about publisher policies, or that
10.1.0.200 wasn't compatible with redirection from a request for a
9.2.x yet.

I was hoping they just forgot, or it was a bad install and someone
neglected to install the publisher policy, because otherwise, it seems
my options are:
a) recompile the 9.2.0.4 application with a 10.1.x ODP.NET
b) use the <assemblyIdentify> stuff in the application.config file
c) same as b, but do it on a machine.config level, or
d) uninstall 10.1.0.200, and reinstall 10.1.0.400 on all client PCs.

To me, the publisher policy method seemed most centralized, and
cleanest.
 
I respectfully disagree. Version 10.1.0.400 of ODP.NET by default
installs two publisher policies. One points requests for 10.1.x to
the installed 10.1.0.400 Oracle.DataAccess, the other points requests
for 9.2.x also to the installed 10.1.0.400 Oracle.DataAccess. I've
tested it, and it works.
Click to expand...

Hmm, as I've both installed I can't see if this was also the case
before 10.1.0.400.

To me it seems strange the calls for 9i are redirected to 10g
assemblies.
My problem is that we've already deployed 10.1.0.200 ODP.NET to around
~2,000 PCs, which did not by default install or even include a
publisher policy.
Click to expand...

If I recall correctly, the first public version was 201, then 301 and
now 400. But I could be wrong in this. What I DO know is that the
official downloads always had policy files for their OWN version and
the patch versions (the ones you download from oracle's support site
after logging in) do not have policy files.
I don't know if its a bad install done on the PC
image, or that Oracle didn't think about publisher policies, or that
10.1.0.200 wasn't compatible with redirection from a request for a
9.2.x yet.
Click to expand...

Well, the 10g ODP.NET I've currently installed, 301, only redirects
10g odp's:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess"
publicKeyToken="89B483F429C47342"/>
<bindingRedirect oldVersion="10.1.0.000-10.1.0.300"
newVersion="10.1.0.301"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
I was hoping they just forgot, or it was a bad install and someone
neglected to install the publisher policy, because otherwise, it seems
my options are:
a) recompile the 9.2.0.4 application with a 10.1.x ODP.NET
b) use the <assemblyIdentify> stuff in the application.config file
c) same as b, but do it on a machine.config level, or
d) uninstall 10.1.0.200, and reinstall 10.1.0.400 on all client PCs.

To me, the publisher policy method seemed most centralized, and
cleanest.
Click to expand...

Publicer policy files are signed, so I think that tampering them isn't
an option.

I'd go for a). Trust me on this, using 9i code against 10g odp.net
will give problems sooner or later. (like strange error 3000
exceptions).

But you're always free to opt for another option of course :)

FB

--
 
Included with the 10.1.0.400 ODP.NET is the folder
Client\ODP.NET\PublisherPolicy. One of the files,
Policy.9.2.Oracle.DataAccess.config, looks like this:

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess"
publicKeyToken="89B483F429C47342"/>
<bindingRedirect oldVersion="9.2.0.000-9.2.0.999"
newVersion="10.1.0.400"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

I'm not so much concerned about recompiling the application under 10g.
It's just, that doesn't seem clean to me, and seems like a slippery
slope. When 11.x comes out, we're likely to have a LOT more apps out
there, and I don't want to be the one who has to recompile and
redistribute them :)

Conversely, I don't like the idea of having 9.x, 10.x, 11.x all side by
side on each client.

I share your concern in running 9i code against 10g odp.net, but I
still think I'm going to recommend we go route b) for now, and modify
the app.config to redirect to 10g odp.net. We'll test it as thoroughly
as possible, and even if something weird happens after pushing it out,
it's fairly easy to back out of again and try another route.
 
Back
Top