@ Head

Recently a fellow MVP pointed out the addition of the TransferRequest method to the HttpServerUtility class.  The documentation falsely states it as being .NET 3.0 when in fact the change is made in .NET 3.5 Beta.

You'd think stating the file versions would be enough to clear up the matter, which is what I did.  I looked in some Virtual PCs to see what file version there were for System.Web, and determined that the change that includes TransferRequest was the 3.5 version.  Saddly one other MVP wanted to add in some FUD.  And that is really sad because people should know that 3.0 does NOT modify the 2.0 assemblies.  It is important that enterprises know they can safely rollout 3.0 without worrying about changes to the 2.0 framework.

 Here's what I posted:

I just looked in some virtual PC's, and the change is System.Web to
2.0.50727.1318

Prior to that, System.Web was 2.0.50727.210 as of KB922770 . Note:
Installing .NET 3.0 does NOT change that

The change to the 1318 minor version occurs with the install of .NET 3.5
Beta 1 bits.  Whether or not this will be the case with the final release of
3.5 I'm not sure.  I believe the changes are all non breaking so they may
just do that.

And here's some of the comments another MVP made:

There's a bunch of members in 3.0 which aren't available in .Net 2.0

It would be *so* much easier for everybody if you documented your "facts".

Did I miss the documentation you cited ?
Are you aware that *documenting* something goes beyond simply stating an assertion ?

Okay you can get the gist.  I state the versions and state I looked in VPC's etc, and I get back some childish argument about that not equating to their sense of the meaning of "documented".  I s'pose some people just like to argue and spread FUD. Sad.

So anyway, no matter what anyone else tells you, .NET 3.0 does not change the 2.0 assemblies. 

3.5 does but that's another story ;)  I actually hope they will release 3.5 as 4.0 given all the *additions*.  If 3.0 deserved a new version number then 3.5 definitely does.  Plus changing the 2.0 libraries even if it is just to add new members really isn't what one would expect of a minor version upgrade.

I just read again today the claim that you should use + for string concatenation in VB.  You should NOT.  Just because you can doesn't mean you should.  VB has the Concatenation operator & as distinct from the + operator. Yes for the most part adding two strings is the same as concatenating them, but adding two variables is very different from concatenating them... that's why in a dynamic language it is important to have two different operators.

The correct one to use is & for concatenation, and use + for addition.  So for strings use &.

See my previous blog entries on this for more details....

http://msmvps.com/blogs/bill/archive/2006/04/23/92280.aspx

Roger Jennings asks about VB9 and collection initializers.  It's a question I too have asked, and although I'm not certain it does appear there won't be collection initializers for VB9 :(

One thing I did want to point out though is in regards to the array initializers. Roger posted the code :

Dim Capitals = { _
  New City With { _
    .Name = "Antanarivo", _
    .Country = "Madagascar", _
    .Longitude = 47.4, _
    .Lattitude = -18.6 }, _
  New City With { _
    .Name = "Belmopan", _
    .Country = "Belize", _
    .Longitude = -88.5, _
    .Latitude = 17.1 }, _
  New City With { _
    .Name = "Monaco", _
    .Country = "Monaco", _
    .Longtitude = 7.2, _
    .Latitude = 43.7 }, _
  New City With { _
    .Country = "Palau",
    .Name = "Koror", _
    .Longitude = 135, _
    .Latitude = 8 } _
}

And goes on to say that "which should read Dim Capitals = New City(){ _. It's clear that no one tested the code before publishing the update"

I don't think that's a fair comment as the document shows code that isn't even implemented in Beta 1. (e.g operators on Nullable types). So it is clear the document is forward looking, and talking about how things will/should be.

So, given that, if we stop and analyze the syntax for array initializers it should be basically as presented. Perhaps one could argue the syntax should be Dim Capitals() = {.    It should also support the syntax you can use today in VS 2005, e.g: Dim ints() As Int32 = {1,2,3} , or as per the code Roger suggests Dim ints() As Int32 = New Int32(){1,2,3}

Okay so given the minimum it needs to support (current syntax), in VB9 we add anonymous types and inferred typing.  Inferred typing means we remove the "As XXX" part.  So this means the syntax Dim Capitals As City() becomes Dim Capitals and the Dim Capitals() As City syntax becomes  Dim Capitals().  Anonymous types means we can't define the type name. So New City() { would become New() { _ , and given that the existing syntax doesn't even require the New Int32(), the New() becomes superfluous because the set brackets { } define the array data.

IOW: the syntax as shown is as it should be. (IMO)

I was listening to Sean O'Driscoll's blog cast earlier today while working in the kitchen, and one thing stuck me was the analogy he made about buying a camera.  This reminded me of something I saw on a Dell forum recently...

I had purchased a Dell monitor, and the monitor itself is beautiful , but there was/is a problem when it comes to using the integrated SD card reader.  After searching their forums I found out it was a problem with the monitor in general not just mine.  Not a big deal to me, but a bit disappointing.

The thing that really struck me while searching their forums was a post by someone who asked if they should buy that monitor.  They were concerned after reading a lot of negative feedback.  The good news for them and Dell was the replies were a resounding yes.

But it got me thinking about how many probably were asking the same question but never did.  What kind of impression does newsgroups and forums leave on your customers ?

I find Dell's pretty good because you do seem to have a high level of clearly visible interaction from Dell staff.  But still, the site is all about problems, the bad side of things.  It gives you as much confidence as wading through a mass of KB articles.

So do newsgroups or forums help sell your product ?  I don't think so, they can however sell a vision of good or poor product support.

When it comes to actually telling the good story, the passionate story, I think blogs are the primary source.  Magazine articles too often provide great reviews. Company web sites however are always going to try to sell, and so people do tend to view that with more skepticism.  The problem you have with 3rd party sites, blogs or review, especially comments on reviews is the question of credibility.  I've read reviews for hotels that make the places sound really nice only to discover it's more like a place where you'd bring your own fumigator to.

Personally I tend to like blogs, and find them more credible. I suppose the problem with dingy hotels is the reviews have been anonymous as such, where as blogs, people tend to want to ensure they remain credible.  Of course not all blogs are good, some are just marketing, and all have the tendency to be biased to some extent, after all they are about people's opinions.

Are blogs a good way to research any purchase you've got planned ? Web sites ? Newsgroups or forums ? What web resources do you use to help you make purchasing decisions ?