10 Replies Latest reply: Dec 3, 2012 10:29 AM by 958108 RSS

    ODP.NET Managed Driver Beta

      References to System.Drawing and System.Windows.Forms in a data provider Library?! If you just want to provide toolbox icons for the darned component designer or such, you are to supply a separate design-time assembly (e.g. Oracle.ManagedDataAccess.Design.dll). I fear to imagine what do you need System.Windows.Forms for…

      Further, there is still NO SUPPORT FOR RUNTIME DATABASE/SCRIPT CREATION (schema/user in terms of Oracle DB). I posted the request more than a year ago: Programmatic database creation and deletion in ODAC Entity Framework - still nada! Obviously, just nobody cares…
      Similar question: Re: Entity Framework and CreateDatabaseScript - Method

      Oh by the way:
      x64\Oracle.ManagedDataAccessDTC.dll: Platform Target= x64
      x86\Oracle.ManagedDataAccessDTC.dll: Platform Target= Any (?!!)

      Edited by: 879621 on Sep 30, 2012 1:19 PM

      Edited by: 879621 on Sep 30, 2012 1:25 PM

      Edited by: 879621 on Sep 30, 2012 2:07 PM

      Edited by: 879621 on Sep 30, 2012 2:08 PM

      Edited by: 879621 on Sep 30, 2012 2:10 PM
        • 1. Re: ODP.NET Managed Driver Beta
          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"?
          • 2. Re: ODP.NET Managed Driver Beta
            Hi 955105,
            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 :)
            • 3. Re: ODP.NET Managed Driver Beta
              Alex Keh - Product Manager-Oracle
              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
              • 4. Re: ODP.NET Managed Driver Beta
                Hi Alex,

                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.
                • 5. Re: ODP.NET Managed Driver Beta
                  I've posted the new feature request: https://apex.oracle.com/pls/apex/f?p=18357:39:8899698796262::NO::P39_ID:27501
                  • 6. Re: ODP.NET Managed Driver Beta
                    Alex Keh - Product Manager-Oracle
                    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.
                    • 7. Re: ODP.NET Managed Driver Beta
                      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
                      2102 characteristics
                      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.
                      • 8. Re: ODP.NET Managed Driver Beta
                        Alex Keh - Product Manager-Oracle
                        mwwoo is one of the developers on the Oracle .NET team in case people are wondering about the source of information.
                        • 9. Re: ODP.NET Managed Driver Beta
                          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.
                          • 10. Re: ODP.NET Managed Driver Beta
                            I don't understand why the library doesn't sort all this out for the user.

                            if(IntPtr.Size == 8) {
                            // 64-bit
                            } else {
                            // 32-bit

                            Simple enough to P/Invoke to appropriate unmanaged DLL.