Oracle.DataAccess.dll problem

Elements Oxygene
1

I had a project I created a few years ago. Now I had to update it. I have a recent RemObjects compiler version. It USED to be that when I built the solution, I would get a WARNING message about the Oracle.DataAccess.dll. Something about it being 32 bit (unfortunately, I’m not able to get back to that state now).

NOW when I compiled it, I get a Fatal Error message rather than a warning.

So on looking around the web, it was suggested to use the newer Oracle.ManagedDataAccess.dll which is, as the name implies, a fully managed .net assembly instead of the cobbled together thing from before. This worked with a .Net 4.x version.

Everything compiled and ran ok. But now the customer doesn’t want to add .Net 4.x to their IIS configuration.

So I’m back to trying to figure out how to use the Oracle.DataAccess.dll.

Unfortunately, I can’t get to a state to reproduce the problem right now, but I was hoping that you might recognize what this issue is. And I’m wondering if there is a way to tell the compiler/linker that that assembly is OK and don’t do a fatal error on it.

Or maybe the compiler I’m using has a bug that should be flagging it as warning instead.

Any ideas?

2

Was it an msbuild error or an elements error? That info would help already, that or the message.

3

Good question. Traveling at the moment so I can’t confirm which it was. But now that you ask, it might have been msbuild. At the time I just saw that it wasn’t going to allow the dll. I’ll have to check it out when I get back.

4

I guess this question isn’t critical anymore. The customer accepted the newer Oracle assembly and moved to .Net 4.x and it all worked for them.

5

I completely missed your reply, sorry

if msbuild ignores it you already had a mismatch of framework versions.

6

Just made the reply so nothing to be sorry about. To clarify, this question isn’t critical to ME anymore as they updated.

I don’t think there was a mismatch of versions when it originally compiled because it worked. But I won’t have to work with Oracle.DataAccess.dll any more.