The July edition of MSDN Magazine is out with some interesting .NET topics.
Unhandled Exceptions and Tracing in the .NET Framework 2.0
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Is this isn’t advertising then what is it?
Still some topics look interesting so I better check them out
I posted the comment that was moderated down because I realized the headline wasn’t related with the contents of the post (Sorry Eugenia but that’s what i felt) and just if someone is interested the link I think it’s more related to the headline is here
http://msdn.microsoft.com/msdnmag/issues/05/07/Bugslayer/default.as…
BTW I never meant to offend the staff…
I am still dealing with the fact that .NET 2.0 is seriously incompatible with .NET 1.1.
And that the “no DLL hell” that Microsoft preaches regarding .NET is bullshit. Microsoft .NET gets corrupted and confused more easily and faster than just about any other Microsoft technology. I am stuck with customers who have to pave their machines because .NET is such low quality crap (error 2908).
The lack of effort Microsoft is putting into .NET is pathetic.
So back to topic. It is obvious Microsoft is shipping a fucked version of .NET for their competitors:
“The great news about the .NET Framework 2.0 is that unhandled exceptions, no matter where they come from, now cause termination of the app.”
With the sort of “anything other than ‘ok’ = exception” class libraries that are around, this strategy is just plain dumb. This is the best Microsoft could think of?
It is getting plain to see that .NET will never be a “world class” framework. It is time to tell our customers we are moving to Java. However flawed as Java is, it is better than the half-baked crap that Microsoft calls .NET.
There is no intelligence behind .NET. After Anders and company were done copying Java and fixing it up a bit, it is clear they ran out of gas.
Maybe six to twelve months from the time .NET 2.0 ships, there will be .NET 2.1 which will be the working version of .NET 2.0. Even if we convince ourselves to *rewrite* our code for .NET 2.0, we will have to wait basically a year more for a stable and tested .NET codebase. What a joke.
Ok, I have to take Microsoft side on this one…
The point is that programs need to be maintained. And there is money to be made in doing so. So what’s the big deal? Just write a new version of your Net application and compile against the latest and greatest. If I read the article right, there is no need to rewrite the whole code for the program (As long as it was carefully written, just make the proper functions that would do the exception handling and rewrite the calls).
Now I mostly write apps on C++ because it’s the thing I’ve learned so far on campus but the algorithms can be language independent. Don’t they?
“what’s the big deal? Just write a new version of your Net application and compile against the latest and greatest.”
You gotta be kiding me!! – Have you got any clue what a new QA process might cost? Probably also new distribution, and perhaps packaging.
pravda, you mention a number of issues with .net, we’ve started using .net but haven’t encountered any problems yet, I’d be interested to learn more before we find them ourselves.
Yeah Pravda, how about some examples? I’ve worked on close to 20 projects running the gammut from small to enterprise level and have run into no more problems than on other platforms.
“what’s the big deal? Just write a new version of your Net application and compile against the latest and greatest.”
hehe, that doesn’t say anything about the AMOUNT of issues, just that it is fairly similar to other API/Platforms
pravda, you mention a number of issues with .net, we’ve started using .net but haven’t encountered any problems yet, I’d be interested to learn more before we find them ourselves.
Until he provides details about his claims, here are mines.
I’ve been using .NET since 1.0 but of course standard version is 1.1. I never (and repeat: never) got a .NET installation messed up.
As for application compatibility, .NET 2.0 should be .NET 1.1 compatible meaning you can simply move any 1.1-compiled application to 2.0 environment and it works. There are a few chances this won’t work (btw, it’s Microsoft: they care about backward compatibility…). We moved many application from 1.1 to 2.0 without any problem and by doing so your performance will improve. Of course, if you can re-compile your application to 2.0, that will be better.
The only time a slight difference between 1.1 and 2.0 could prevent application to properly work, compiler told me and I was able to change that on the fly before compilation. It took only 5 mins to me.
However, keep in mind that, as someone stated here, if your application won’t run on 2.0 (whatever reason) you can simply configure it to run to its original environment in a few steps. So should that happen, simply configure your application to run with 1.1 until you find what’s wrong in 2.0.
If you’re running a web application on an external provider, simply tell them to configure your application to run with 1.1. They will SURELY (and MUST BE) able to do that. Any 2.0 installation also supports 1.1.
Hope this helps.
In regards to compatibility, I think you’re misunderstanding something. Yes, they are incompatible, and that’s the point. There’s a philosophy that’s part of .NET called “side-by-side deployment,” and it’s a philosophy that goes all the way down to the root. The idea is that you can have different versions of the .NET runtime deployed side-by-side. Why is this important? Because applications compiled against 1.1 will continue to use 1.1. They won’t even know 2.0 exists. In this way, changes to 2.0 won’t break 1.1 apps. Similarly, 2.0 apps have no knowledge of 1.1. They are totally separate.
This is also important because it allows Microsoft to introduce new features that may not be backwards-compatible. This isn’t a problem because 1.1 apps will continue to work just fine. They won’t even know the new features are there. If you want to take advantage of the new features, write a new app. I know that sucks, but it’s the best solution there is for DLL hell.
The problem with that strategy is that it works well for libraries that STAY being 1.1, however it’s fundementally flawed once you need to update a small method to use a 1.1+ feature.
Using that strategy, a simple update of a method, might require a gargantuan effort to rewrite the whole lib (or the offending parts). Then comes the whole process of QAing the library and doing backwards compatibility tests. All in all, not something people want to do.
Does anyone actually use the Trace feature of .NET 1.x when there are other open source logger packages like log4net or NLog?
http://logging.apache.org/log4net/
http://nlog.sourceforge.net/
Tthe alternatives are much more powerful and much cleaner to use. I think that the whole idea of trace switches and trace listeners just adds complexity and bloat to the code and configuration. Trace switches don’t scale well when you have a complex application made of components.
Unfortunately I think that .NET 2.0 tracing additions will just make things different instead of making them any better.
I do, when in school. But not for my own apps
Does anyone actually use the Trace feature of .NET 1.x when there are other open source logger packages like log4net or NLog?
I’m currently using Log4Net for all projects I’m involved into. It works very well and it’s very powerful.
Is that there are no perfect programming languages(That’s why there are so many) and .Net (C# and libraries) is no exception tho this…
Maybe some developers will feel more confortable by sticking to .Net 1.1 while others move on to 2.0 that should not be a problem, heck, there is still people building apps on Visual Studio 6 anyway
Thanks for the comments TBPrince, I suspect there isn’t any really wrong with .NET as pravda suggests, we’ve certainly not encountered anything, quite the contrary in fact. I actually quite pleased with the increase in productivity with using .net compared to other frameworks.