1 2 3 Previous Next 32 Replies Latest reply: Aug 19, 2013 1:44 PM by Alex.Keh .Product.Manager-Oracle Branched from an earlier discussion. RSS

    ODP.NET NuGet support

    user3939382

      Will this be going up on NuGet at any point in the near future?

        • 1. Re: ODP.NET NuGet support
          Alex.Keh .Product.Manager-Oracle

          No, this is not planned.

          • 2. Re: ODP.NET NuGet support
            user3939382

            Really?   So only the 11g version will be available via NuGet?

            • 3. Re: ODP.NET NuGet support
              Alex.Keh .Product.Manager-Oracle

              Oracle itself has not created any ODAC 11g packages for NuGet.org.

              • 4. Re: ODP.NET NuGet support
                user3939382

                Ah, that's interesting.  It's completely non obvious that those aren't the official packages- if you use the IDE's package manager they are just listed as created by "Oracle"   (The website does show that these were uploaded by a 3rd party- but most folks will be using the package manager)

                 

                It would be nice if Oracle would consider this in the future (either by using the standard NuGet archive or by hosting their own repository) as this is increasingly how .Net packages are being managed.

                • 5. Re: ODP.NET NuGet support
                  Alex.Keh .Product.Manager-Oracle

                  My team has had some discussions regarding supporting NuGet. The community has also requested this feature. I'll be interested to see if the number of votes increase now that managed provider is now available.

                   

                  My own hypothesis is that many people have requested NuGet support since unmanaged ODP.NET could be difficult to setup and configure at times if more than one Oracle Client existed on the machine. I can see the case why developers want a NuGet unmanaged ODP.NET package.

                   

                  With managed ODP.NET, those issues have been mostly resolved. Managed ODP.NET is not dependent on any other .NET libraries besides a few standard .NET data access classes that are already a standard part of .NET Framework. It doesn't require any generic app/web.config file settings to be made. NuGet does save you from the process of downloading from OTN and running the installer, but these benefits are minor compared to the project setup ones.

                   

                  On the down side, NuGet doesn't GAC assemblies. It can't include the Oracle Developer Tools for Visual Studio, which are an important design-time tool set ODP.NET developers use. The universe of potential benefits becomes much smaller when considering these aspects.

                   

                  Nonetheless, I'd be interested to hear what people think. Feel free to reply to this thread.

                  • 6. Re: ODP.NET NuGet support
                    user3939382

                    At least with my implementation- I'm really just looking for the managed driver- one less piece of software a new team member would need to install to get our product working (especially for folks who aren't going to be working on the DB interface and don't otherwise need the Oracle client installed)    Plus one less place to check for updates.

                     

                    At the moment we have a conditional project inclusion of the unmanaged drivers and are coexisting the x32 and x64 stacks on developer machine.   With edit and continue now supported in VS2013 we'll (finally) be able to jettison x32 entirely and just have x64.  
                    Was contemplating moving to the unmanaged driver and that investigation was what lead to this thread.  With the new EntLib now in NuGet we now are getting all of our external packages from NuGet except for ODP.net and DevExpress.

                    • 7. Re: ODP.NET NuGet support
                      Lannie Liberty

                      I'd rather get my software directly and only from Oracle.

                      • 8. Re: ODP.NET NuGet support
                        SeanKilleen

                        I think there are some definite advantages to the developer community, especially considering that the effort isn't prohibitive to produce a Nuget package as part of a build process.

                         

                        I'll try to make some points in support of a Nuget package below.

                         

                        • Dev tools is overkill: While i agree that the developer tools are an important part of working with ODP.NET, for many quick data-access scenarios or mapping scenarios (say with NHibernate), oftentimes the developer tools aren't needed because you're not necessarily doing design or generating a large portion of a model. I don't think devs will forget about the developer tools if they can get their hands on a nuget package; in fact, you could even include information about it in a Readme that will be displayed automatically.
                        • Forcing an install for lightweight components is unfortunate: DLL While I understand that ODAC will have a better install package, with xcopy, while we wait for that release I am stuck. I am unable to install the 12c client on my machine due to a path issue (who would think that an entire client install would be necessary for a handful of DLLs?) It is leading me to literally make posts to see if someone will e-mail me the DLL files zipped up. (if anybody is willing to do that here with the 12c odp.net managed DLLs, let me know -- I'd greatly appreciate it)
                        • No GAC is a good thing to me: Not GACing the assembly is one of the bigger advantages of Nuget IMO. I don't want the assemblies to be in the GAC; I want them to be referenced in my lib folder as part of my build & integration process. I think it's a bit of a paradigm shift from "install this everywhere you're doing to run it". I like things to be more self-contained with less dependencies on the surrounding system.
                        • Shifting Paradigms: For many in the .NET world, nuget has removed so much hassle that it's basically the "way we do things" now. So while Oracle resolved a lot of the dependency issues by just releasing the managed library (and seriously, kudos on that), a lot of devs feel now like not having it available on Nuget is like forcing devs to jump through hoops. And forcing us to install a software suite to get to what we know are static DLL files might be taken the wrong way. In the age of Nuget, Oracle's current process makes it seem behind the times.
                        • Confusion around unofficial packages: As someone else posted, developers are coming to expect that packages be created for software such as this because Nuget has become an indispensable part of the ecosystem. As a result, when a package doesn't exist, folks tend to try to create one. However, when this isn't a vendor-supported option, it can cause confusion. Most vendors want to be the ones releasing their packages to Nuget.
                        • Ability to show configuration examples: Nuget allows you to add entries to web.config, and I think you can add comments as well. That seems like an opportunity to express examples of all of the great configuration that ODP.NET allows.
                        • A great commitment to developers: This isn't a game-changer, as it's clear you already care about developers. But to me, the fact that I can open Visual Studio, type in "Install-Package", and have everything just work tells me that the developers of that library don't just care about functionality, they care about ease of use and they care about enabling my productivity by saving me time. You're not sending a negative signal by not doing it, but it would be a hugely positive thing if it was there.
                        • It's not too difficult: Assuming that the build process at Oracle is fairly sophisticated, if you have an integration server outputting your DLLs, you can build a nuget package every time the build passes. For reference, Scott Hanselman wrote a pretty good article on the subject (though it's from '11 and may be a tiny bit dated now). So hopefully it could become a set-it-and-forget-it with minor tweaks here and there. Particularly if you plan to keep the number and names of DLLs fairly stable (which makes sense), you won't have to update the Nuget packages.

                         

                        I know I'm evangelizing a bit, but you asked for my thoughts. Thanks for being so open to receiving our feedback!

                         

                        ___

                         

                        Addendum -- To make the point about developer productivity, I'm going to narrate the process I just had to take to get the ODP.NET DLLs. Admittedly it's going to suffer a bit because ODAC isn't out yet, but the idea will be the same.

                         

                        What I would have done with Nuget:

                         

                        1. Open my Project
                        2. Type "Install-Package ODP.NET"

                         

                        What I did instead (keep in mind, I only need the DLLs to copy and paste them into a folder within my VS Solution):

                         

                        1. Went to Oracle's Web site
                        2. Downloaded the 2 GB Server installer which took a little bit.
                        3. Extracted the zip file which took a little bit.
                        4. Right-clicked on setup.exe and selected "run as administrator".
                        5. Received 30-40 popups from my company's security software (when programs attempt to launch other programs/processes, you have to allow them unless it's been whitelisted). Clicked allow on each one.
                        6. Went through the install but was told that my path was too long.
                        7. Went into environment variables and had to pick through which path entries to remove.
                        8. Realized I would be better served with the client.
                        9. Repeat steps 1-5 with client software download.
                        10. In the installer, choose a custom installation to be sure I can install odp.net
                        11. Receive a random error "[INS-30131] Initial setup required for the execution of installer validations failed." The details of which are "Cause: Cause of problem not available" and "Action: User Action not available". I also see "Framework setup check failed on all the nodes" and "Version of exectask could not be retrieved from node "[my machine name]"
                        12. Restored the path to its original values (I'd copied the original to a backup).
                        13. Tried again; no luck.
                        14. Now I'm stuck. I can install an entire database server on my desktop, or I can hunt through support forums to fix a generic error message.

                         

                        Now factor in that I have a project due on Friday that I need to use ODP.NET for, and you begin to understand the extent to which Nuget can be helpful to a developer.

                        • 9. Re: ODP.NET NuGet support
                          Alex.Keh .Product.Manager-Oracle

                          Sean,

                          I appreciate the feedback. I'd like to hear your thoughts when ODAC 12c is out. We've made an improvement in the install process where you can set up your tnsnames.ora from within Oracle Universal Installer if none exists on the machine. If one does exist on the machine from a previously used home, we copy that file and sqlnet.ora over to the new managed ODP.NET Home. That's a step NuGet can't automate for you.

                           

                          A few comments in response to your points:

                           

                          When install the Oracle Dev Tools for Visual Studio, it automatically installs ODP.NET, managed and unmanged, already. While dev tools may be unnecessary in some situations, developers who use Oracle will already have it installed, which means ODP.NET is already installed. It seems unnecessary to have to get a NuGet package for software that is already on the target machine.

                           

                          For GAC concerns, the xcopy package is customizable. You don't even need to run the configuration batch file if you want to skip GAC, adding to the machine.config, etc.

                           

                          With that said, my team will consider your points. Thanks for posting.

                          • 10. Re: ODP.NET NuGet support
                            Jesse

                            I second Sean's feedback, it's exactly right.

                             

                            A package will alert when there is a new version is available for updates, you don't have to watch for it.

                             

                            Just one question from your response, you imply that you can use the managed provider without running the xcopy installer, is that correct?  You can just add a reference and that's it?

                             

                            Jesse

                            • 11. Re: ODP.NET NuGet support
                              SeanKilleen

                              Hi Jesse,

                               

                              Thanks for the +1 and advocating on this. The ability to run "update-package" and have it get the latest version (and to specify if you want a pre-release even) is definitely a huge bonus.

                               

                              Regarding your question about xcopy, to me the brilliance of the managed DLL is that it's just that -- a DLL file. I copy it into my solution's directory (usually in a "lib" folder), I reference it in my application, configure my settings in my web.config, and I'm off to the races. I didn't have to install Oracle on the server, I didn't have to go through a bunch of overhead. There really is a beauty in the managed provider DLL in that regard. The ODP.NET team has done some awesome work to support that endeavor; I really think it's commendable.

                               

                              Regarding xcopy, the reason I'm advocating for the Nuget package is that right now, you have to run the installer so that it will extract the DLLs. After that, you can copy/paste. If the xcopy installer has them decompressed already, you could likely just copy them without actually running the installer.

                              • 12. Re: ODP.NET NuGet support
                                Alex.Keh .Product.Manager-Oracle

                                With ODAC 12c, there will be a managed ODP.NET only download around 2 MB in size zipped up. You can just download, unzip, and import the DLL into your project. There is no need to run the configuration script batch file to use managed ODP.NET if you want to replicate what NuGet does. All the batch file does is GAC the assembly, setup performance counters, setup machine.config, and a few other config steps. The batch file can be modified so that admins can customize their deployments as needed.

                                 

                                Oracle can add sample .NET config files to the zip file if developers prefer it. Currently, Oracle places .NET config sample scripts in our documentation. There are many different ODP.NET configuration options that a single .NET config file would not be able to present things in a summarized manner. There are pages and pages of documentation of attribute settings and possible values, especially with managed ODP.NET. With unmanaged ODP.NET, having a sample .NET config is much more possible. With managed ODP.NET, you've got all of ODP.NET's settings, plus TNS, SQL*Net, and LDAP settings. And those settings can have multiple values.

                                 

                                I can see some benefit in being able to quickly move up and down versions or getting informed when a new update is available. However, a new ODP.NET release comes out one to two times a year. There aren't that many updates to track. For new download alerts, @OracleDOTNET Twitter and the monthly Oracle .NET  newsletter already suffice as methods to get passive alerts.

                                 

                                One thing I would your feedback on is distinguishing the exact NuGet support manifestation you want. Do you want:

                                A) Oracle to host a package on nuget.org (or any other publicly available NuGet feed)

                                B) Oracle to host a NuGet package on oracle.com

                                C) Oracle to provide a pre-built NuGet project with every managed ODP.NET release. That would allow you to customize it for your team and host your own NuGet server to deliver the customized packages.

                                 

                                You may choose more than one, but priority is what I'm looking for.

                                • 13. Re: ODP.NET NuGet support
                                  SeanKilleen

                                  Hi Alex,

                                   

                                  Thanks for being so open to the idea and the discussion. Some responses below:

                                  With ODAC 12c, there will be a managed ODP.NET only download around 2 MB in size zipped up. You can just download, unzip, and import the DLL into your project.

                                  This sounds like a great start, and I really appreciate that the team is working towards this.

                                  Oracle can add sample .NET config files to the zip file if developers prefer it. Currently, Oracle places .NET config sample scripts in our documentation.

                                  My thinking is that sometimes a library, when added via nuget, will modify the Web.Config to include some comments about sample configurations since that's where the config will wind up. I've really appreciated this since I get a lot of insight as to some potential real configurations, set up right in the web.config files. It doesn't have to be every possible example, but I think that with a small amount of effort you could easily cover 70% of use cases.

                                  I can see some benefit in being able to quickly move up and down versions or getting informed when a new update is available. However, a new ODP.NET release comes out one to two times a year. There aren't that many updates to track.

                                  I think about this more in terms of workflow. When starting a project, I might add 30+ Nuget packages that I know I'll be using. Oracle is currently the one exception that makes me go somewhere else, to another web site, download files, extract them, copy into my directory, manually reference the DLL, and then enter the config. I'm not saying this is necessarily unacceptable, but I'm sure you can appreciate the added value of being able to stay in that workflow.

                                   

                                  The ability to use ODP as a Nuget package also better enables things like project templates that will always have the latest version of the Oracle packages, etc.

                                  Do you want:

                                  A) Oracle to host a package on nuget.org (or any other publicly available NuGet feed)

                                  B) Oracle to host a NuGet package on oracle.com

                                  C) Oracle to provide a pre-built NuGet project with every managed ODP.NET release. That would allow you to customize it for your team and host your own NuGet server to deliver the customized packages.

                                  In an ideal world for me, Oracle would host an ODP.NET official nuget package on nuget.org, and would update "pre-release" versions with every successful build and main release versions to correspond with traditional releases.

                                  • 14. Re: ODP.NET NuGet support
                                    Edmund_Poillion

                                    I had the same issue, needed the files but couldn't install the client.  What I did was "unzip" all the jar files in the client install and search for the files I needed.  I did this with the 32 bit client I downloaded from Oracle - winnt_12c_client32.zip.  Here's how to get the Managed OPD.NET files:

                                     

                                    - Extract the winnt_12c_client32.zip file.

                                    - Locate the following path in the unzipped files: client32\stage\Components\oracle.ntoledb.odp_net_2\12.1.0.1.0\1\DataFiles.

                                    - There are 38 .jar files in this folder, extract the contents of each of these to the same location, they each contain a some of the needed files.

                                    - If you go to the location you extracted the .jar files to...

                                        - The Oracle.ManagedDataAccess.dll is under odp.net\managed\common

                                        - The configure/unconfigure .bat files for 32-bit are under odp.net\managed\x86

                                        - The configure/unconfigure .bat files for 64-bit are under odp.net\managed\x64

                                        - You can look around the rest of the folders for other bits.

                                     

                                    I was able to use these files to get the managed ODP.NET driver working in my application, hope this helps you out as well.

                                     

                                    Thanks, Edmund

                                    1 2 3 Previous Next