I found a similar thread in the forums that discussed this issue... http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=9007 ...it said that a new thread would be started regarding the problem, but I couldn't find it...so here I am again.

After reading the forementioned thread, I have taken the following actions... -Removed the Oracle.DataAccess from GAC -Deleted all the asp.net tempfiles -Searched my entire HDD for "LLBLGenPro" to find any runtime libraries that might be stuck in weird places (the only ones I found were in the LLBLGen install directory.) - I moved the connection string from the LLBLGen build's app.config and placed it in my web.config file.

No luck so far...any other suggestions?

Pkease check the following blog post: http://walaapoints.blogspot.com/2007/06/odpnet-llblgen-pro.html

ALso, be sure you don't use an assembly redirect in the config file of your app IF you have ODP.NET 10g v2 installed, as you need to reference the .NET 2.0 build of the provider. (there are two versions). Redirects of the assembly makes things go wrong in some special cases, as apparently .NET's fusion gets confused.

Yes, Lancer in the Park...I have read it many times now. However, I found the problem...I was clued in when I tried to open my project in LLBLGen - the runtime error thrown when I tried to open my LLBL project in LLBLGen explicitly mentioned TWO Oracle versions. After some trial and error on redirects in the app.config for LLBLGen, I discovered that I needed TWO redirects! One to redirect from 10.1.0.400 and another one to redirect from 1.102.2.20. I thought I could put a dash separator (from-to) in there as I had seen done in other examples, but no such luck - it had to be two explicit entries like so...

<dependentAssembly>
   <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" culture="neutral"/>
   <bindingRedirect oldVersion="10.1.0.400" newVersion="2.102.2.20"/>
</dependentAssembly>
<dependentAssembly>
   <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" culture="neutral"/>
   <bindingRedirect oldVersion="1.102.2.20" newVersion="2.102.2.20"/>
</dependentAssembly>

Okay, now that I am over that hump, and have yet another problem. Here's the error being thrown in Visual Studio when I am debugging...

Could not load file or assembly 'Oracle.DataAccess, Version=1.102.2.20, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)" Source="SD.LLBLGen.Pro.DQE.Oracle10g.NET20

I am ssuming the key words here are, "assembly's manifest definition"...but which assembly are they refering to? For some reason, something is STILL looking for Oracle's 1.102.2.20 version. I have removed version 1.102.2.20 from the GAC, put version 2.102.2.20 into the GAC. I have the redirects in place and apparently working (for LLBLGen...not my application), and now what???!!!

According to the reading I have done in this forum, I am going to have to get the source code from LLBLGen and recompile the "SD.LLBLGen.Pro.DQE.Oracle10g.NET20" project --- Is that correct next step? Is that the assembly who manifest is messed up?

Jeeze! Oracle is a major pain in the neck!

You should need NO redirects. Please remove the redirects as you have installed ODP.NET 10g v2.

You don't need the redirects at all.

So to sum it up: - you have to have ODP.NET 10g v2 installed. CHECK (you have this installed) - you have to reference OracleDQE 10g .NET 2.0: CHECK (you reference this according to the error) - you have to have NO redirects in your config file: CHECK this. - you should UNinstall ODP.NET 10g v1 (10.1.0.4) if possible, but in theory it shouldn't mean a thing.

The Oracle10g .NET 2.0 DQE dll is build against 2.102.2.20. This means that if you reference that one in the generated code (as you do) you should just place a reference to Oracle.DataAccess.dll v2.102.2.20 from the C:\Oracle\product\10.2.0\client_1\ODP.NET\bin\2.x folder

NO redirect from 10.1.xxx nor from 1.102.2.20 are necessary as these dlls aren't used. You therefore should make sure that you reference 2.102.2.20 of Oracle.DataAccess in your own project.

Also please make sure you have ODP.NET 10g v2 installed, don't rely on just copying the dll into the GAC.

I just download the 10g driver yesterday, here's the path on my machine to the dll...

C:\oracle\product\10.2.0\client_3\ODP.NET\bin\2.x\Oracle.DataAccess.dll

And the properties list this as version...

2.102.2.20

As you recommended, I removed te redirects in the LLBLGen app.config (I have no redirects in my web.config), and here's what happens when I try to open my LLBLGen project in he LLBLGen client...

MESSAGE: Exception has been thrown by the target of an invocation. Could not load file or assembly 'Oracle.DataAccess, Version=1.102.2.20, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The system cannot find the file specified. Could not load file or assembly 'Oracle.DataAccess, Version=10.1.0.400, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The system cannot find the file specified.

STACK TRACE: -----[Core exception]-------------------- at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck) at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean fillCache) at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean fillCache) at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at SD.LLBLGen.Pro.ApplicationCore.DBDriverHelper.CreateDBDriverInstance(String assemblyFilename, String namespaceToUse, String className) at SD.LLBLGen.Pro.Gui.Forms.MainWindow.OpenExistingProject(String filenameToOpen) -----[InnerException]-------------------- at SD.LLBLGen.Pro.DBDrivers.Oracle10g.OracleDBDriver..ctor() -----[InnerException]--------------------

SOURCE: mscorlib SD.LLBLGen.Pro.DBDrivers.OracleDBDriver10g

oh, oH, OH!! Hold the phone...When I select driver from the LLBLGen drop down, I have... Oracle 10g Driver (ODP.NET 10.1x)

I need a dropdown choice of something like... Oracle 10g Driver (ODP.NET 2.x)

I don't have a choice like that, only the one choice for ODP.NET 10.1x. How do I get the correct option of ODP.NET 2x in the list?

Ok, I think we messed up ourselves as well. Deeply sorry for that.

My assumption (and I think of walaa as well) is that you were on v2.5. I think you are on v2.0, correct?

If so, that's the problem: the Driver for 10g for v2.0 are build against 10.1.0.4

So is the DQE.

I didn't see this info in this particular thread, so I assumed you were on v2.5. However your other thread you started there you say you're on v2.0.0.0.

As we made this error ourselves, I'll make it up to you and build the Driver and DQE for you against 2.102.2.20.

This will probably mean that you have to re-create the project.

(edit) 10g driver which is build against 2.102.2.20 for v2.0 attached. make a backup copy of the 10g driver in <llblgen pro installation folder>\Drivers\Oracle10g and copy this one on top of that one. You will see the same choice, but that's just the driver.config file. You will now be able to create a new project normally without redirects.

Will compile the dqe now. (edit) DQE is now attached as well. The DQE is also for 10g and 2.102.2.20.

ahh - I see now. No worries man, I had started this thread as a spin-off of the other one. I should have reposted all my info again (as instructed in the posting rules - oops!)

Yes, I am on LLBLGen 2.0. However, I do have LLBLGen 2.5 zipped up and wait for me to install. Should I just go ahead and upgrade? The only reason I haven't is because I have been very busy, and also I have a few other 2.0 LLBLGen projects that I have already implemented into some web solutions.

What's the best route to take from here - Upgrade or replace the 2.0 stuff I have with what you sent? I am sure you would know better which is best way to go (better than me anyway) at this juncture.

Okay, I decided to go ahead and run LLBLGen 2.0 and 2.5 side-by-side for now because I have a very critical application built with 2.0.

After installing LLBLGen 2.5, I tried to build a new LLBLGen solution. I was surprized to find that there was still no "Oracle 10g Driver (ODP.NET 2.x)" listed in the drop-down...only the same "Oracle 10g Driver (ODP.NET 10x)....is that the one I am to use to insure the reference to the 2.102.2.20 version of Oracle.DataAccess.dll? To make this clearer, I am attaching a screen shot

Call me impatient, but I went ahead and built a new LLBLGen solution in 2.5, using the "Oracle 10g Driver (ODP.NET 10x)" driver. All went great!! So my recommendation to anyone using LLBLGen for connecting to Oracle 10g or 9i is to DEFINITELY upgrade to 2.5...it was super easy after that

Okay, here's a new trick I tried, and it worked... After copying the connection string that LLBLGen made it its app.config to my web.config file (the x's are obviously placeholder for real data)....

<add key="Main.ConnectionString" value="data source=GVTAG.xxxxx.com;user id=xxxxxx;password=xxxxx;persist security info=false;"/>

I modified it so that I don't have to use that sTuPiD tnsnames entry. I have done this before by using examples from http://www.connectionstrings.com/ (an excellent site if you have never been there by the way), and now the connection string in my web.config file looks like this...

<add key="Main.ConnectionString" value="data source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS= (PROTOCOL=TCP)(HOST=xx.x.x.xx)(PORT=1521)))(CONNECT_DATA=(SID=XXXXX)(SERVER=DEDICATED)));User Id=xxxxxx;Password=xxxxx;" />

This accomplishes the same connection as before, but without the reliance on a tnsnames entry that has to be maintained yuck

Question: Why does LLBLGen add the connection string as an <appSettings> entry rather than a <connectionStrings> entry?

oops - I marked the thread complete before anyone could answer my question....and now I cannot UN-mark it.

Don't worry as soon as you post a reply on a thread, it gets re-openned again.

Question: Why does LLBLGen add the connection string as an <appSettings> entry rather than a <connectionStrings> entry?

You can place the connection string in either place. In fact LLBLGen Pro code searches for it within the <connectionStrings> first, and if not found it searches for it in the <appSettings> of your config file.

That's cool! Thanks for the information and all your help. You have an AWESOME product! Hopefully this thread will help some oher poor soul like me

Thanks Kyle, glad everything is sorted now