Russ Lewis MCSD

www.stormsoftware.net

Microsoft Certified Partner

How great is this?

A simple site with a simple purpose and exactly the right name!

Well done, those folk at http://www.connectionstrings.com/ 

Learn247.NET <http://go.microsoft.com/?linkid=1510978> - The WeRock 247 <http://go.microsoft.com/?linkid=1510979> & Football 247 <http://go.microsoft.com/?linkid=1510980> Samples:These go way beyond just being 'samples'. Both applications come with training materials that lead you through building the applications from scratch. Introductions are given to the technologies involved which span Smart Client, Web Client, Mobile Client and Web Services and the materials are available online or for order on DVD.

I wanted to experiment with the different forms of referencing the local machine's database localhost, (local), ., 127.0.0.1, etc., so I built this little tool.

Warning - the tool uses sa & no password - I dont! And neither should you!!!

Source available here

Exe from here

BTW - the “.” seems to work well

This morning I read with glee, Rob Chartier's mini rant about VB.NET's option strict. I say “mini rant” in the hope of encouraging Rob to rant some more, but first I wanted to rush to the defence of the VB .NET team on one point.

I'm a VB programmer who moved to C#, so I also had a phase of damning the team for not adopting a consistent set of keywords across the two languages. Rob cites static (C#) and Shared (VB) as an example and asks why not just adopt one or the other. It would certainly make life easier for me. Actually, the benefits are even greater when you consider override (C#) and Overrides (VB) or new (C#) and Shadows (VB).

By now I've mentioned enough examples to set out the arguments against such a move. If C# and VB.NET had the same keywords:

• Which case would you adopt, lower case throughout as in C, or Icapped as in VB?
  • Perhaps we could have a set of aliases like we do for the primitive types so that a C# programmer can type new and a VBer New
• Which set of keywords do you choose?
  • The C# set are good because C, C++ and Java people are all familiar with them
  • The VB ones are good because they often describe the functionality far better (isn't Shadows a nice way of describing the effect achieved by adding a function in a derived class that eclipses the function of the same name in the base class?)
  • Maybe you decide each on its merit and produce a mixed ancestry. Yet sometimes the words are equally meritorious. Static variables are both static in memory and shared between instances.

VB .NET developers, in the main come from VB developers. I've not yet heard of people moving into .NET as their first programming experience (although a couple of Universities have started exactly such programs.) When they do start learning programming by learning .NET, I guess they are more likely to choose C# as the language - I would certainly advise them so to do.

So, VB .NET is there to allow millions of VB 3/5/6 programmers to move into OO and for them to stay up to date with the MS environment. Consequently VB .NET has to keep it's existing set of keywords for those people. But VB .NET introduced several keywords that did not exist in VB to allow for inheritance. And they chose descriptive words as is the tradition of VB because there was no reason to maintain a tradition with C. Interestingly, many of these VB developers have found the move to VB .NET too tough, but that's another story!

So, if the decision was to produce a single keyword set that was mixed, they would alienate both sets of developers. If they chose the C keywords, as they did for C#, they would alienate the oft-mentioned “millions of VB developers”. And if they went mixed, they would upset everybody!

IMHO, what the VB .NET team have done (or were told to do) is to “dumb down” VB .NET to the point where it is no longer the language of choice for serious, knowledgeable VB developers. I read sometimes that they are trying to re-introduce the RAD into VB, yet I don't think there's much difference in the number of keystrokes taken to type VB and C# code. Where it will make a difference is when wizards and helpers start to generate code. But frankly, that code could be in any language.

I do a lot of training and am involved in writing courses, where VB .NET has its place. For example, it's easy for the wider audience to read 5 lines of VB code that demonstrate some point, than it would be to read C#. Whether the audience chooses to write VB or C# is another matter, but I'm sure the C# writers can read both languages with ease.

However, I do agree with Rob and many others who have made the point about Option Strict - it was madness of them to default that to Off. Especially when you consider the rationale was to make VB .NET more like VB and to allow VB6 code and coding practises to be supported in .NET.

Sushila Patel announced a series of training / labs for Office 2003 at

http://weblogs.asp.net/SushilaSB/archive/2004/03/26/96760.aspx

Since I've added WSE to the Web Services course, I was please to discover this 'positioning piece' from Omri Gazitt. The full version is here, but this extract describes WSE nicely:

So what is WSE?  WSE is a different kind of release.  It is a platform enhancement technology.  Shipping major platforms every few years is a fact of life, but some technologies move so quickly that customers need updates well before the next platform comes out.  Web services is one of those technologies.  So we created a new model for getting enhanced platform technology to our customers - and thus WSE was born.

WSE is a supported product in the same way that any Microsoft platform is - you can deploy on it, and we support it via Microsoft's Product Support Services.  But there are a few important differences.  First, each WSE release is supported for 2 years + 1 year of extended support (compared with the 5+2 model for major platform releases).  This is because we anticipate doing releases on around a yearly schedule, and our goal is to have at most 2-3 versions to support at any given time, so we can deliver on our goal to ship on the order of once a year.  Of course when the major platform comes out, we encourage developers to move to that platform, which is supported at 5+2.  Another difference is that WSE is not necessarily integrated with anything - there are no complex technology interdependencies - WSE is a standalone product and can therefore ship on a faster schedule.  Yet another difference is that we don't guarantee compatibility between releases - Web services are evolving quickly, and we often implement early versions of the specs which get superseded by the final versions (e.g. WS-Security getting superseded by OASIS WSS-Security).  Finally, while WSE is also "hardened" from a functional quality, security, and stress point of view, there are things that we don't do with WSE that we do for major releases - for example, we don't localize WSE.  For all of these reasons we are able to create new versions of WSE faster than we can roll out major platform releases.