Once I installed Visual Studio 2008 it was time to add the Team Explorer for Visual Studio 2008.  The Team Explorer aka Team Foundation Client is found on the Team Foundation Server installation DVD.

So I took the .ISO file which I downloaded from MSDN and copied the TFC folder which contains the Team Explorer installation onto an actual DVD.  This gave me a copy of just the Team Foundation Client 2008 which I could install onto my development machines.

I put the DVD into my Vista/Office 2007 machine and kicked off the install.  The install ran and after things were going I moved onto another machine.  When next I checked I found that the installation had failed.  So I reported the failure via the automated process that the install package provided and tried again.  The install failed again - which left me... concerned.

So I took the DVD out of my Vista machine and moved to my Windows XP / Office 2003 machine and ran the installation.  While that was running I started searching the web for any known installation errors with Team Explorer 2008.  I finally found a note in the Microsoft MSDN Forums that mentioned someone else was having an install problem and found that it went away when they used the install from a DVD which had all of the TFS products, as opposed to a CD with only the TFC folder.

Now what was interesting is I found this as my Team Explorer install on Windows XP with Office 2003 completed successfully.  In other words on an XP machine running Office 2003 you only need the TFC directory to install Team Explorer.

So I went to my .ISO file and burned a DVD of the entire image this time and put it into the Vista/Office 2007 machine.  I must admit I really like the updated install package for the TFS product, having the different product options available is a nice way of handling the different install packages.  At any rate I clicked on the Team Foundation Client and started the install.  The first and subsequent screens to start the installation looked just like the stand-alone DVD's and the install started with the same packages.  However, in this case the installation ran to completion.

Thus if you are using Windows XP with Office 2003 you can install a standalone installation package for Team Explorer however, if you are running Vista or Office 2007 and you get an installation error - then make sure you get a copy of the full Team Foundation Server (TFS) DVD and run the install from that media.

So for those who weren't aware Visual Studio 2008 released on Monday November 19th.  I got my download started early while the downstream transmission speeds were still above 300KB and it finished late yesterday afternoon, early evening when the transmission speeds were down under 70KB.

So like many who have been using Visual Studio 2008 Beta 2, I made the decision to install Beta 2 on my main desktop (physical machine).  This was a good decision as I've been using Beta 2 for projects for the past 4 months.  However, now it was time to face the music - would I need to rebuild my box to get the release version installed?

As part of working on the next Version of Professional Visual Basic for Wrox, I have a virtual environment which was configured for my authoring and screen shots.  So it became my test platform.  I started the uninstall of VIsual Studio 2008 Beta 2, I uninstalled MSDN, and as I looked at the list of other products some of which hadn't uninstalled I found several that were from 7/27 the day I installed VS 2008 B2 and I could tell they were related, so I uninstalled them as well.  I then took a couple minutes to rename my old projects directory to "B2" since I plan to rebuild the projects from scratch and I made sure other directories that VS would target were also clean. 

So I took a fairly conservative approach to minimize the risk that it would fail.  I rebooted and connected my VPC to the ISO which I downloaded and kicked off the install with crossed fingers.  The installed started no problem.  Nearing the end of .NET Framework version 3.5 was install my Vista machine asked me to reboot and restart my installation, which I did.  The installation then ran to completion and asked for another reboot.

I then installed MSDN locally and again everything went fine.  So for those wondering installing the release version of VS 2008 on a machine which previously ran VS 2008 Beta 2 seems to a non-issue.  So get out there and get the latest bits and start working there are a ton of new features to explore.

It's Friday so in a slightly more light hearted spirit I thought I'd link to a less serious post.  I for one have written about and certainly talked about the persona Mort.  Mort for those not up to speed is a Microsoft 'persona'.  Microsoft created these persona's to help them focus on the type of person that used a given product.  Paul Vick has a fun little post describing (with pictures) three of the main developer persona's and suggesting that it's time for Mort to retire. http://www.panopticoncentral.net/archive/2007/11/14/22589.aspx 

My personal opinion is that Mort took a bath and learned C# a long time ago, he's got a big velvet Elvis hanging in his trailer.  (I'm saying this in the context of Paul's post) Thus from the standpoint of VB retiring Mort only makes sense, and I find the Ben persona much more appropriate

This winter I'll be taking my first crack at a new class at the UCSD Extension.  It's surprising that I'm heading into my third year teaching the Visual Basic .NET Programming II class and now I'll get to do my own lead in.  I'm looking forward to this opportunity especially since I'll be updating the materials to account for Visual Studio 2008.  As always I'll make certain the course supports those who only have access to the VB Express Edition in terms of lab work.

So if you are looking to learn about the most powerful and most popular .NET language, stop in for a class.

For more information on the when and where and if you are interested in registering for the course go to the UCSD website at: http://www.extension.ucsd.edu/studyarea/index.cfm?vAction=singleCourse&vCourse=CSE-40615&vStudyAreaId=14 

Often as a new release of Visual Studio approaches there are posts regarding, where are the two primary languages in .NET going?  In short as has been noted on one or two places around the net the VB MVPs posed the question of, what is the strategic long term expectation for VB and how is VB doing in the market?  Which language should I learn, which will help me get a job? etc.  

(The short answer regarding which language to learn is - if you are going to do just a little programming VB is easier to learn and maintain.  If you intend to be a Professional Software Engineer and limiting your career to being a full time Cubicle Code Monkey you need to know both. Just knowing C# or VB isn’t enough, as a developer I’ve learned somewhere between one and two dozen programming languages, to be honest I lost track of them all and stopped counting long ago – although interestingly enough I still have my high school ‘Basic’ programming book...sentimental value only - the point being casual developers will be more comfortable in VB and professional developers learn languages and VB and C# are both necessary with .NET today.)

At any rate focusing on the core topic, depending upon where you ‘stand’ your view of VB or C# might be that it’s doing great or not so great.  After all if you are working in a shop where your senior management likes C# it might seem like very few people are working with VB. 

On the other hand this perception might be a self-fulfilling prophecy for your company. After all if every project uses a hammer then there must be a lot of nails (how’s that for twisting a proverb “if all you have is a hammer everything looks like a nail”)  If your company “supports” both VB and C# languages but encourages that new projects use one language well then you begin to wonder.  As I noted in the past I’d consider that pretty short-sighted for a consulting company.  After all if your goal is to sell software as a service (which consulting companies do) you don’t want to lose a major portion of your market to language bias… so before I go further I want to clarify where I got some of the data I’m about to toss out.

I think it’s common knowledge that I’m an MVP (I can hear some of you: ‘could he mention it one more time…’) anyway I bring this up to note that it shouldn’t be a shock to realize that as an MVP I have a Non-Disclosure Agreement (NDA) with Microsoft.  This comes up because as a group we MVP’s have some communication channels (formal and informal) with Microsoft.  One of the formal ones revolves around my specialty area Visual Basic.

In this area the VB-MVPs have essentially an opportunity to truly speak freely to Microsoft on NDA topics.  It’s where we can say we think that feature A is useless or that we think the VB team has dropped the ball by not having a given feature, or where we think they need to take the ball and really run with it.  It also allows us to ask questions and get answers that might embarrass one or more people at Microsoft.  In general it is a valuable tool.  Every so often we get permission to post some information from that discussion to help frame discussions outside that group – things that aren’t too germane to actual company business, and that’s the case for the numbers I’m about to post.

There are way more people online downloading C# right?  Wrong – At this point you aren’t going to be surprised when I say the VB Express is the top download of the Express editions.  It probably also doesn’t surprise you if I say that it’s downloaded far more frequently then C++ Express.  But does it surprise you when I note that C++ is the number 2 download behind Visual Basic.  It surprised me, after all I expected Visual Web Developer to be in the top 2 (after all both VB and C# web developers would use that one tool).

That’s right Visual Basic alone is more popular by a margin of 20% over C++ <credit VB Team>.  What I will say is that the other three express editions are all much closer in terms of downloads, and registrations.  The point is that Visual Basic is noticeably more popular. Of course this is the Express Edition, that’s for students and hobbyists, they aren’t professional developers.

So how big is Visual Basic when someone reviews the market?

Well according to Forrester research Visual Basic is the #1 .NET language. <credit VB team>  Note that’s not some legacy number based on COM developers, that’s just in terms of .NET developers.  That’s right the majority of professional developers out there are using Visual Basic, and that even makes sense.

Think about it this way, prior to .NET the two primary development languages were C++ and VB.  C++ was far more powerful, but it took longer and cost more to develop applications.  Sure for someone developing tools or with a huge install base the disadvantages could be overcome for the power.  VB on the other hand was much easier to learn and use, the code was easier to maintain and its performance while not equal to, was certainly comparable to C++.

Along comes C#, from the standpoint of C++ developers C# offers a familiar syntax and reduces the disadvantages of C++ - applications were easier to develop and accordingly cost less.  C++ developers and Java developers have without a doubt flocked to C#.  In fact if you are a Java developer and haven’t moved to C# boy are you missing out on the future.  However, these were smaller developer communities to start with then Visual Basic which also released a .NET version.

Visual Basic also moved to .NET and its disadvantage – not having the same runtime environment and power as the other major language went away.  Note the fact that VB is easier to learn, read and maintain is still true but now you also get all the power of C# and since .NET creates code on par with C++ it means you as a VB developer are creating first class applications.

Sure some people have jumped from VB to C# that is to be expected, and many companies which in the past would have C++ for some projects and VB for others are moving to use only 1 .NET language.  However, as I’ve noted in the past most VB developers will find the transition to VB.NET fairly easy and natural.  When I teach I find that the students with previous VB experience do very well, and in fact that once they get the key elements of Object Oriented Development are ready to become productive.  More importantly the VB teams recent move from a migration wizard to the Interop toolkit (similar to WPF Interop) and the Power Packs make the transition from VB6 much easier.

What is interesting is how the VB team blog (http://blogs.msdn.com/vbteam/) ranks in the top 1% of all MSDN blogs and the fact that the VB Developer center on MSDN is one of the top trafficked sections of MSDN (http://msdn2.microsoft.com/vb). <credit VB Team>  In other words VB is doing just fine and as I’m sure we would all agree so is C#.  In the near term there is no reason to suspect anything about this equation will change – C++ and Java developers will tend to prefer C# and those who have mastered both VB and C# will prefer VB J

So what about the future?

Well for starters the Visual Basic team recently published the Beta version of the Visual Basic language specification.  A great step for defining how the language works, and one I look forward to seeing become the basis for standardization.  We also know Paul Vick is discussing VB X (aka VB 10)  over at Panopticon Central (http://www.panopticoncentral.net/) and is very open to input on things to deprecate in the languages specification and new language features to add.  I highly suggest going over to get in a good suggestion or two.  As for Visual Basic – I’m confident that it’ll be around and diving into all corners of the Microsoft development tools.

So this is a quick post to place my vote on the recent changes to daylight savings time.  When it comes to movng it earlier in spring back toward Febuary, that works for me. 

However, moving it from the last Saturday in October to the first Saturday in November messes with Halloween.  Instead of it getting dark an hour earlier so that the Trick or Treaters get out earlier and finish earlier - everyone waits for dark to fall and the result is: Trick or Treaters are out for almost an hour later at night.

I know that some will say that having the sun out makes trick or treating safer but as was shown tonight - that is only true if people change the habit of waiting till dark.  We didn't base our trick or treating when I was growing up on a time, we based it on sunlight -when it was gone we got to go out.  So don't make up alot of claims about safety, the reality is this is one of the few nights (July 4th is another) when kids get to go out after dark.  And as I recall we kids love that aspect of it.  So instead of everyone being done by 7:30 or 8 they are finishing up around 9, meaning they are out later which is in my opinion a bigger risk. 

So with all due respect, to everyone's claims of non-existant energy savings and safety, put daylight savings time back to ending at the end of October, Thanks

I actually a while back wrote a discussion on software estimation that someday I'll post.  However, this evening I ran across another item that I felt it worth pointing out.

In general I consider software estimation to still be more art then engineering.  I don't mean this as a complement, I mean that its predictability, which in engineering we strive to keep high, is in reality low (experience people operate closer to medium predictability...) Part of the problem of course is the ability to learn over time and effectively apply the lessons.  The fact is an experience software lead has learned over time how to estimate and may come close but the learning is of a more intuitive nature.  That's why someone will ask 'why did you estimate that X would take 3 days?' and the engineer's answer is the equivalent of 'because.'

So why am I bringing this up, well I'm going to reference one of those people who's blogs I follow in terms of the business of software.  As I've said in the past - if you are working in this industry not only should you be keeping up with technology, but you need to take some time to learn about the business side - and estimation definitely falls into that category.  Let's face it, from an engineering standpoint I wouldn't care if I finished in a week or a month, but from a business standpoint - well that is a huge difference.

With the release of their latest version of FogBugz, Fog Creek has introduced a new feature for software estimation.  In short the idea is that over time as you define and estimate tasks the software tracks the accuracy of an individuals estimates over the course of a project.  It then determines an accuracy factor.  Over the course of several projects it refines this factor.  It then applies this factor to an individuals estimates - for more information check at Joel on Software's blog at: http://www.joelonsoftware.com/items/2007/10/26.html 

On the surface this is a great feature and I like it but a couple notes, not to bash but as a warning since even my first impulse is to say "I'll take 2".  First the estimator (person creating the estimate) can't know what the tool's adjustment factor for their estimates is because they'll probably 'game' it.  That is to say the estimator will consider their estimate and if they know that the tool will double it, well they'll reduce it by some percentage, because of their inate desire (and it may be totally unconscious) to hit some number (generally as low as possible).  After all the estimator says (ex: "I know I was over by 50% last time over the project so I was going to double my initial gut estimates but the tool is going to do that so I'll need to reduce my estimates so that when the tool doubles my estimates they won't be too high.")  The net is this can result in a reduction of the original estimate to account for the tool's automated increase.

The second thing to keep in mind is that the tool doesn't account for the fact that each project is truly different.  If the developer were consistently estimating the same type of task then the 1 to 1 corrolation that the tool applies makes sense.  But if project 1 is say a desktop application and the developer's UI estimates are 50% under and the next project or the third or fourth consectutive project is suddenly an web UI or a pure business interface and as such the developer's estimate is 90% correct - well suddenly the game has changed and in reality the previous estimates shouldn't be weighted as heavily - but how heavily is the question, that 50% and 90% could also be reversed.  The tool isn't magic and it can't account for all of the variables. 

Finally by its nature this tool will always penalize someone who's estimation skill is improving.  The first set of estimates might be all over the map, the next set might be consistently 25% of actual and then if the estimator sees this and ups their estimates by 150% the correction factor of the tool will suddenly make the estimate way over the top.  Something to keep in mind whether your tool is a fancy algorithm or a set of multipliers in an Excel Spreadsheet - the tool is only a tool - you will still need to carry out a reality and business cost review of the estimate.

One of the most highly anticipated features of Visual Studio 2008 is XML Literals.  It doesn't sound like much until you start thinking about some of the ways that you can leverage this capability.  One creative way is to replace code, Beth Massi of the VB Team recently made a post highlighting a little of the power that you can have with XML Literals in Visual Basic 2008.

http://blogs.msdn.com/bethmassi/archive/2007/10/23/avoid-underscores-in-your-multiline-strings.aspx

What's interesting is her post leverages another new feature call type inference which allows her to create the new object with specifically needing to specify details of the type.  She continues the example but just the first section allowing you to format strings without any special characters is pretty awesome.  Of course the syntax <%= %> might give me nightmares of ASP but overall the capability is very cool, and combined with some of the power of XLINQ that VB provides (see Scott Hanselman's post: http://www.hanselman.com/blog/XLINQToXMLSupportInVB9.aspx) VB is definitely looking to simplify working with XML... you know that data structure which is at the core of things like XAML and Silverlight.

Update:
Beth's keeping the XML literal ideas going with her latest post: http://blogs.msdn.com/bethmassi/archive/2007/10/26/xml-literals-tips-tricks.aspx

So the latest industry buzz-term (since it's not a word per say) is MVC.  MVC is a description of a software pattern.  The key to software patterns is being able to speak them and understand them.  I'm sure you've read many articles that mention MVC and you sit there wondering: What is MVC?

So some 'jerk' (you know the type who provides your latitude and longitude when you ask where you are) says to you, "MVC stands for Model-View-Controller and it's the latest in architecture." 

OK, What is a Model View Controller and what do I need to change in my architecture?

This is actually a pretty simple question and as I've said before, outside of major paradigm shifts - the more things 'change' in the technology world, the more they stay the same.  Many years ago - probably before some of you reading this were born we had the concept of a 3-tier architecture.  The idea, which followed on the heels of modular programming was that you should separate out your User Interface from your Business Logic from your Data Access.  (UBD... or reordered DUB) Over time this was called n-Tier because you might have more then one 'tier'.  The idea however was that you had components responsible for these elements.

Well in an MVC model the Model represents your data access, the View represents your User Interface and the Controller represents your Business Logic.  So you have DUB -> MVC - but wait say the formallists, it isn't the same.  So what's the difference?

Well under the n-tier model there were those who subscribed to the idea that all communication had to travel from the User interface to the Business Layer to the Data Tier, and in the reverse.  In other words the User Interface wasn't allowed to directly communicate to the Data Tier.  We tended to refer to people who tried to enforce this as 'jerks' (see above).  Generally those of us developing applications spent hours justifying the fact that in the real world it made sense to have the User Interface directly access the Data tier to retrieve key data and in some cases even for certain key automated updates.  That's essentially the gist of the difference.

So there you have it because people couldn't adapt to this one concept we have a new name - MVC to describe an old concept.  So when someone suggests you re-architect your current n-Tier application to be MVC based and they want to charge you money to do so - well you know how much it should cost - nothing because even if you kept your UI from updating database directly, you still have an MVC architecture in place.... now you can just stop being so * retentive about which components in that architecture communicate.

Its funny we literally created a new name for an old concept, why?  Well the 'jerks' will accept a concept with a new name that doesn't exactly match their understanding of an older concept.  It's literally easier to reaname and remarket a concept then to for some people to update their knowledge.

The preceding is of course a brief comparison - to wit there are several other characteristics of the architecture models I've omitted (such as n-Tier) in order to quickly illustrate the key similarities between these models.  I'm sure someone (see jerk above) will point out one or more such items in the comments...

UPDATE: I should also point out that yes the MVC pattern has probably existed for as long as the 3-tier architecture has. The point here is that it is the latest trend for architects and for many the new description seems like it is describing something... well.. new.  In the past MVC was a common model for application logic but now that more "software architects" are actually learning about software best practices it has made the move to describing enterprise architecture.  The concepts aren't new, just the name being used to describe what we've been trying to do.

Microsoft recently released Visual Studio 2008 Beta 2 (http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx).  Being the type of developer who is always interested in such tools and more importantly currently being involved in a couple Windows Presentation Foundation 3.0 projects I was one of the first to download a copy.  One of the new features of Visual Studio is that it allows you to target your builds at the .NET 2.0, .NET 3.0 or .NET 3.5 versions of the .NET Framework. 

My expectation although the documentation doesn’t claim it, is that I would be able to start using VS 2008 while other members of my team continued to use the older Visual Studio 2005 with the November 2006 CTP extensions for WPF support.   I was partially (mostly in fact) correct – but it requires a few ‘tricks’, and more importantly even for true .NET 2.0 projects that isn’t a true statement.

The warning shot was fired when I opened the project solution.  The first thing that VS 2008 did was initiate a conversion wizard to convert the solution and project files on the project.  It kept them targeting .NET 3.0, but they would no longer open in VS 2005.  Fortunately I hadn’t checked anything into TFS so I copied the files and undid my changes.  (Note: I later tested with .NET 2.0 projects and the result is the same.  There is actually a reason or arguable merit for this, as I’ll explain as I discuss how to manage this scenario.)

So what I then did was take my solution and project files which I had converted and copied out and named them with the original project name plus “2008” on the end.  This meant I still had the original project files and the newly converted files.  In comparing these files it was apparent the scope of differences was minimal – in fact it was mainly a couple strings to reflect that these were in fact 2008 versions of the same file.  So I modified the solution file and instead of referencing the projects in the solution by their original name I adjusted the solution file references to be the other “2008” versions of my project files.

I then reopened my new solution file in Visual Studio 2008 and found that my solution would build and was maintainable.  In fact I was able to work in this mode quite literally for a couple of weeks with no issues what so ever.  It then came time to package this project for deployment.  We were using a Click Once deployment model and this is where two issues were discovered.  The first issue was that Visual Studio 2008 Beta 2 did not include a signed .NET 3.0 Framework redistributable package that you can add as a dependency to your project.  There wasn’t much to be done about this but I did mention it along with my other problem to Microsoft.

The second issue was that while in the project properties, if I clicked on the Security tab, Visual Studio 2008 crashed.  Not threw an error - it crashed and burned.  As part of being a Microsoft MVP I have access to a shortcut for contacting a couple people on the development team about issues when I’m working with something like VS 2008 Beta 2.  In this case I mentioned my concerns about having new project types, my concern with the .NET 3.0 redistributable and  my issue with the Security Tab for my project’s properties causing Visual Studio 2008 to crash.  This got the attention of Eric.Knox one of the ‘developers’ @Microsoft who emailed me about reproducing the problem.  Because the customer was comfortable with me sending this problem to Microsoft I forwarded Eric a complete copy of my solution files (fortunately it was a relatively small code base).

Eric was immediately able to reproduce my problem (which was good) since I was now bothering someone who's time is arguably more valuable writing new features into the product J.  After a couple hours Eric contacted me to tell me what the problem was.  In short when I readdressed my solution file to reference my project files, I failed to also adjust the project references in my project files to do the same thing.  For most of Visual Studio this wasn’t a problem, but in the case of the security tab this caused a fatal error.  Eric was able based on my code to find this in a relatively short period of time – and in the RTM version of Visual Studio 2008 the environment won’t crash if you repeat my mistake.  At the same time however, this is still an error in Visual Studio 2008 and the error message you get may not be the most helpful.

The key is you need to be certain to convert the project references in both your solution and project files if you want to develop on Visual Studio 2008 in parallel with someone using Visual Studio 2005.  Aside from the preceding issue I’ve had only one issue (that I’m about to discuss) working this way, and being able to work in Visual Studio 2008 has made me far more productive then I would have been with the Visual Studio 2005 environment and the XAML editor which is almost non-functional (for complex XAML).  In general I’ve just manually added new classes placed in the Visual Studio 2005 versions of the project files to mine and vice versa.  The coordination on that level has been very easy and relatively painless – so if you are in the scenario where not everyone on a team is in a position to move to Visual Studio 2008 simultaneously, I’d still go for it on .NET 3.0 projects.

However, there is the remaining issue which appears to coincide with the reason Microsoft is moving the project files forward.  I stumbled on this issue quite by accident when during development I created a new class in the project.  As part of this new class I happened to syntax which is based on the new release.  I didn’t reference any .NET 3.5 libraries but I wrote my VB/C# code using syntax which the Visual Studio 2008 compiler recognized.  However, Visual Studio 2005 and Visual Studio 2008 don’t use the same build engines and as a result when a team member tried to compile my new class the compiler kicked out my code.  So if you are going to attempt this route recognize that although you are still building a .NET 2.0 compatible project (based on the libraries which are referenced) you  will have access to language features that are interpreted by the compiler at build time which aren’t compatible with the build engine a Visual Studio 2005 developer will use.  Again this wasn’t a major problem, in fact it was incredibly easy to recognize and resolve but this is probably the type of issue that the folks at Microsoft were most concerned with when they made it so that the same project file wouldn’t work in both build environments.

Finally of note, keep in mind that a new version of TFS (TFS 2008) will be shipping with Visual Studio 2008 along with a new version of Team Build.  Both have several new features that you’ll want to access and since your old Team Build 2005 won’t like Visual Studio 2008 projects – you’ll need to upgrade to TFS 2008 in conjunction with or before you move your developers to Visual Studio 2008, so make sure you start looking at that Beta 2 product now as well.