What is the worst thing in .NET?

.NET Framework is the best, but a few things could be better, right?

What about ".Equals(object) : boolean"? It is seriously the worst thing in the .NET Framework. It was only invented because we did not have operator overloading in .NET 1.0! Removing "Equals" from the framework would be an OK breaking change!

In Visual Basic one of the things I don't like is that you can call a function without using () after the method name: Return Me.ToString -> Should be: Return Me.ToString() !!!

/Klaus Enevoldsen

Klaus Enevoldsen wrote:

.NET Framework is the best, but a few things could be better, right?

What about ".Equals(object) : boolean"? It is seriously the worst thing in the .NET Framework. It was only invented because we did not have operator overloading in .NET 1.0! Removing "Equals" from the framework would be an OK breaking change!

In Visual Basic one of the things I don't like is that you can call a function without using () after the method name: Return Me.ToString -> Should be: Return Me.ToString() !!!

/Klaus Enevoldsen

I'm sure I've had to use .Equals for COM interop. (Exposing a .NET assembly through COM)

But I can't remember why on earth I had to do that.

The Visual Basic thing is a language difference nothing to do with the Framework really.

I can't really fault .Net I love it I just wish it was platform independent. Also theres a few silly unimportant things that could be changed like having String and string in C#

One other thing is how easy it is to write things badly, it could be seen as a good thing that an application can be throw together with no real thought but I don't think so, and this is easier to do that other frameworks I think not really sure.  I think the Framework should force some good patterns & practices more if it could. 

My beef with it is that you can't compile your app and keep your code secure. Anybody can decompile your code with tools provided by MS. Obsfucation, as it currently works, isn't the best solution to this problem because it is a serious pain to work with. It needs to be directly and tightly integrated into the Framework along with application encryption and licensing algorithms for even more security if desired.

The fact that it's called .NET.

string.Equals has overloads for case insensitive comparisons too..

As Littleguru's example indicates, the big difference between Equals and operator== is that Equals is a virtual method. You can use it without knowing the actual type of the object. Operator== only works if the variable is the correct type. Many algorithms, such as Array.Sort, take advantage of this fact.

Furthermore, operator overloading is not a CLS feature, and not all CLR languages support it.

bgmacaw wrote:

My beef with it is that you can't compile your app and keep your code secure. Anybody can decompile your code with tools provided by MS. Obsfucation, as it currently works, isn't the best solution to this problem because it is a serious pain to work with. It needs to be directly and tightly integrated into the Framework along with application encryption and licensing algorithms for even more security if desired.

Yes. I am with you on that one. I don't like the fact that any old Joe can drop my application in Reflector and view the source-code.

[C]

System.IO stream classes could be a lot more user friendly. Often times I think they should rewrite them.

System.IO.Easy

IO for the mere mortal. I would complain about System.XML as it is as easy a target. But XLINQ fixes the issue for me.

In fact Brad Abrams comments on this in the Framework Design Guidelines. They did usability testing after it was released. 
 

I always try and use object methods over logical operators, ever since I found out that there is a difference between "" and string.Empty.

But, I am not sure if that is a "better practice" or not. Or is it just like your preference for String over string?

JohnnyAwesome wrote:

I always try and use object methods over logical operators, ever since I found out that there is a difference between "" and string.Empty.

But, I am not sure if that is a "better practice" or not. Or is it just like your preference for String over string?

We always use String.Empty because we run a program over the code at the end to extract ALL strings for translation. This is the same reason why we prefer String.Format - "http://" + host + "/" + folder + "/" + name would extract 3 strings which would all be difficult to describe without delving into the potentially months-old code, but String.Format("http://{0}/{1}/{2}",host,folder,name) extracts one string that is easier to see what it does, easier to read and easier to internationalize in the case of currency and time strings.

String.Empty is not extracted because it is not a string literal, wheras "" is extracted, and this means that our translation team would have to translate a hundred blank strings which wastes their time, our time and serves no real purpose. String.Empty implies that the string is intentionally left empty also.

My gripes, at least those that come to mind at the moment:

• Unsigned integers aren't full citizens--they aren't CLS-compliant.
• The bifurcation between value types and reference types still drives me nuts.

evildictaitor wrote:

String.Empty is not extracted because it is not a string literal, wheras "" is extracted, and this means that our translation team would have to translate a hundred blank strings which wastes their time, our time and serves no real purpose. String.Empty implies that the string is intentionally left empty also.

To what would they translate the literal ""? Could your tool simply not extract empty strings?

I wonder, is it faster to test for string.length > 0 or to test for string.empty?