« February 2005 | Main | April 2005 »

March 21, 2005

Great COM Interop Talk

This talk digs into the COM Interop options available, and how to decide between them. Very good stuff. It looks like this was delivered to Microsoft internal folks, and is now available on the web. That's fantastic!

Other tidbits "Core Office is written in C" (not even C++)

Posted on March 21, 2005 at 08:28 PM | Permalink | Comments (0)

March 17, 2005

Scott and Rory sitting in a tree

No kissing (yet), but some slapping.


"No, because after he prints it, he's going to take a picture of it."

Posted on March 17, 2005 at 09:22 AM | Permalink | Comments (0)

March 16, 2005

Granular late binding : VB Whidbey Fun

I was doing some stuff with performance counters in Whidbey when I realized that they just didn't work for a couple of things that I wanted to do. % Disk Time is just broken, and I couldn't use a network performance counter because .NET truncates the instance field to 64 characters.

No biggie. I'll just inherit PerformanceCounter, and make a couple of specializations that work for network and disk usage. Crap. PerformanceCounter is sealed.

Ok, generics to the rescue. I'll just make a:

public void DoAnalysis(PerfCounterType counter)
// some stuff
// some stuff

Won't compile because the compiler can't verify that what's passed in actually exposes a NextValue method (well, in this case, the compiler could verify it, but it couldn't in every case). Ok, this is what constraints are for. I should be able to do something like:

public void DoAnalysis(PerfCounterType counter) where PerfCounterType: PerformanceCounter, CustomPerfCounter
// some stuff
// some stuff

Crap. PerformanceCounter is sealed and you can't use a sealed class as a constraint.

Ok, the following is not, (I repeat, NOT) what I actually did, but what did pop into my head was something interesting that VB + Whidbey makes possible.

I could have a partial class where most of my code is, and have Option Strict On in that class (early binding).

Then, I could make another file with another portion of the partial class that contains:

Option Strict Off
public void DoAnalysis(Object counter)
// some stuff
// some stuff

In other words, with partial classes and VB.NET, most of your code can be option strict on, but you can set up individual methods to be option strict off (late bound). You couldn't do this with VS2003, because you couldn't break a class across multiple source files. Fun.

Posted on March 16, 2005 at 03:21 PM | Permalink | Comments (1)

March 15, 2005

Smart Client Offline Application Block (SCOAB) Demo

A while back, I put together a demonstration the shows the basics of using the Smart Client Offline Application Block (SCOAB). I've posted it to my web site. Enjoy.


Posted on March 15, 2005 at 11:19 AM | Permalink | Comments (15)

March 12, 2005

Support for VB6 is not ending

I'll have to admit, I was personally very ignorant about the difference between mainline support and extended support, and assumed that extended support equated to sucky support. Here's the deal in a nutshell, as pointed out by Jay Roxe. The end of mainline support means that you have until March 31 to use your two free support incidents that came in the box with VB6. So if you've been saving up something really good to call Microsoft support about, now's the time.

After March 31, your free support incidents are no longer valid, and you have to pay for each support call that you make. To calculate how much this is giong to cost you, use the following worksheet:

1. # of phone support calls for VB6 made in the last year ______
2. Cost of each phone support call $245
3. Multiply lines 1 and 2 ______
4 # of web support calls for VB6 made in the last year ______
5. Cost of each web support call $195
6. Multiply lines 4 and 5 ______
7. Add lines 3 and 6 _______
8. Enter the greater of - 0 - or line 7 _____

This amount may be further reduced if you qualify under the Silicon Valley Hair Growers Relief Act of 2001. To determine if you qualify, complete worksheet 2003vs and enter the total here ______.

For example, when I fill this out, I get:

1: 0
2: $245
3: 0
4: 0
5: $195
6: 0
7: 0
8: (annual cost to me of VB6 transitioning from mainline to extended support): 0

As Jay also points out, VBRUN.dll is part of the windows XP operating system, and will be patched and supported as long as XP is, so the only thing that's switching to extended support is the IDE.

Posted on March 12, 2005 at 08:10 AM | Permalink | Comments (0)

March 11, 2005

C# Late Binding

With one line of C# code, you can invoke a method on an object using late binding. You might find this easier than the Reflection GetMethod Invoke dance.

The only catch, you have to reference Microsoft.VisualBasic. This gives you access to the LateCall and LateGet methods. LateCall lets you invoke a method. LateGet does the same thing, but gives you access to the return value.


using System;
using Microsoft.VisualBasic.CompilerServices;

namespace LateCS

    class Class1
        static void Main(string[] args)
            object f = new Foo();

            // No return
            LateBinding.LateCall(f, null, "Bar", new object[] {"Scott"}, null, null);

            // Return
            string z = string.Empty;
            z = (string)LateBinding.LateGet(f, null, "Bar", new object[] {"Scott"}, null, null);

    public class Foo
        public string Bar(string x)
            return "Bork bork bork";

Posted on March 11, 2005 at 08:41 PM | Permalink | Comments (6)

March 10, 2005

Microsoft buys Groove

This absolutely rocks! I've been using Groove for quite some time, and the fact that it's being added to the Microsoft suite is a very good thing.

Posted on March 10, 2005 at 07:53 AM | Permalink | Comments (0)

March 09, 2005

Just plain wrong

There's a lot of hub-bub about the MVP petition to keep VB6 alive, with many links to this post. The problem is, this post contains a number statements that are just plain wrong:

It's "basically" impossible to migrate programs written in earlier versions of Visual Basic to the .NET version. That means any organization with an investment in Visual Basic code -- consultants, ISVs, IT departments, businesses, schools, governments -- are forced to freeze development of their existing VB code base, or reinvest virtually all the time, effort, intellectual property, and expense to rewrite their applications from scratch.

First, as the comments to this post point out, many people have migrated applications over to VB.NET. It is a porting operation (a.k.a. it's not automatic) , but there's nothing remotely impossible about it. Second, organizations are not forced to freeze VB6 development. VB6 doesn't stop working at the end of the month. VB6 still runs, compiles code, and any apps built with VB6 still work. You won't get the same support from PSS, but how many of you are really leveraging VB6 support today? In other words, you're going to find that March 31st is just like any other day. Finally, even if you want to stop doing new development in VB6 and start using .NET, you are not forced to rewrite your VB6 app. It's trivial to extend a VB6 application using VB.NET code. The interoperability works quite well.

Indeed, when it came to preserving its own code assets, Microsoft made certain its mountain of Visual C++ code would move quickly and easily into Visual C++ .NET. Microsoft Windows XP and Server 2003, Microsoft Office, Visual Studio, Microsoft's enterprise business solutions; they're all built in Visual C++ (as is practically everything else the company sells).

This is misleading. This makes it sound like your unmanaged C++ just automatically becomes managed C++. Not the case. Yes, Microsoft does ship a C++ compiler that's more similar to C++ 6.0 than VB.NET is to VB6. But, c++ already supported inheritance, constructors, etc, and didn't need to have those things added to the language. Also, as Microsoft does move things to managed code, they don't seem to be using C++ to do it. They're rewriting it in C#. In other words, moving any code to .NET, whether it's C++ or VB6, it's a significant porting operation.

Worse, Microsoft broke the sacred trust of BASIC developers; something the company carefully cultivated since its founding in 1975 (Microsoft Basic was the company's first product). Forward compatibility was a given until the arrival of .NET. Then, with the arrival of Visual Studio .NET, Microsoft chose to abandon its doctrine of evolutionary change in favor of a revolutionary "clean slate" approach.

Who are you kidding. I remember doing a lot of work to move code from one version of VB to another. Hey, where'd my ActiveX control go? What's this new ADO thing?

.NET is a completely different architecture. I'm not going to bore you with reference counting vs. garbage collection, but once again, moving any code from unmanaged to managed is a porting operation. This isn't unique to VB. Porting a Win32 C++ app to fully managed is a heck of a lot more work.

Also, I'm not trying to be hostile here, but let me make sure I understand this correctly. You're giving this kind of strong advice to developers, and you don't write code any more? I have a word of warning for people: take your advice about coding from people who code day in and day out. Don't take VB.NET advice from someone who only codes in C#. Don't take C# advice from someone who only codes in VB.NET. And please, don't take any advice about what language is best for you from someone who doesn't code. Now I understand why so many of these quotes sound like recycled myths. I suspect that they are the result of regurgitated complaints, not first hand experience.

Thank G-d I'm not dependent on having to program any longer, because with the release of .NET, I'd be farkled, fubar'd, and frazzled. Like many other developers, I don't have the time, energy, or desire to un-learn the substantial skills I've acquired in over 20 years of coding with Microsoft Basics, and re-learn some new thing that's marketed as Visual Basic, but is, in fact, radically different.

Welcome to software development. I've used over 25 languages since I started programming. I full expect that if I'm to stay in this field, I will always be learning new languages, frameworks, object models, you name it.

It's not too late or technically difficult for Microsoft to admit its mistake, and resurrect support and advancement of classic Visual Basic. There's no reason, technical or otherwise, why Visual Basic 6 can't coexist with Visual Basic .NET, just as Microsoft Visual FoxPro coexists with Access, just as Microsoft Visual C++ coexists with Visual C#, and just as Microsoft's Macintosh division coexists with the company's overarching Windows focus.

It does, VB6 coexists just great with VB.NET. You can call into VB6 code from .NET. You can call into .NET from VB6. You can run the VB6 and VS.NET IDEs side-by-side (much like I used to have to run Visual Interdev and VB6 side-by-side).

I'm on-board with what the petitioners want. I want it to, but let's at least stick to the facts and not mislead people about the realities of VB6 and VB.NET development.

Posted on March 9, 2005 at 04:06 PM | Permalink | Comments (18)

March 05, 2005

Shades of Green

Microsoft's "Project Green" was supposed to be a rewrite of all their ERP apps (Great Plains, Navision, etc.) on managed code, but Mary Jo says it ain't so.

Posted on March 5, 2005 at 01:44 PM | Permalink | Comments (0)

The return of transaction-oriented programming?

The System.Transactions 2.0 iceberg becomes visible on the horizon, and Stuart Celarier points to some very interesting things below the water line.

Posted on March 5, 2005 at 01:41 PM | Permalink | Comments (1)