ODP.NET

No, this is not planned.

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

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

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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

Hi Edmund,

thanks for providing that advice; however, the issue is the juxtaposition of those steps vs. typing "install-package odp.net" into Visual Studio. From a time, effort, and centralization/standardization perspective, Nuget is increasingly the go-to solution for these sorts of package management setups.

I 100% agree with you and would also like to see an "official" Oracle NuGet package available.  I just wanted to share the workaround that enabled me to keep moving forward while we wait for the ODAC release and possible NuGet release.

Another argument for supporting NuGet is package recovery. I don't want store dependencies in source control. Without NuGet I can't. Installing Oracle on build machine/controller is not option because of lack of administrator privileges.

Please fully support NuGet it just makes .Net dev so much better for continuous integration using a build server as Slawek said.

Alex_Keh-Oracle_Product_Manager wrote:

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.

Is that available yet? I haven't seen it, and it's what I need.

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.

A, definitely. The beauty of using NuGet is that it's low-maintenance, I don't want to have to tell every developer in the shop to go add the Oracle feed for one package. All I want to be able to do is to get the managed provider with minimal fuss.

Please, please, PLEASE release a NuGet package of the managed libraries. We have had so many internal issues with Oracle Client/ODT/ODP.NET installation and setup that SQL Server has started taking a substantial hold. I'm literally here right now because I have some work to do on an Oracle project and needed to see what managed solutions were available. When I saw this post title containing both "ODP.NET" and "NuGet" I squealed like a little girl. I will be trying the unofficial package that is already on there in the next few minutes before I click on the finished download of ODTwithODAC. The ease of receiving automatic updates and choosing versions is so vital that I often make tool selections based upon if it is available as a NuGet package (EntityFramework, MVVM Light, log4net, etc). I don't need anything from Oracle except the .NET data provider libraries and SQL Developer. If both of those became independent of a client or large tools package installation then my stress level with Oracle database  app development would plummet.

ODAC 12c is now available for download.

Once you have used ODAC 12c and ODP.NET, Managed Driver that comes with it, let me know your feedback, especially if there remains major reasons to host managed ODP.NET on NuGet.

Here's a direct link to the 2 MB ODP.NET, Managed Driver download.

And don't forget to vote for ODP.NET NuGet support in the Oracle Feature Request Tool if you still want this feature after you try out managed ODP.NET.

Many of you have hinted at the answer indirectly, but I want to make sure I have captured your priority correctly. If Oracle could not host on nuget.org, but could on OTN, would you use this NuGet feed instead?

> If Oracle could not host on nuget.org, but could on OTN, would you use this NuGet feed instead?

This would be better than not having NuGet at all, but definitely not as desirable.

What I believe you would end up with is folks making unofficial copies of the packages on NuGet.org.

Is the hesitence to use NuGet.org technical or legal?

> Is the hesitence to use NuGet.org technical or legal?

Legal.

Alex_Keh-Oracle_Product_Manager wrote:

> Is the hesitence to use NuGet.org technical or legal?

Legal.

What aspects of legal are troubled by this? Nuget packages can require acceptance if a license agreement and community members also agree to abide by the licenses of packages they download. Essentially this mimics Oracle's flow by making someone accept a license before allowing the download / installation. Is there a concern beyond enforcing license acceptance?

I think that while an oracle-hosted package is a second choice, it's a distant second because it still adds an additional layer and special workflow that must be done to accommodate oracle versus every other package provider.

In other news, great to hear about ODAC 12c -- thanks for that update!

It's not the legal concerns around downloaders. It's the legal rights around how uploaded software is treated.

-----------------

https://www.nuget.org/policies/Terms

User Submissions.

Outercurve does not want to receive confidential or proprietary information from User through the Web site. Any material, information, or other communication User transmits or posts ("Communications") to the Web site will be considered non-confidential and non-proprietary and Outercurve will be under no obligation of any kind with respect to such information. Outercurve will be free to reproduce, make derivative works from, use, disclose, and distribute the Communications to others without limitation. At our sole election, Outercurve may provide authorship attribution by listing User's name.

-----------------

As soon as I upload something to the Outercurve Foundation (via nuget.org), I've given them plenary rights to the software. That's a big problem for most commercial software distributions, including ODP.NET.

If you're an open source vendor, then this policy is fine. If Outercurve wants to distribute commercial software, it cannot co-opt ownership rights. This is the biggest issue, but there are others. For example, how can Oracle ensure that no one else on the site represents themselves as Oracle? There's no way to authenticate the "author", especially if you're downloading directly within Visual Studio.

Fundamentally, all these business issues can be boiled down to characteristics of open source (i.e. bazaar, torrents) distribution. If Outercurve introduced closed source/commercial-friendly (i.e. cathedral, iTunes) distribution, it would eliminate pretty much all of Oracle's business/legal concerns. But Outercurve is devoted to working with corporate developers in open source environments. If the component is closed source, then it doesn't fit within Outercurve's mission. That makes me skeptical they would ever support commercial distribution.

Essentially, Oracle would need to open source ODP.NET just for nuget.org distribution. That is like putting the cart before the horse.

Now, if somebody created a commercial software NuGet distribution channel, people could purchase, rent, or try out commercial software from it. That would be something Oracle would consider. That's why I asked about an alternative popular NuGet feed.

That's a really interesting business problem that I wasn't aware of, Alex, and I'm glad you brought it to my attention.

Given these circumstances, presented in the way you've presented them, I wouldn't gripe about Oracle releasing on its own channel. However, I'd love to see this as an opportunity for commercial and open source ecosystems to find a way to work it out. The gains in productivity are too numerous to let the licensing snafu get in the way.

I'm going to try to look into whether this problem has been resolved in any satisfactory way before. In the meantime, I think a great first step would be for oracle to release on its own nuget feed while indicating its willingness to add the package to nuget.org should the licensing be resolved. This would show the serious commitment to developers and our productivity while simultaneously highlighting a flaw in the nuget ecosystem. Developers shouldn't have to deal with a lack of packages, but oracle shouldn't be foraced to give up anything to make this happen, either.

Would be a potentially great case study if we could find a win/win on this.

Eew, yeah I can see how that is a problem.

Maybe it'd be worth contacting them and trying to find a solution? It's far better usability wise to have it hosted in the main nuget repository.

Maybe it'd be worth contacting them and trying to find a solution? It's far better usability wise to have it hosted in the main nuget repository.

FWIW, I reached out to the nuget team on twitter and provided a link to this discussion. Other devs may wish to do the same. Twitter.com/nuget

If someone from Outercurve Foundation reads this thread, they can contact me at alex.keh (at) oracle.com. Or if someone knows the Outercurve contact, email me and I will get in touch with them. We can see if we can work something out.

Hi all -- this is Sean Killeen. Trying to transition to a new account as I'm leaving my employer for a new position. Responding here so that I'll be tracking and users will be able to recognize my strange display name (that I can't change for some reason).

Thanks,

Sean

You can't change your handle to one that already exists. That prevents two unique users appearing as the same person. Since "SeanKilleen" already exists, you can try "Sean-Killen" or "SeanKillen2" instead.