4 Replies Latest reply on Sep 26, 2013 6:29 PM by landyman

    using managed odp.net




      We have several .net applications running on client machines that target the unmanaged odp.net driver.


      Now, if we write any new .net application that targets the managed odp.net,

      should i install 12c cleint on all the client machines?


      What steps do i need to follow to avoid installing 12c client on all the client machines.?


      On searching the forum , few members have mentioned that I can extract 12c client and only

      add the essential dll files related to managed provider.
      Is there a list of which files are essential to use managed odp.net?


      If i do extract all the dll's successfully and use in a project, and i deploy the project to client

      machines, will it work successfully? (publish the project to client machines along with these new dll's)



        • 1. Re: using managed odp.net

          You just need to deploy the Oracle.ManagedDataAccess.dll (CopyLocal) with your application, and make sure that you're using configuration settings within app.config to alleviate the need for TNSNAMES.

          • 2. Re: using managed odp.net

            Here is a sample 'sanitized' app.config from one of my recent small scripts that touches a RAC database, but does not require TNSNAMES on the target server:


            <?xml version="1.0"?>



                <section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess" />

                <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />



                <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>



                <version number="*">


                    <setting name="TraceLevel" value="0" />

                    <setting name="TraceOption" value="0" />

                    <setting name="TraceFileLocation" value=".\" />



                    <!-- create your alias here for your test database -->

                    <dataSource alias="orcl.company.com" descriptor="(DESCRIPTION=(ADDRESS_LIST=(FAILOVER=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1.company.com)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2.company.com)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host3.company.com)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host4.company.com)(PORT=1521)))(CONNECT_DATA=(FAILOVER_MODE=(TYPE=select)(METHOD=basic)(DELAY=50))(SERVER=default)(SERVICE_NAME=BLAHBLAH_SERVICE)))"/>       




              <log4net debug="true">

                <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">

                  <file value="./TestCase.log" />

                  <appendToFile value="true" />

                  <rollingStyle value="Size" />

                  <maxSizeRollBackups value="10" />

                  <maximumFileSize value="50MB" />

                  <staticLogFileName value="true" />

                  <layout type="log4net.Layout.PatternLayout">

                    <conversionPattern value="%-5p %d %-30.30c{1} %-25.26M - %m%n" />




                  <level value="ALL" />

                  <appender-ref ref="RollingLogFileAppender" />




                <!-- reference your test db in the connection string -->

                <add name="TestDB" connectionString="user id=scott;password=tiger;data source=orcl.company.com"/>   



            • 3. Re: using managed odp.net

              Thanks for your quick reply.


              So download the odac 12, extract the relevant dll's and reference in your application. Right?

              And ofcourse while deploying using copylocal to distribute to the client machines.

              • 4. Re: using managed odp.net

                I recommend downloading the full 12c client to your developer workstation, that way you get SQLPLUS and all the goodies. ODP.NET and the ASP.NET stuff comes along with it by default now, so I am not sure you would ever need ODAC if you just install the full client. I always create a folder in my solution structure for dependencies and COPY in the Oracle.ManagedDataAccess.dll then add a reference from that location. This way, if you're using Source Control (which we all do, right?) then it doesn't complain about a referenced file being outside of the solution folder structure.




                C:\blahblah\VSProjects\MySolution\MyProject\ would contain your project

                You create:

                C:\blahblah\VSProjects\MySolution\ExternalDependancies or something along those lines, and copy the DLL there.


                Then, in VS, you right click on  your SOLUTION, then go to Add -> New Solution Folder. Call it "External References" or something.


                Then, right click on the new folder and Add -> Existing Item. Select the DLL, and now VS knows about the file. When you're checking in your solution, it will be copied up there.


                THEN, right click References in your PROJECT and navigate to the ExternalReferences folder you made and add the DLL that way to your project. Once it's in your references list, go to properties and make sure Copy Local is true. Voila, c'est fini.