views:

371

answers:

+5 Q:

What features would you like added/changed in the .NET Framework?

Over the years I have found myself being limited by what's available in the .NET framework, and having to work-around the stuff that isn't there.
This seems ludicrous to me because there are so many controls available on the internet, and us developers always seem to be solving the same problems over and over.

For example I recently needed to use a tree-list control. But because there isn't one available in the .NET framework, I had to either make it myself or use a 3rd party version.

Imagine there was some way of submitting a control or piece of code to MS so that they could try/test/tweak it and make it good enough to include in the next version of the framework.

If this could happen,

What would be your first request for the next version of the .NET framework?

To not have to cast enum's of integers back to int in order to use it!

Chalkey 2009-10-12 22:07:51

But then you lose your strongly typed enums.

Ed Swangren 2009-10-12 22:09:32

It would be nice to be able to treat enums more like ints sometimes. I agree there should be a cast to go from int to enum, but how is assigning an enum value to an int not a widening conversion? I get frustrated with this sometimes. The casts really clutter the code.

Snarfblam 2009-10-12 22:50:56

Consider Console.WriteLine(MyEnumType.SomeValue). As it stands, that resolves to Console.WriteLine(System.Object), which displays "SomeValue". With an implicit cast to int, it'll either cause an ambiguity error on compilation, or display the numeric value, I'm not sure which. Principle of Least Surprise, anyone?

FacticiusVir 2009-10-12 23:15:52

FacticiusVir, how does that cause implicit cast to int when WriteLine expects a string, which in term causes implicit call to MyEnumType.SomeValue.ToString().

Xerion 2009-10-13 15:13:42

Console.WriteLine has 19 different overloads; it expects many more things than just System.String :-D. Console.WriteLinewill accept string, most of the base value types (int, bool, byte, double, etc.) or System.Object, which is the catch-all case that enums fall into. Enums don't have an implicit cast to System.String; if they did, you could compile the following code:

FacticiusVir 2009-10-14 10:12:32

namespace Enum_Sandbox{ using System; class Program { static void Main(string[] args) { Display(MyEnumType.SomeValue); } static void Display(string value) { Console.WriteLine(value); } } enum MyEnumType { SomeValue }}It's the Console.WriteLine(System.Object) overload that calls ToString internally. If you supply an implicit cast to int (you can simulate this by creating a struct with an override ToString and an implicit cast operator to int)

FacticiusVir 2009-10-14 10:19:26

then the compiler resolves the call to Console.WriteLine(System.Int32) instead, giving you the numeric value of the enum, rather than the string representation.

FacticiusVir 2009-10-14 10:20:22

You are right, this would break compatability, but it should have never been a required explicit cast in the first place. Enums are named constants, and pass the is-a test (as a matter of opinion): an instance of MyEnum is an int (in fact, you can specify this in the enum declaration... enum MyEnum : int {}).

Snarfblam 2009-10-14 21:36:31

+12 A:

Dale Halliwell 2009-10-12 22:13:39

+1 for the WPF NotifyIcon ! Linq to Events is probably a good idea too, although not as immediately useful to me...

Thomas Levesque 2009-10-12 23:14:46

I need to see lots more examples for System.Reactive before I can get in that mindset :o

280Z28 2009-10-13 01:24:55

+2 A:

More attractive default styles for WPF controls. I think Adobe Flex controls, for example, look much better out of the box.

DanM 2009-10-12 22:35:50

MSFT just can't seem to focus on "better out of the box" xp. They build great frameworks and tools, but always comes short of a great end-to-end solution by missing the last mile.

Xerion 2009-10-13 15:17:37

+3 A:

A build in decent HTML editor. Like the Rich-text-box, but for html.

GvS 2009-10-12 22:42:36

+3 A:

const-correctness enforced by the CLR--it can't be cast away as in C++.

Dan 2009-10-12 22:44:00

Assignment Type inference.
Methods on Enums
Enums that can implement interfaces ( like java's enums )
Wildcards in Generics ( ? extends Myclass )

( Yeah I am a java programmer :) )

Surya 2009-10-12 22:46:33

+1 for #2. I like # 3 too, though.

Snarfblam 2009-10-12 22:54:14

One major advantage of enums in the CLI is they are extremely lightweight. The bytecode operates on them as the underlying type. Enums in Java may be more flexible, but they are also often avoided (unfortunately) in favor of `static final int` for performance reasons. One could argue that an enumeration is a selection of options (no more or less), so an "enum with methods or interfaces" is actually a class/struct in the first place (not an enum at all). Static classes like `Colors` and `SystemColors` show particular examples of this pattern.

280Z28 2009-10-12 22:56:09

@280Z28 This is the first time I am hearing about performance issues with enums , i thought they were essentially like singletons . Can you post references supporting your claim

Surya 2009-10-12 23:01:23

Adding methods to an enum will have NO impact on performance of existing functionality. Being able to add methods doesn't require them to be garbage collected, read/written by accessors, created by constructors, or anything like that. It just allows methods to be added to the IL and called from code in a manner similar to extension methods on an enum. In fact, I believe you CAN give an enum methods if you write the IL yourself and assemble it.

Snarfblam 2009-10-14 21:32:20

P.S. Implementing an interface with an enum has no perf hit on existing functionality. Just like implementing an interface with a struct, you don't run into gc/boxing/v-tables/virtual calls unless you actually USE the interface.

Snarfblam 2009-10-14 21:46:26

+5 A:

Extension Properties. I know they were planned for .NET 4.0 but had to be cut. (See Eric Lippert's Blog for details)
Static Interfaces. For example, several classes implement a Parse method, but there's no means of writing a generic method to convert a list of strings into a list of T.
Also, a special generic type keyword for Enums.
An interesting possibility would be retrospective interfaces. Let's say I define an interface with methods that exist on a class in a pre-existing library; for example, I want to wrap the System.Collections.Generic.Queue in an IQueue interface. Currently, I'd have to create a special wrapper class.

FacticiusVir 2009-10-12 22:46:42

Aren't these more like wishlist for language features?

çağdaş 2009-10-17 00:33:48

+3 A:

I want:

Improved start-up time of WPF applications. They've already taken a crack at this in 3.5 SP1, but there's still substantial room for improvement.
Better hardware-acceleration support for Silverlight. It's been improved in Silverlight 3 for video-scaling and such, but it still isn't as far along as it is in WPF.
More binding help for XAML in Visual Studio & Blend. Namely, I'd like to have intellisense work as I type, suggesting things to bind to. Because honestly, 9 times out of 10 I'm lost with the binding syntax of XAML.

Steve Wortham 2009-10-12 22:48:41

I wish they would just include Blend with a purchase of Visual Studio. It is so vastly superior for WPF/Silverlight design that Visual Studio that they should either embed its UI as the Visual Studio designer or get rid of the VS designer in favor of it (Blend's).

280Z28 2009-10-12 22:58:11

Yeah, that'd be nice. Fortunately I'm using my BizSpark account to get all the developer tools for free while it lasts. But 3 years from now I'll have to pony up the cash for the latest Visual Studio AND Expression Studio since I've come to depend on them both.

Steve Wortham 2009-10-12 23:03:23

+2 A:

Microsoft's Community Promise was/is great news for the open source community, but I think a few people don't realize that it lacks in one particular area. Most people assume that the public API exposed by certain .NET Framework assemblies are what's covered by this promise. Notably, mscorlib, System, System.Core, System.Xml, and maybe some others. However, the promise only applies to the API listed in ECMA-335, which is unfortunately tremendously out of date and represents only a small fraction of the API exposed by these assemblies. Even fundamental things like the TryParse method exposed by most of the primitive types are missing from the published standard. I wish Microsoft would amend their statement to include "Implementations of the public API exposed by the assemblies X, Y, Z, ...," where this clearly applies only to the public API and not to the underlying source code (Microsoft's implementation). Coding strictly to the ECMA-335 standard would be a tremendous limitation even for basic console applications.

280Z28 2009-10-12 22:49:32

+8 A:

Give me a Linker!

I want to be able to hand out a stand-alone app that does not rely on a particular set of libraries to be installed on the person's computer. I don't mind if the app remains a managed app in the process, but I'm tired of a 250 mb bootstrapper being the "solution" for distributing a tiny application that uses one one-hundredth of the APIs provided to me.

@Chris S: dotnetfx35.exe is 231 mb; that's the latest full installer I have. Depending on what you have installed already, it may not need all the data in there (in fact, it includes x86, x64, and ia64 versions of files). You could cut out the ia64 versions to save yourself some space ( the .exe can be decompressed and messed around with - Microsoft has a guide or two on the MSDN about it) but the installer still tries to phone home to Microsoft to make sure it has all the latest versions. (There's supposed to be a way to disable it, but that's not recommended.)

@FacitiusVir: The client profile has significant limitations: missing many libraries (basically, unless you're only doing WPF, it's no good), doesn't actually count as a .NET install (other apps won't sense it as a .NET install) and only works for Only Windows XP SP2 or SP3 and x86 architecture (sorry, a whole lot of people!) As soon as you get in an environment that fails to meet any of those situations, you're SOL. And then, I'm STILL distributing 24 extra megs for my app, that may be redundant when they're forced to get the entire client for X library not included in the Client Profile. To top it off, the client installer still needs to connect to the internet to install. That's unacceptable in many environments. I don't want ANY app I write "phoning home" during install - there are too many issues with trying to make internet connections through various types of firewalls to be a reasonable solution for a stable, simple to install program. I want to make stuff that just works, not stuff that happens to work if you're in a certain configuration (and if not, you have to create some file in a special place with a special name you looked up and yatta yatta.)

Now, with the .NET 4.0 Client installer, things are looking up: it now installs for every platform (that matters), you are allowed to have a local package installer, and it's actually part of the .NET framework now and can be serviced separately. That solves many of my particular beefs with it. As long as you're making pure .NET forms apps, you'll continue to be fine. However, as before, step outside that box a little and you're back in 231 meg land.

Robert P 2009-10-12 23:21:31

Have you considered the .NET Framework Client Profile; as it only includes a subset of the API, it's between only 10MB to 56MB download, depending on what framework versions to already have installed. Not quite a compact as a single redistributable, but it's a lot less than 250MB.

FacticiusVir 2009-10-12 23:33:53

250mb or 22.4mb?

Chris S 2009-10-13 15:09:47

I want a tree-list view, i.e. a list-view which can have one of the columns be a tree-view. Or a tree-view with columns effectively. I've seen countless versions of this on the net and in many apps, and they all look slightly different.
I want a full ribbon control which adheres to the current MS ribbon look and feel. For instance the l+f of the Win7 ribbon is completely different to the one I've been implementing from the MFC Feature Pack in VS2008 for the past year :/

It would satisfy my OCD if there was more consistency in this world :)

demoncodemonkey 2009-10-13 15:03:10

Windows 7 scenic ribbon is the new, standard ribbon going forward. It's now built into the OS, and even Office 2010 will use it.

Robert P 2009-10-13 19:54:40

Well that's the new, *current* standard ribbon, which will probably look entirely different in 2 years time

demoncodemonkey 2009-10-13 20:22:53

Easier shared configuration solutions.

Jason 2009-10-13 15:13:13

I want a ReadOnlyDictionary.

demoncodemonkey 2009-11-04 14:40:53

ansaurus

tags:

views:

answers:

What features would you like added/changed in the .NET Framework?

Give me a Linker!

related questions