Hi,

I am using LLBLGen Pro 3.1. I am using oracle databaase as my model. I have recently updated my OS to Win 7 64 bit. Since then I got the Proivder error while trying to connect to the ORacle Database to the Designer. I have in my system installed the ODAC Component version 11.2.0 and It has two folders one for 2.x and another for 4.x. In my registry ODP.Net 4.112.2.0 is seen under ODP.Net. I hope it is 32 bit. How to make my desginer work in 32 bit mode as we might have installation/users in both Win 7 and Win XP.

Also I need to found out, which version of the ODP.Net is referenced by the LLBLgen designer. Currently this is the entry in my machine.config(64 bit) entry for Oracle data provider.

  <DbProviderFactories>
      <add name="Oracle Data Provider for .NET" invariant="Oracle.DataAccess.Client" description="Oracle Data Provider for .NET" type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=4.112.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
      <add name="Microsoft SQL Server Compact Data Provider" invariant="System.Data.SqlServerCe.3.5" description=".NET Framework Data Provider for Microsoft SQL Server Compact" type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=3.5.1.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
    </DbProviderFactories>

Please check this thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=19259

To run llblgen pro designer as 32bit application you have to use the 32bit runner, which is a small .exe installed in the llblgen pro installation folder (and accessible through the windows start menu).

As llblgen pro is a .net 3.5 application, it will use the ODP.NET .NET 2.0 build, but that's fine. v3 of llblgen pro doesn't reference any ODP.NET version, so any version assigned to the factory name in machine.config is loaded. This will be the 2.11.x.y from the .net 2 machine.config file, as llblgen pro is a .net 3.5 app (and .net 3.5 uses the .net 2.0 CLR). If you want to run the designer on .net 4, you have to use the .net 4 runner, which will run the designer on .net 4, however as 64bit application.

The designer is not what you ship to your customers, so your customers will run your own application, which will run on the .net version you choose for your application. If you build it explicitly for x64, it will only run on 64bit, but vs.net by default builds for 32bit.

From the above I understand that I need to do either of the following:

1) Run the LLBLGen 32 bit application by setting the reference to the 2.11.x.y (ODP.Net) in my machine.config file.

2) Download the 64bit DLL with the version 2.11.x.y for ODP.Net and Run the LLBLgen for .Net 4.

In case of the first step whether it is mandatory to have the ODP.Net version 2.X in the Registry? because now I have installed latest version of LLBLGen 3.1 build (as on May 20th,2011) and open the 32 bit application, still I am facing the same error?

if it is mandatory Could you please tell How to add the old version of DLL is registry?

saravana wrote:

From the above I understand that I need to do either of the following:

1) Run the LLBLGen 32 bit application by setting the reference to the 2.11.x.y (ODP.Net) in my machine.config file.

ODP.NET adds this entry during installation. The** .NET 2.0** machine.config file has to have the reference of the factory. This file is in the folder: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG

2) Download the 64bit DLL with the version 2.11.x.y for ODP.Net and Run the LLBLgen for .Net 4.

No, if you want to use the 64bit version of ODP.NET, you need to run the llblgen pro designer as 64bit, which is the default on 64bit windows. It will run on .NET 3.5 which uses the .NET 2.0 CLR (so the factory has to be located in the .NET 2.0 machine.config and the version will be 2.11.x.y).

Yes it's confusing, we moved away from hard references of odp.net to the provider factory system, but oracle managed to make this a struggle as well. Anyway: on 64bit windows, when you simply start the designer directly it will run on the .NET 2.0 64bit CLR. So you need 64bit ODP.NET installed.

In case of the first step whether it is mandatory to have the ODP.Net version 2.X in the Registry? because now I have installed latest version of LLBLGen 3.1 build (as on May 20th,2011) and open the 32 bit application, still I am facing the same error? if it is mandatory Could you please tell How to add the old version of DLL is registry?

It's not the registry, it's the machine.config file. There are two: one in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG folder, which is for .NET 2.0/3.0/3.5 and one in C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Config which is for .NET 4.

The error you get in the screenshot is the result from the fact the machine.config file of the CLR version the designer runs on doesn't have a definition for the ODP.NET db provider factory. It's likely the entry is only added to the .net 4.0 one, not to the .net 2.0 one.

Hi,

Thanks for your detailed help. I have now following the second solution. I have now installed the 64 bit ODP.Net from Oracle. I am now able to run the designer and generate the source code for an Oracle schema.

But I have an existing BL layer which access the DAL which is generated in Win XP machine(32 bit). When I tried to run a unit test from the my BL layer, I got the following error:

Test method AvantiForms.BL.UnitTests.TemplateOrPartMgrTest.CreateNewTemplatepartTest_Creates_New_TemplatePartInDB threw exception: 
System.TypeInitializationException: The type initializer for 'SD.LLBLGen.Pro.DQE.Oracle.DynamicQueryEngine' threw an exception. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'Oracle.DataAccess.Client.OracleClientFactory' threw an exception. ---> Oracle.DataAccess.Client.OracleException: The provider is not compatible with the version of Oracle client

I have also attached a screen shot of the detailed error. It is complains about the DLL "SD.LLBLGen.Pro.DQE.Oracle.DynamicQueryEngine", But when I checked version details of the old DLL(from old BL & DAL app)and the DLL with the same name in the newly created DAL(after updating 64 bit ODP.net), the version details are same. Do you have any idea why it is throwing the above error?

Can you regenerate the failing BL on the new 64 bit machine to see if that makes it work ?

Matt

Hi,

I tried that still the same error exists. When I open the registry for Oracle there is three entiries now. One for ODP.Net which contains 2.X and 4.X entires. It is pointing to the new path "c:\Oracle" I have used the following command to install it.

install.bat odp.net4 C:\Oracle odac
install.bat odp.net4 C:\Oracle odac

This is correct as I have installed 64bit DLLs by install.bat with the above path. BUt Odac is taken from the readme.txt. I though it will be replaced for the old entry for the Oracle_Home. But in the registry the Old key "KEY_ORACLE_HOME" still exists. This is pointing to the path where 32 bit ODP.Net DLLs are present.

Whether the above old entry might gives error? if it is then How to set the new path (64 bit DLL present) as the Oracle HOME? I have attached my registry details as Image.

I have checked the machine.config entries for 32 bit and 64 bit. All the have entries for Oracle Provide for .net.

Since you have both .NET versions installed of the ODP.NET, the question would be which of them does your application use. And thus which version of the Oracle.DataAccess.dll do you reference. Could you please check this out.

Walaa, he doesn't reference Oracle.DataAccess.dll, as he uses v3, which uses dbproviderfactory.

The ODP.NET used is the one related to the bitness of the application he builds: so saravana, I think your own application is a normal application and thus runs as 64bit by default, and the factory used (see my post above about which factory is used based on the .NET version and the machine.config file) is the one for the 64bit ODP.NET, however the Java part (see below) is the one of the 32bit version.

ODP.NET has 2 parts: a .NET part (Oracle.DataAccess.dll, with the factory) and a Java part, which is the OCI, the Oracle Client Interface. The .NET part calls into the OCI which connects to the Oracle DB.

So long story short: uninstall the 32bit version. You don't need it.

This has no influence on what your client has on his XP system: the generated code simply asks .NET for the Oracle dbproviderfactory, and if you install the 32bit ODP.NET on the XP system, it will work with that 32bit system.

Sorry for this trouble, it's extremely confusing and Oracle's fault (you're not the first running into this), but we hope we can get you on track with this.

Hi Otis,

I have tried what you have informed above. But still the same error persists.

The type initializer for 'SD.LLBLGen.Pro.DQE.Oracle.DynamicQueryEngine' threw an exception.

To summarise what I have done and the current envirnonment in my system is as follows:

1)Unstall the ODP.Net 32 bit DLLS using the Oracle Universtal Installer 2)Uninstall Oracle Instant Client using the Oracle Universtal Installer 3)Re-generate the DAL with Target Framework as .Net 4.0 4) Looked at the contents of machine.config (located at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config , C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Config\machine.config C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config, C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config on an x64 OS) and Update the Machine.Config files with the below entries in both 32bit path and 64bit path.

      <add name="Oracle Data Provider for .NET" invariant="Oracle.DataAccess.Client" description="Oracle Data Provider for .NET" type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=2.112.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />

<add name="Oracle Data Provider for .NET" invariant="Oracle.DataAccess.Client" description="Oracle Data Provider for .NET" type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=4.112.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />

As the error still persists, I have even tried generate the DAL code in .Net 3.5 as target. But the probles still there. I am tried to buid the LLBLGen Runtime Libraries Source code but it gives error like cryptogrpahic failure .. strong key name....

Please advice whether I can solve this problem with your latest code? I am also wondering why my installation path of the LLBLgen dosen't contain the Libararies for .Net version 4.

The path C:\Saravana\Avanti\LLBLGen Pro\Frameworks\LLBLGen Pro\RuntimeLibraries have DLLs for .Net version 2.0 only. Is latest availble for 4.0?

There are no .NET 4.0 assemblies. They are not needed, as you can use .NET 2.0 assemblies in .NET 4.0 applications.

Anyway, you said you have uninstalled everything regarding to Oracle Client and ODP.NET. I assume you have re-installed ODP.NET for x86 & x64 , correct?

Ho Wala,

No. I have un-installed only the 32 bit version of ODP.Net DLLs from my machine. The 64 bit version of ODP.Net which is installed already reamins. Also I am not re-install the 32 bit ODP.Net dlls again in my system.

To make it clear:

1)I have now only 64bit ODP.Net DLLS in (C:\Oracle\odp.net). 2)I have update the machine config of the Frmaework64 folder for both .Net2.X and .Net 4.X 2) I have update the ORACLE_HOME entry in registry and system Envirment path to C:\Oracle.

I will be very happy,If I could get a help document on How to make LLBLGen Designer and Runtime work on Win 7 (64 bit)machine. This now has broke my development work as I am unable to test my code.

Regards, Saravana Perumal C

First of all, it's not something we caused, all we do is request the factory from .NET and use that. Oracle's ODP.NET install is however a mess, and this makes things complicated.

We'll try to help fixing this, but as we don't own Oracle's code, all we can do is try to find the source of the misconfiguration and fix what Oracle messed up by advising you to change something. You were able to connect to the database using the designer so there is a way to make this work, so let's focus on making your application work as well

1)I have now only 64bit ODP.Net DLLS in (C:\Oracle\odp.net). 2)I have update the machine config of the Frmaework64 folder for both .Net2.X and .Net 4.X 2) I have update the ORACLE_HOME entry in registry and system Envirment path to C:\Oracle.

Ok. First, test again if you can connect to the oracle database from the LLBLGen Pro designer and refresh the schema.

If that works: - If you simply ran LLBLGenPro.exe, you're using the .NET 2.0 version of odp.net on 64bit. - If you ran LLBLGenPro_NET40.exe to run the designer, you're using the .NET 4.0 version of ODP.NET on 64bit - If you ran LLBLGenPro_x86.exe to run the designer, you're using the .NET 2.0 version of ODP.NET on 32bit.

From what you wrote I think you used the first option, simply run LLBLGenPro.exe. **Test this again, it's important ** If it's not too much trouble, try all 3 and see whether all 3 work. My guess is LLBLGenPro_x86 fails.

If your application is a .NET 4.0 application (not .net 4.0 client profile, choose the full .net 4 profile in the vs.net project properties in vs.net) and the platform target is set to 'x86' in the vs.net project properties, your application is a 32bit application, and you'll use the .NET 4.0 ODP.NET on 32bit. By default vs.net 2010 applications are anyCPU but this changes sometimes (this is a vs.net 2010 limitation), be sure you check it. It can be it's not set to 'anyCPU'. set it to 'anyCPU'.

There's one problem: if your application is a website, it might be running as 32bit application. To test if this is a problem, add a simple console project to your solution and select '.NET 4.0 full profile' in vs.net project properties and reference the generated code. Also make sure the platform target is set to 'anyCPU'.

Copy the app.config file to this project so you have a proper connection string setup. Now in this console application, simply create a connection to the database using the generated code, e.g. by loading some entities. Wrap the call with a try/catch block and write the error to the console using Console.WriteLine() or step through the code in the debugger. To start the console app, make it the startup project of your solution. If this works, it's the 32bit-nature of your website.

Could you please test these things for me?

Hi,

I am finally managed to make my BL and UI test application work with latest DAL genreated using 64bit mode.

If your application is a .NET 4.0 application (not .net 4.0 client profile, choose the full .net 4 profile in the vs.net project properties in vs.net) and the platform target is set to 'x86' in the vs.net project properties, your application is a 32bit application, and you'll use the .NET 4.0 ODP.NET on 32bit. By default vs.net 2010 applications are anyCPU but this changes sometimes (this is a vs.net 2010 limitation), be sure you check it. It can be it's not set to 'anyCPU'. set it to 'anyCPU'.

The above advice make it happen. I have an WPF test application to test my DAL. When I checked the Project properties, The Build - Platform Targer earlier was X86. When I change that to Any Cpu, The application starts working.

Eventhough my BL & unit tests bulild mode is Any CPU, The unit test continued failed. When I checked the LocalSettings File of the unit test project, It has Host Property(TestSettings - Host). Under this earlier setting was to Force Run in 32 bit Mode. Now I have changed to "Run in 64bit process in 64bit machine". After this the unit tests also executed successfully.

Please note that "LLBLGenPro.exe' (default option in the start menu) is used to generate the DAL now. When I used the LLBLGenPro_NET40.exe , I am still unable to connect to DB. well I shall check it later. Fist I need to test the latest DAL & BL from Other machine (32 bit).

Thankyou very much for your timely help.

saravana wrote:

Hi,

I am finally managed to make my BL and UI test application work with latest DAL genreated using 64bit mode.

If your application is a .NET 4.0 application (not .net 4.0 client profile, choose the full .net 4 profile in the vs.net project properties in vs.net) and the platform target is set to 'x86' in the vs.net project properties, your application is a 32bit application, and you'll use the .NET 4.0 ODP.NET on 32bit. By default vs.net 2010 applications are anyCPU but this changes sometimes (this is a vs.net 2010 limitation), be sure you check it. It can be it's not set to 'anyCPU'. set it to 'anyCPU'.

The above advice make it happen. I have an WPF test application to test my DAL. When I checked the Project properties, The Build - Platform Targer earlier was X86. When I change that to Any Cpu, The application starts working.

I suspected as much. Microsoft changed this during the release candidate of vs.net 2010 if I'm not mistaken, because some edit/continue/debugging tools in vs.net don't work on 64bit. It really sucks that this happens, and it can lead to a lot of time wasted... anyway, now you know where to look

Eventhough my BL & unit tests bulild mode is Any CPU, The unit test continued failed. When I checked the LocalSettings File of the unit test project, It has Host Property(TestSettings - Host). Under this earlier setting was to Force Run in 32 bit Mode. Now I have changed to "Run in 64bit process in 64bit machine". After this the unit tests also executed successfully.

Ok.

Please note that "LLBLGenPro.exe' (default option in the start menu) is used to generate the DAL now. When I used the LLBLGenPro_NET40.exe , I am still unable to connect to DB. well I shall check it later. Fist I need to test the latest DAL & BL from Other machine (32 bit). Thankyou very much for your timely help.

If LLBLGenPro_NET40.exe doesn't work, you likely got the initial error you had when you started this thread, that the factory can't be loaded, correct?

Your code should work fine on a 32bit machine, as you install 32bit ODP.NET there, but your code is build against anyCPU, so will use 32bit on a 32bit machine and 64bit on a 64bit machine....

Glad you get things working now