Currently, the behavior of the built-in SmtpClient is to set the SMTP envelope's MAIL FROM as follows:

- Use the MailMessage.Sender property if it is not null; otherwise
- Use the MailMessage.From property

When a .NET application wants to send an auto-response e-mail (such as a "Support Ticket Created" or a "Message Accepted") e-mail, it would be nice to be able to send a null envelope from ("MAIL FROM: <>"). This translates to a "Return-Path: <>" stamp and is the SMTP-sanctioned way to say "I don't want to start an auto-responder war; don't send any bounces back to me."

But leaving MailMessage.Sender as null causes SmtpClient to look at MailMessage.From (so that doesn't work), and the MailAddress class bombs if you try to do new MailAddress("<>").

So it would be nice if there was some kind of hook to say "please use a null MAIL FROM on the SMTP envelope" (the e-mail would still have the appropriate From header).

1) Microsoft release a new version and new technologies too soon. It makes developer's life a ****. I find myself learning new technologies most of the time rather than using them.
2) Microsoft should bring in existing opensource projects into visual studio and .net rather than creating it's own. Like Nhibernate instead of Entity Framework. I had spend a lot of time learning and mastering NHibernate and now I have to also start learning Entity Framework. Instead microsoft should have created better tools to integrated Nhibernate with visualstudio etc. or microsoft could support such projects.
3) Since I love C# and hate JavaScript, I wish if microsoft could come up with something like JSIL or Sharpkit that way we'll be able to use C# with HTML5 and CSS3 to create apps.
4) Try to make .Net framework completely cross platform or start supporting opensource projects such as mono etc.

Additions to the MemoryMapped namespace in .Net4.0 Framework
The memory mapping is set up like a file so could you add:-

Missing Method:
if.exist which will check that file name X exist unlike now via an exception

Missing Events:

OnChange (Memory X has changed)
OnClosed (MemoryFile has closed)
OnOpened (MemoryFile has opend)
Etc...

e.g. CreateView(Address etc).OnChange(Addressof,MyHandler)

Why?
Application A shares memoryFileX
Application B also shares memoryFileX
B's event is rased as A changes data . E.g A reads database and sends B new IP addess via shared memory

The only way now is to have a blocking thread which is yet another CPU overhead.

Kind Regards

David Rathbone
Snr Developer RAL

Collections and dictionaries are a disorganized jumble in .NET

System.Collections.* contain multiple overlapping interfaces and types with confusing names and complex inheritance (making them difficult to derive from).

I know that one can use an external library like C5 instead but I always thought this irritating since this is such a basic and common issue.

- The collections in .NET are incomplete: no multikey maps, for example

- We need better documentation of which collection to use when and what for

I would suggest adding quick reference tables to the MSDN documentation with columns like access by index / first / last / key, sorting, cloning, readonly access, locking / concurrency features, storage mechanism, underlying collection(s), performance, interface inheritance, data binding features...

- Collections are dispersed in multiple namespaces somewhat randomly

System.Collections
System.Collections.Concurrent
System.Collections.Generic
System.Collections.ObjectModel
System.Collections.Specialized

For example, SynchronizedKeyedCollection is in .Generic but KeyedCollection is in .ObjectModel. Why?

- Some useful types and interfaces like ILookup and IGrouping are only accessible via LINQ.

- Obsolete or add compiler warnings to prevent use of older, non-generic interfaces and types when possible. Consider moving (and dangerous) features like SyncRoot and IsSynchronized in ICollection to a separate interface.

Hi Guys,

A fair number of us out there in virtual space would be very happy if you would implement support for Array / Lists with the use of a long data type as the index. This is kind of a problem that is brought up continuously on StackOverflow.com, and we are seriously lacking a GOOD solution here. Yes, we've heard that you've increased the supported size in the .Net 4.5 Framework, but it's not good enough. We really want to be able to use the 64-bit space for addressing more than a few billion objects, and this lack of support (which took me by surprise) is curtailing or limiting .Net adoption for some of the larger projects out there.

I myself looked into borrowing code from Mono to see if I could work around the limit, but to no avail. The efficiency hit of implementing a List of Lists, and putting a wrapper around them is just begging for a touch of sanity, as I will always be worried about bumping into that limit. More and more memory will be spent just managing the lists, which defeats the purpose of using a larger one.

I have not yet explored using a C++ .dll to handle this problem, but again, it detracts from .Net.

I've previously posted this on Connect - https://connect.microsoft.com/VisualStudio/feedback/details/331753/regex-should-have-a-static-tryparse-method

The System.Text.RegularExpression class does not have a true ability to test for valid regular expression syntax from a string input. The only way that this can currently be accomplished is to surround the Regex ctor (that takes a string) with a try/catch and look for an ArgumentException if the string is not a valid regular expression.

This is not desirable for 3 reasons:
1. It doesn't follow the "TryParse" pattern used by other types for "conversion" from strings such as Int32.TryParse( string ), etc.
2. Performance of possible exception throwing
3. Exceptions should not be used for control flow