VB.NET version of SCSF - OR - Starting point for VB.NET

Topics: CAB & Smart Client Software Factory
Jan 15, 2007 at 7:01 PM
I've been evaluating the adoption of CAB and SCSF for the rewrite of our internal administrative desktop application. CAB is a perfect fit, and I want many of the benefits provided by the SCSF.

However, we are a VB.NET shop. I don't want to start a religious debate on the virtues of the languages here. My development team is familiar with C# and could, if forced, adopt it. However, we would prefer not to. It is my understanding from some threads that I've found that Microsoft has had some legal issues with producing the GAT templates for SC in VB.NET. However, I think they may have been resolved and the plan is to release an update to SCSF sometime near April which includes the VB templates.

Of course, I really can't wait that long to start my project. So, the way I see it, I have three choices. I'm looking for help in deciding which way to go.

1) Don't use the SCSF, at least for now. We could start with one of the CAB sample solutions. I'm not sure which one is the best. The first stage of our desktop application is a Dashboard module. It's mainly a read-only display of summary information. Lots of tables and charts. One module, one workitem, simpler UI.

Later, when the SCSF for VB comes out, I can incorporate my dashboard module into the larger framework created by the SF.

2) Switch the team to C# and use the result of the SCSF. Of course, it may be possible to inherit from certain sections of the framework and write pieces in VB, as well as keep all existing business layer and model code in VB.

3) Use the SCSF to generate the solution. The use one of the code converters and convert all of the code to VB. A few days worth of effort, but made up by the increased speed the development team would proceed at in our language of choice.

Any advice or more information on the VB.NET templates of SCSF would be most appreciated.

Jan 21, 2007 at 8:03 PM
We the similar situation and it would be nice if somebody close to MS practice group address this as soon as possible.

Jan 22, 2007 at 10:54 AM
Another vote(plea) from me!
Jan 24, 2007 at 9:41 AM
Yet another vote!

The lack of a VB version of this tool is seriously hampering development.
Jan 25, 2007 at 4:38 AM
...and yet another vote!:)
Jan 27, 2007 at 5:53 AM
How long we have to wait until somebody from/close to Microsoft patern & practice gruop respond?
They should be reading this forum.

Jan 27, 2007 at 7:51 PM
If I throw out the language part of this question (C# or VB.Net), then the real question here is: should we start using CAB now, or wait until the SCSF is out? That is precisely the question many folks had to answer a year ago when the CAB was released and the SCSF was in development.

Our team elected to use the CAB and not wait for the SCSF. This was actually a good thing; we learned a lot about the CAB and how it works since we had to do everything by hand. We came up with our own conventions and rules and object responsibilities.

Just recently, we spent some time converting our project to the SCSF. We had new developers coming on board and we didn't want the learning curve for CAB to slow them down. We saw value in them being able to execute a recipe, for instance, to create a MVP unit. Our application was 30+ project files, but only about 5 of them referenced CAB libraries. The process of converting what we had to make it compatable with the SCSF took about a day and a half for a single developer. The effort was worth it though - we can now use the SCSF and recipes to create core CAB components.

My suggestion would be not to wait for a SCSF if you choose to go the VB.NET route. If you need CAB now, then use it. Creating all of the objects by hand, and learning how they associated with each other will teach you a lot about the CAB, and then when the SCSF arrives it won't be a mystery to you. You'll know most of what it is doing.

To the language question though: not to be a C# zealot, but given the entirety of your situation I would recommend moving to C#. You would get the benefit of having a SCSF to work with right now, but also an additional bonus: C# is the language of choice for most .NET developers and that means that tools, 3rd party plug-ins and other tech will almost always be developed in C# first, and VB.NET second. If you're a C# shop you get the benefit of being first in line for almost everything.

When you go to conferences, summits or other technical .NET events, all of the examples will be in C#. When 3rd party folks develop open-source solutions for CAB, they will typically develop them in C# first. Being a C# shop gives you a leg up on just about everything.

The SCSF is a perfect example of the difference between C# and VB.NET: the C# version is out and people are using it. The VB.NET folks are having to wait. If you elect to be a VB.NET shop, I can guarentee that the SCSF won't be the last thing you have to wait for.

If your people know C# or can move to it quickly, then make the switch. I think a year down the road you'll be glad you did.

Jan 29, 2007 at 8:51 PM
We were in the same boat as you about 6 months ago. The path we decided to take was to have the core "Shell" team develop in C# using CAB and SCSF, while application development teams would use VB.NET to build their modules.

With the consistent delays of the VB.NET version of SCSF, we decided to go the route you mentioned in item 3. We created an initial 'template' module solution in C#, and converted it to VB.NET (using a mix of code converters and manual conversions). We also took on the larger task of creating VB.NET versions of the SCSF recipes as well as creating our own recipes. We accomplished this by modifying the SmartClientDevelopment guidance package. We left the guidance package itself in C#, but changed the T4 templates and other various pieces to output VB.NET code for our application developers to use (by using our template module that was converted to VB as a guideline).

We were worried in the beginning about the amount of time that Guidance Package conversion would take, but looking back on it now, it was a valuable experience to learn the inner workings of the GAT. We can now update and create new recipes utilizing complex custom wizards with relative ease.

However, I do agree with ChrisHolmes post above. If you have the chance at all to push through the switch to C#, go for it! We weren't able to go that route unfortunately.