Microsoft Connect Gems

My favorites from connect.microsoft.com. They really have managed to connect with my sense of humour. I wonder how they can spare any time on developing new products and new releases when there are so many unresolved issues in their existing products! But still, it was fun to read their replies to some bug reports.

XYZ,

Thanks for your feedback.
But you haven't answered my question. What would you recommend to cope with cases like attached example illustrates? Is there a general pattern for serializing generic collections?
Posted by Unregistered User on 23/11/2005 at 03:12

It seems that the attachment was somehow lost from this bug. Could you please reattach and reactivate?
Posted by Microsoft on 06/12/2006 at 13:05

---

Thank you for submitting this issue. Unfortunately, we have decided that it will not be addressed because the risk of the fix and its potential breaking nature outweighs its benefit. By the time the next opportunity to make this change comes about, the hope is that the new serialization technologies in a future version of the Windows Communication Foundation will address your scenario. If this issue is causing significant negative business impact, please contact Microsoft Product Support Services. I regret that we could not provide a better resolution. Rest assured that we seriously considered this issue - a Won't Fix decision is never easy to make.
-- XYZ

---

Thank you very, very much for bringing this to our attention, for following up, and for not giving up after two bug resolutions. I think this is a great example of the value of the MSDN Feedback program. You have indeed uncovered a serious problem with Version Tolerant Serialization and Generics. Unfortunately, Whidbey is pretty much completely closed down right now, and it is impossible to check in a fix even for a bug of this magnitude, which is why I am forced to resolve this as Postponed. However, be assured that we are treating this issue very seriously and are now in the process of discussing alternative delivery vehicles for this fix (e.g. the possibility of making a patch available through Product Support Services.) In the meantime, please use assembly binding redirection (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconassemblybindingredirection.asp) as a workaround.
Thank you again for the time you invested in reporting this problem,
-- XYZ

Binding a Value Type Array to a DataGridView

Short answer: Dont.

The long answer: try it for yourself.

Cannot copy assembly...

Here's a pretty serious issue with VS2003. I have a VS2003 solution consisting of multiple projects and every now and then, it gives me a build error saying "Cannot copy assembly...The process cannot access the file because..."

..because Microsoft goofed up yet again.

And what do we get when we contact the
support site? Well they got a hotfix but they want us to contact support in order to get it. Don't these fellas know what a 'DOWNLOAD" is?

More frustration...

This man may be able to help us out.

Stupid ASP.NET

Did you know that a Response.Write in the Page_Load gets rendered right at the top of your HTML markup? Right at the top! Meaning right before <HTML>. Isn't that cool!

Not only that, a Page.Controls.Add will place your control right at the bottom of your controls collection which means that it goes right after the closing </HTML>. Awesome!!

Want some more?!

OK. Now, to add a control so that it falls within the <FORM>...</FORM> (which is what everybody wants), we need to say Controls[1].Controls.Add(mycontrol).

Controls[1] will get you the reference to the <FORM> control and so on...

Right now Controls[1] works for me but, who knows...

Cookies in ASP.NET

Cookie collections in ASP.NET are just weird to say the least. I'm too tired to go into details. Just remember this:

1. When you read Response.Cookies[somename], the cookie is automatically created and returned if it does not already exist. Code which checks if(Response.Cookies[somename] == null) is pointless.
   (This does not apply to Request.Cookies)
   
2. When a cookie is added to Response.Cookies, it is automatically added to Request.Cookies too. Ditto for deletes.
3. Want more? If you add a cookie to Response.Cookies and it already exists in Request.Cookies, then Request.Cookies will have two cookies with the same name. So it is better to do a Request.Cookies.Remove(somename) before Response.Cookies[somename].
   For cookies using multiple values it makes sense to reuse the cookie which was removed from Request.Cookies.
   
4. If you'd like even more bugs with your ASP.NET: Response.Cookies Bug

Yup. That was the short version.