Summary: ProductFeedback about the .NET framework
SeeAlso: ProductFeedback, Microsoft_.NET@Wikipedia

The MSDN team have created a web-based feedback site - you can submit bug reports straight into their database! We'll gradually start deprecating this wiki, and pointing people over there instead -- JonathanHardwick

Bugs

DialogBoxesDuringDragAndDropEvent - when calling ""DialogBox"" during ""DragDrop"" event, all machine background and other open windows are not redraw - posted by ""ProTON""

TooltipsAndNumericUpDown - when tooltips are set on a control that hosts other controls within it (like ""NumericUpDown"") tooltips are not shown on those child controls.

DisplayMemberAndStringLength - the listbox calculates the size (e.g. for scrollbars) by the length of ToString()..

CheckEvents - the ""Tree-View"" has ""BeforeCheck"" and ""AfterCheck"" - ""CheckedListBox"" and ""ListView"" only ""ItemCheck""

TreeViewAndRightClick - if you right-click on an item (which wasn't selected befeore) inside a treeview and try to get that element inside the ""MouseDown-Event"" to have to manually set the item as selected..

ControlsAndXPStyle - not all controls support xp-style (e.g. ""NumericUpDown"" and buttons with images)..
Update: I believe this is fixed in .NET 2.0, try the beta - ShadowChaser

System.Windows.Forms.Binding Class - almost all of the "simple" data binding bugs can be traced back to the Binding class. The binding class always transforms null's into "DBNull.Value", which will crash any custom Business Entities.
The Binding class also has no mechanisms to force the push/pull of data (Added in 2.0?), the Binding.IsBinding property doesn't work (always returns true and the documentation does not make any sense - why does ResumeBinding set IsBinding to false, what??). Calling CurrencyManager.Refresh while a control's value is currently binding will crash with some sort of 'row' error. No way to determine if a Binding is currently binding (ie/ in the progress of pushing/pulling data). -ShadowChaser

System.Windows.Forms.ComboBox class is extremely slow when using complex data binding (ie/ setting the DataSource property causes excessive slowdowns). The ComboBox class will also synchronize all comboboxes that use the same list datasource... what??? I can understand synchronizing for the same Text/SelectedIndex/SelectedValue/etc properties, but the list just doens't make sense. What happens when I have a data entry form with two databound "country" drop downs? :( -ShadowChaser
-- Posted this to ProductFeedback and they improved ComboBox perf it in 2.0

Missing Features

System.IO.Directory.Copy() doesn't exist

I think I recall a recent blogs.msdn.com post that this was a design decision - there are too many choices to make about what the user really wants. Full recursive copy? Across filesystems? Copying access rights? -- JonathanHardwick

TimePicker - there is only a ""DateTimePicker"" :(

New Feature Suggestions

Declarative pre/post/invariant conditions implemented via standard attributes (like XC# , but for all .NET languages).

Interception..
Contracts and other typical aspects could benefit from similar facilities.

Provide some sort of event/delegate/etc that is fired immediately after an object is created - once all of the constructors have executed. As it stands right now, if you need to call a virtual method during construction, you can't do that safely. There are situations where there are no alternatives to calling virtual methods after construction. -ShadowChaser

Modify the label control to provide a mechanism for showing a "..." after the text if wordwrapping is turned off. (instead of just truncating it)
Update: This has been added to .NET 2.0

Add the ability to provide a "hook" (ie/ delegate) into the main Windows message pump - this is absolutely CRITICAL for developing games!

Weird documentation or features

The new System.Collections.Generic namespace (2.0) does not match the System.Collections namespace. For example, in Collection<T> all of the method paramaters are named different. Why? -ShadowChaser
-- This was changed in 2.0 beta 2. Collection<T> was moved to System.Collections.ObjectModel to signify it should be used in APIs, while List<T> is for general everyday use.

Voluntarially refusing permissions for safety reasons in a fully trusted assembly removes it's full trust! This makes it next to impossible to write "extra secure" applications that remove the permissions that will never be used. If I'm writing an application that uses ADO.NET (not a partially trusted assembly) and not the registry, if i refuse my registry permissions I loose full trust and cannot call the other assemblies or plugin components! Extremely frustrating! We desperately need a way to voluntarially refuse permissions while retaining full trust - ShadowChaser