This content has been marked as final. Show 10 replies
I'm confused as well. If this statement is true
"ODP.NET, Managed Driver is built with AnyCPU. It runs on either 32-bit or 64-bit (x64) Windows."
why is there two different versions of the assembly? Why can't the assembly truly be "Any CPU"?
why is there two different versions of the assembly? Why can't the assembly truly be "Any CPU"?The provider itself (Oracle.ManagedDataAccess.dll) is AnyCPU.
DTC support is, however, still platform-dependent, that's why it is supplied as a separate assemblies for x64 and x32.
These assemblies are not pure managed, they're mixed-mode for some reason.
Hope they will fix it when it's released :)
Oracle.ManagedDataAccess.dll and Oracle.ManagedDataAccessDTC.dll are managed files. There are two versions of Oracle.ManagedDataAccessDTC.dll because it must know whether to make 32-bit or 64-bit calls to the Microsoft Distributed Transaction Coordinator (DTC). The MS DTC has some APIs that only accept unmanaged calls when coordinating an Oracle transaction.
Oracle has had extensive conversations with the Microsoft DTC architect and development staff to find a solution that eliminates any need for platform-specific calls. The conversations concluded that Microsoft must add new managed APIs to the DTC for Oracle transactions. When Microsoft will add these APIs has not been announced. Oracle has asked these APIs be made available ASAP. As soon as Microsoft provides support, the needs for unmanaged calls by Oracle.ManagedDataAccessDTC.dll disappears.
Note: If you do not use distributed transactions, you do not need Oracle.ManagedDataAccessDTC.dll. You can just use Oracle.ManagedDataAccess.dll.
Regarding feature requests, please make them on the Oracle .NET Feature Request Tool:
They are much easier to track and prioritize with the tool than on the discussion forum.
Edited by: Alex Keh - Oracle Product Manager on Oct 8, 2012 5:00 PM
it's perfectly clear that the two assemblies have to be platform-specific for a reason. My original question just stressed the fact that one of them (that in the folder x86) is in fact NOT platform-specific (Platform Target=‘Any’, instead of ‘x86’), whereas the other one IS (Platform Target=’x64’, in folder x64). Is it an oversight or done deliberately (why?) ? And BTW, the assembly OraProvCfg.exe in x86 is built just fine with Platform Target=’x86’, only the corresponding library - not. Kind of misleading.
What is more important are the references to System.Drawing and System.Windows.Forms. Is there any case these libraries need to be loaded in run-time? According to my tests they wont’t get loaded, but I couldn’t prove it by inspecting the source code because parts of the code are obfuscated with SmartAssembly. I only could see the System.Drawing is needed in the main assembly to provide an icon for the component designer toolbox (ToolboxBitmapAttribute). Despite the both referenced libs are parts of BCL and there is no client profile in .net 4.5 anymore, there still can be deployment policies dictating no GUI-dependent components are ever loaded on the server side. So we just need to be sure that such policies are satisfied, and if not – when exactly they can be violated. And in case the references are only needed in design-time, it would be even more preferable just to have all such dependencies in a separate bunch of assemblies (Xxx.Design.dll) that aren’t going to be redistributed. Otherwise I would rather sacrifice any design-time support requiring dependency to any GUI-components in favor of run-time dependency transparency. Honestly, I just hardly can imagine a serious developer implementing data access by dragging components from the toolbox.
Thanks for bringing these two issues up. We'll fix both the Platform Target and System references issues in the second beta.
Regarding your feature request, you may also want to vote for the Code First feature request:
It is overlapping, though not exactly the same, as your feature request.
The Oracle.ManagedDataAccessDTC.dll that we built for 32-bit is a correct x86 build and targets the win32 platform. This dll does NOT target to AnyCPU
I have verified it by 3 different strategies:
1. Running "dumpbin.exe /headers" on the win32 Oracle.ManagedDataAccessDTC.dll provides the following results. The result indicates that the Oracle.ManagedDataAccessDTC.dll is a valid win32 dll.
Dump of file Oracle.ManagedDataAccessDTC.dll
PE signature found
File Type: DLL
FILE HEADER VALUES
14C machine (x86)
5 number of sections
5074282C time date stamp Tue Oct 09 06:35:40 2012
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
32 bit word machine
OPTIONAL HEADER VALUES
10B magic # (PE32)
10.00 linker version
2. Running the "Corflags.exe" on the win32 Oracle.ManagedDataAccessDTC.dll utility provide the following output. The result does NOT imply that the win32 Oracle.ManagedDataAccessDTC.dll is targeting AnyCPU platform. The result that we see is consistent with other Gac32 dlls (egSystem.Data.dll..etc)
Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 24
ILONLY : 0
32BIT : 0
Signed : 1
A dll that targets AnyCPU platform must have the following properties.
PE : PE32
ILONLY : 1
32BIT : 0
So, the CorFlags result does NOT imply that the win32 Oracle.ManagedDataAccessDTC.dll is targeting AnyCPU platforms.
3. Runs x86/win32 application that depends on the win32 Oracle.ManagedDataAccessDTC.dll. It works well.
4. I have also tried to run a x64 application that loads the win32 Oracle.ManagedDataAccessDTC.dll. An exception is thrown that indicate
that the win32 Oracle.ManagedDataAccessDTC.dll has a badImageFormatted, which also proves that the win32 Oracle.ManagedDataAccessDTC.dll does not run on
x64. This implies that the win32 Oracle.ManagedDataAccessDTC.dll does NOT run on x64 platforms.
5. Our ManagedDataAccessDTC project settings contains machine setting that targets x86 platform.
I only did a quick check with .Net Reflector and it reported me "Platform Target = Any". Now I've re-checked it using AssemblyName.ProcessorArchitecture and Module.GetPEKind() and can confirm everything is fine with it. Apparently, there is a bug in .Net Reflector in how "Platform Target" is discovered (only 32BITREQ flag seems to be considered). I apologize for this confusion.