I've been wandering on the net and I encountered a lot of message like this one
Link
ODP.NET and it's stability.
Wow, ODP.NET 10.2.0.20 is not horribly stable yet.
I find rather astonishing that such big editor releases a product that is not stable but it seems so, so should ODP be used ? Is there anything more sure ?
I always had the impression that Oracle doesn't care a great deal about .NET and MS technologies in general (which is understandable). ODP.NET doesn't fit the ADO.NET 2.0 model very well (the way it handles transactions, command parameters bound by order rather than name...). But anyway, since Microsoft has deprecated its own Oracle provider (System.Data.Oracle), you don't really have a choice... Sure, there are third party ADO.NET providers for Oracle (like the one from DevArt), but they're not free. So if you want a free ADO.NET Oracle provider, you're stuck with ODP.NET anyway
To answer the question more directly : I wouldn't say that ODP.NET is not stable. It might have a few bugs, but it's very widely used in production environments all over the world, which wouldn't be the case if it was really unstable. So I'd say it's quite unlikely that you will encounter major bugs.
The post you are quoting is 2 years old. Current stable version is 11.1.0.7.20. I haven't used it personally but I would use it for production.
If there will be problems with that (or any other components of your application) the testing should find the problems before deployment.
Get the latest stable version from Oracle's site. But even then you'd realize that there are still connection leaks. Even though the following steps might not solve your problems completely, they certainly help:
Use the using(){} construct
Write a batch process to drop all connection to your db on a regular basis. In my experience every other week for a VERY BUSY website.
Let me know if there is a better way!
Related
I was about to use the existing Serilog's SQL Server sink but I realized that the latest pre-release and stable versions do not support ASP.NET Core.
Is there an alternative to this sink? What am I supposed to do? Should I write a new sink?
The Serilog sink for SQL Server depends on some types not yet in .NET Core. Work started to refactor the sink and remove the dependencies, but since then, the types in question have been added to the next .NET Core version:
https://github.com/dotnet/corefx/pull/12426
Due to this, the Serilog SQL Server sink will most likely remain .NET Framework-only until the next .NET Core/.NET Standard release, after which support will be quick to add.
In the interim, writing a quick implementation of ILogEventSink of your own would be a reasonable way to get unblocked.
I can't tell you what you're supposed do, but I can describe a couple options. The Sql Server Serilog provider on GitHub would be a better place to ask the question of what they intend to do.
Serilog is indeed on the .Net Core train, as many, many other mainstream .Net projects are. You are correct that as of today, the SQL server sink is .Net 4.5 only. You can:
Continue developing your ASP.Net Core project, target .Net 4.5 in your project json, build and deploy to windows OS only, but carry on using SQL server sink.
Many companies are migrating to .Net Core but targeting .Net 4.x.x in order to keep 100% back compatibility with existing packages while the kinks are ironed out in the framework. This has been a viable solution for my large scale projects.
Target .Net Core, and write your own logging repository layer to manage custom SQL and database log dumping code.
If you're in core, this is easier than it sounds, but requires experience with Data Repositories and IoC. Any code that needs to dump logs to the database would have to have some sort of "ILoggingRepository". It does however, duplicate calls to logging methods, in addition to deviation from the ILoggerProvider interfaces in Microsoft.Logging.Abstractions - forgoing the flexibility of log levels and such, unless you decided to re-engineer your own. It's a working solution; I never said it was an elegant one.
Write your own Serilog sink.
I don't have experience with this one, but I have seen code samples that describe details of how to accomplish this. The reason I never pursued this option is due to a fear that by the time I finished writing my beastly database sink, the open-source community would rework the Sql Server version into a fully core-compliant and database independent version. This would be the most heavy-handed solution, but also the most robust.
There may be other sinks available for .Net Core, but if you're looking for the SQL server one specifically, then you most likely are working with constraints that prevent using MongoDB sinks and file providers and such.
I guess the question is not really technical, but rather a philosophical one, then I do not propose an answer, but consideration:
In my humble opinion, Microsoft with its Silverlight killing, UWP orientation and "escape to clouds", admitted defeat of its entire concept of proprietary software development, so liberation of dotnet platform is nothing more than the farewell gift for developers, deceived in their hopes.
By itself, dotnet ecosystem is very promising, but its future has little to do with the Microsoft products, as it was before. At least, I hope as a developer who has been working with Microsoft products more then twenty years. Therefore, common infrastructure libraries that were focused on concrete Microsoft products (I mean MS SQL Server in this current case) are dying now.
Therefore, the conclusion is: if you already have long-term project that tightly coupled with SQLServer, maybe it is better to put some efforts to your current logging solution adaptation, otherwise it is better to look for some logging solution, not dependent on MSSQL. Probably it should support different storages via adapters or something like that.
Try to look at this, they declare Core support in next version, at least this is a live project.
Yes I still use the older version of the .NET Framework & love it. Would like to use a database wrapper now massive by rob is awesome if I had 3.5 but Nooooo.
You got any suggestions for a database wrapper ?
Please don't suggest a ORM(ex NHibernate, Active Record) all we do is write stored procedures and supply them parameters in our data access layer. Nothing more nothing less, we are thinking of abstracting away parameters as object now thinking wrapper might be out there or rolling out our own.
Dapper dot net - written by Sam Saffron of Stackoverflow fame - is a good alternative to Massive, and it's very similar, but also supports .NET 3.5.
https://github.com/StackExchange/dapper-dot-net
But you definitely need to upgrade to at least .NET 3.5 - 2.0 is really really REALLY old by now..... since it still uses the same CLR version (2.0), it shouldn't be any problem anyway - just upgrade - it's not more effort than installing a security update...
The 3.5 support is a bit less "elegant" in some places (like when you need to provide lots of parameters to a method call, since 3.5 doesn't have optional and default parameters yet), but it works like a charm!
It handles stored procedures without any problem - even those that return multiple result sets....
If you really cannot upgrade to .NET 3.5 (why is that again??), then the best you can do is the Microsoft Data Access Application Block - but that's light years behind the nicety of Massive or Dapper.NET .....
How about Microsoft's Enterprise Library? Older versions that will work with 2.0 are still available. I've used this in the past quite effectively (although we have since moved to the Entity Framework in 3.5).
I've seen there is a plenty of them. NCache, Velocity and so forth but I haven't found a table comparing them.
What's the best considering the following criterias:
Easy to understand.
Is being maintained lately.
Is free or has a good enough free version.
Works.
I can't speak for what's best or worst, but I'll throw in my experience with NCache in case it helps.
Disclaimer: NHibernate and I had some disagreements, we have since gone our separate ways :)
The Good
The performance was great
The support was great, it's well maintained (I'm speaking to status as of ~6 months ago)
It has a free version (caveats below)
It worked as well as possible, but I had issues with the base level 2 cache provider implementation...but this was a problem on the NHibernate side with HQL, not the NCache side.
The Bad (For reference look here)
The free version had it's limitations, they are strategically put there no doubt, but for our project ultimately we couldn't use the free version because of some key features not available. The below restrictions are on the FREE version.
Key Based Dependency is not included
None of the database dependencies are included
No 64-bit version
Those were the sticking points on 2 different projects for me...however aside from those, no problems and I was happy with the simplicity of install and configuration. If the above aren't sticking points/requirements for you, I do recommend giving it a shot. It took me less than 10 minutes to get a server up and functioning as our L2 cache.
This question already has answers here:
Is Mono ready for prime time? [closed]
(17 answers)
Closed 8 years ago.
C# looks great because it is a compiled language which seems to run quite well without too much CPU and does not consume too much memory. And StackOverflow and ServerFault are good examples of an MVC/.Net/C# stack that scales.
C# is also interesting because despite being compiled, it still has a lot of advanced features as a language only found on slower interpreted language.
My server being Linux only (Ubuntu 8.04 LTS), I am wondering if installing Mono in place of the .Net framework is a good idea for production use.
I currently do not have any existing applications using .Net but I am interested in using existing frameworks (like MS MVC).
Stable enough and fast enough to do what?
It will have different levels of stability and performance depending on what you want to do, I'm sure. For example, one of my Protocol Buffers unit tests (which uses Rhino.Mocks) manages to make the Mono VM abort with an assertion error - but I have no idea (currently) of whether that would affect anything else I'm doing, or whether it's just related to the form of proxying being used.
I suggest you try it and see.
ASP.Net MVC is now open source. That it is now integrated into MonoDevelop via an add in would suggest that you are likely to get things working.
Given the very new status of this you should expect issues. This blog should be a reasonable starting point for you.
Remember that many ASP.Net MVC tutorials assume you have a sql server back end, this is unlikely to be feasible (given your question) so bear that in mind.
You'll have to judge it on a feature basis. At my current customer we're running a high-volume document processing and delivery system written in .NET 3.5. We have a Linux server that runs Mono with .NET components that take care of the delivery of documents to the outside world, e.g. through FTP. That runs fine in production.
We did run into a problem with the Mono implementation of the .NET FTP component, which forced us to look for other third party .NET components, which solved the problem. So you might run into things like these. But in our case: once we got it to work, it worked just fine and stable.
I think that Mono is REALLY stable and complete.
It brings .NET to *nix World.
In my company I'm leading a project aimed to build an automated machine. This machine is built by different devices that need to be governed using a serial interface (RS232).
The machine exposes a touch screen for user interaction.
One of my responsibilities is to project the logic of the system beyond the GUI application.
I've chose Mono (used for presentation layer) also to build a custom middleware that runs the application business logic.
This middleware is some sort of application server and it's executed in Ubuntu 10.04 LTS.
For now all the system is an advanced prototype, but also the final product will keep its heart in the couple Linux/Mono.
I hope that these considerations could be useful for you.
Regards,
Giacomo
as i had read on mono project wait for MONO 3.0 it will solve the main problem in mono means memory leakages and garbage collectors so before 3.0 we can't say it as stable but it is a life line for developers like us who want to develop platform independent s/w with dot net.
Has anyone used Mono, the open source .NET implementation on a large or medium sized project? I'm wondering if it's ready for real world, production environments. Is it stable, fast, compatible, ... enough to use? Does it take a lot of effort to port projects to the Mono runtime, or is it really, really compatible enough to just take of and run already written code for Microsoft's runtime?
I've used it for a number of internal and commercial projects with great success. My warnings:
Write lots of unit tests and make sure they ALL pass under Mono -- this will save you a lot of trouble.
Unless you absolutely have to, do NOT use their embedding API. It's damn easy to use, but it's ungodly easy to garbage collect valid memory or leak all of your memory.
Don't ever, ever, ever even come close to SVN and unless there's no choice, do not compile your own. Things change so often in SVN that it's highly likely you'll end up implementing something that doesn't work on a release version if your project is significantly large.
Don't try and figure out problems on your own for long, use the IRC channel. The people there are helpful and you'll save yourself days upon days -- don't make the same mistake I did.
Good luck!
Edit: The reason I say not to compile your own from source (release or SVN) is that it's easy to configure it differently than release binaries and hide bugs, for instance in the garbage collection.
Edit 2: Forgot to answer the second part to your question. In my case, I had no issues with porting code, but I wasn't using any MS-specific libraries (WinForms, ASP.NET, etc). If you're only using System.* stuff, you'll be fine; beyond that, you may run into issues. Mono 2.0 is quite solid, though.
I find Mono to be mostly binary compatible with MS. Hence I simply compile with MS, and run anywhere, like Java is meant to be!
The performance of Mono on Linux is getting very close to MS, as little as 2 times slower in some cases, vs 5-10 times slower when running Mono on Windows (but you should really stick to MS then).
I had some experience with Mono.
Pure .NET stuff (like business logic, controllers or algorithms) can be ported without any problems. Yet, weird things start showing up in the components that interact with operating system, UI, services or persistence. So be prepared for some debugging and hacking.
Things that might help:
Component-Driven Development - so that code is reused by Windows .NET and Mono, while differences are isolated and tested)
Continuous Integration running and checking everything against Mono and MS.NET, so that possible issues could be discovered as fast as possible (automated deployment and sanity checks are also recommended)
There are not a lot of UI component suites for shell development in Mono.
When a component vendor says that his code is "compatible with Mono", it is not same as "runs on Mono and is supported".
Although in the present, there are some companies going into production with Mono, I'd still wait before rushing in there due to:
Lack of decent and commercially supported UI component suites
Issues with efficient garbage collection
Not the best debugging experience (compare with the historical debugger in VS 2010)
PS: if there is a company offering fully managed cloud computing solution (not just a VM, but more like Hadoop equivalent for .NET), then I'll be forced to jump in despite these issues.
If you are doing ASP.NET 2.0 work, it works very well. Winforms may work, but it can cause display issues. If you want compatibility in a forms app, I would suggest GTK#, as it is crossplatform.
Like suggested, as long as you thouroughly test, I would agree to using it commercially if that is a viable option for you, unless it is winforms you need. In my opinion, i would stay away from it for now. And forget WPF as there is no support at this time, and there may never be (although they are working on moonlight, aka silverlight for linux)
I haven't used Mono myself but you may be interested to know that FogBugz uses Mono to provide Lucene.NET on Linux platforms. (I only know this because Joel mentioned it in passing in Stack Overflow Podcast #24.)
I've got a bunch of shell apps in production.
I agree with #cody-brocious, write a lot of unit tests. I found in the past that Regular Expressions didn't work exactly the same way as the windows CLR.
It's actually simplier than you think to get into, just compile and run. If you use NAnt on your projects its even easier to transition.
I typically install mono from the source releases and I haven't had any problems.
I've used it for encryption/decryption tools and it worked fine.
In the future, I would consider using Mono/C#, but I would not expect it to be 100% exactly like .Net on Windows.
Of course, you can, especially after Mono 2.0 has been released.
Mono 2.0, is ready for real projects.
You can check this