Spotty Bowles on VB.Net

One of the VBWire links at the top of the forum pages takes you to "Multi-Targeting.. blah blah.. VS 2010" which itself seems to be nothing but a bump up for some Channel 9 interview with the unfortunately named Spotty Bowles. As we know Channel 9 lost all relevance to most of us when they went silent on VB6 topics in mid-2005, so I hadn't seen this until just now.

It was informative to see that compiled VB.Net programs do not run with "any" version of the Framework installed, and normally won't work with any version except the one targeted. While multi-targeting appears to be possible it takes careful gyrations.

Now, none of this would matter much except it seems to fly in the face of claims we've seen right here time after time (after time). Claims about how easy it is to deploy VB.Net programs, how you don't need to worry about Framework deployment because "it's just in there with Win7," and so on.

There are other gems such as how much crap was shaved off VS2010 "out of the box" to make the whole thing appear lighter... "but you can download it, yadda yadda tappity-tap."

It seems to come down to 5 targets now, between choices of CLRs intermixed with various Framework subsets (client vs, full) on top of each CLR.


It appears you can aim at one of these targets and chuckle to yourself that, say, the client Framework on top of the 2.0 CLR will work... but at runtime (probably once deployed to a user) everything crashes down hard after runing for a few minutes because you have finally tripped over a late-bound dependency that requires the full Framework.

What a travesty!

And all very reminiscent of the shattered fried marble world of Java runtimes loose in the wild.


So this single Webcast makes it clear that a .Net application that must run outside your development machine really does need to deploy the entire Framework/CLR for the version of .Net you developed against. If you hold your mouth right you might get away with targeting a compact "client Framework" but you can't count on users having that installed either. It also discusses the way some VB.Net 10 features work targeted against CLR 2.0 while others will just KABOOM unexpectedly.

I can't wait for Spotty Bowles to do his own version of Alice in Wonderland, but Lewis Carrol has nothing on him for amusing romps down the rabbit hole... once you get past his thick accent.


The interview finishes with a lot of apologizing, handwaving, and tap dancing about the many scenarios where multi-targeting breaks down. The good news is that if you're a Microsoft insider you might even find a band-aid for some of those situations. If you enjoy a good Wumpus Hunt the VS 2010 IDE will keep you busy for hours chasing down dialogs within dialogs within dialogs to track down your "Sorry, play again?" compiler warnings.

Once again, just like doing Java development.


You can read his Multi-Targeting Visual Basic Applications in Visual Studio 2010 to avoid 40 minutes of hard to comprehend speech and his failed attempts to make the stuff he says works actually work.

So you seem to be saying that Multi-targeting frameworks does not appear to work well i dont see this as a big deal, we always target a specific Framework with our .Net apps.

Quote:

---

It was informative to see that compiled VB.Net programs do not run with "any" version of the Framework installed, and normally won't work with any version except the one targeted. While multi-targeting appears to be possible it takes careful gyrations.

Now, none of this would matter much except it seems to fly in the face of claims we've seen right here time after time (after time). Claims about how easy it is to deploy VB.Net programs, how you don't need to worry about Framework deployment because "it's just in there with Win7," and so on.

---

I dont see how these two issues are related, ease of deploying application in .Net has nothing to do with targeting multiple frameworks.

As far as i see it what people have said in other threads about the framework is about the ubiquity of the framework deployment. XP SP3 installs the 2.0 Framework, and the 3.5 framework is a cumulative update that includes the earlier frameworks. So you can target the 2.0 Framework for instance and you app will work on any machine that has either XP SP3 or above installed.

This directly from Microsoft -

Quote:

---

Microsoft .NET Framework 3.5 service pack 1 is a cumulative update that contains many new features building incrementally upon .NET Framework 2.0, 3.0, 3.5, and includes .NET Framework 2.0 service pack 2 and .NET Framework 3.0 service pack 2 cumulative updates.

---

Quote:

---

Originally Posted by dilettante

And all very reminiscent of the shattered fried marble world of Java runtimes loose in the wild.

---

I quoted that just to preserve it. I haven't a clue what that metaphor means, nor can I pictured what "fried marble" looks like. It is a very evocative image of a very unevocative thing, and that's worth preserving.

Other than that, and the fact that Spotty Bowles is a terrific name....for somebody else to have, the only point I would make is that Late Binding is mostly a bad idea anyways. When it has to be there, you need to be pretty careful about your testing, for reasons other than the .NET framework.

My real question (not point, since I was hoping to discover the point) is that the "your .Net program just runs anywhere" must not be true. Otherwise there'd be no need for multi targeting, would there?

The process seems more than a little bit finicky from the demos in the webcast and the points made in the white paper. I was particularly confused by the point that deploying the Client Profile Framework can fail if the target machine already has a Full version of the Framework installed.


Be that as it may... can anyone then describe why multi targeting is considered such an important feature in VS 2008 and 2010?

If "it isn't needed" then, er, why is it needed?


Fried Marbles break into a large number of sharp shards when dropped.

Fried marbles are a new one to me. Pretty cool, though.

The value I see to targeting multiple frameworks is that, if you have a program built targeting 2.0, you can still work with it in VS2008 and VS2010 while still having it target 2.0. Prior to VS2008, which first implemented multi-targeting, every time you switched VS versions, you either had to change your program to target the new version (thereby requiring users of updated versions of the program to also change), or you had to retain the old version of VS just to maintain that one program. For that reason, I still have VS2003 on some computers because I still have some programs that target framework 1.1, and none of the multi-targeting editions reach back that far (nor should they, in my opinion). However, when I moved to VS2010, I didn't have to change any of the programs that target framework 3.5 to work on them in VS2010, because 2010 will target 3.5 without any problem.

Of course, there would be a problem if I tried to add 4.0 features to a program targeting 3.5, and I would have problems trying to use LINQ in 2.0, but those features don't add new capability, they just give you new and sometimes easier ways to perform old tasks. For example, I have a program that I originally wrote in VS2005 targeting 2.0 (of course, as that was the only one I could target in VS2005). I did upgrade the program to targeting 3.5 prior to release, but I didn't go back through and add a bunch of LINQ, because the program worked fine without it. Selective use of LINQ would have made the code simpler, and sometimes faster, but not enough to justify making those changes. Therefore, I could just as easily be still using VS2005, but now I can use VS2010, with all the new IDE features in VS2010, I just can't use 4.0 specific methods.

So that's all that multi-targeting means to me.