Keeping C# and VB.NET Libraries the Same

Jun 26, 2007 at 1:10 AM
Since the initial 1.0 release of the Toolkit, many additions have been made to the source. Some of them merely optimizations and bug-fixes, but even more have added features and extended the API. With many of the check-ins so far, updates for the C# and VB.NET libraries are not synchronized, thus creating differences in the APIs, and possibly delaying others' work. I'll admit that I am guilty of this, but I'm not the only one, and I think it should be addressed.

Perhaps it's necessary to impose some formal/informal guidelines that must be met before a check-in can occur. This could include testing the library to make sure it doesn't break anything. There should also be stipulations on API changes, including keeping the two libraries together, and ensuring backwards-compatibility.

I've also wondered why it's necessary to have two separate libraries at all. The beauty of .NET is that it all compiles down to similar CLI code, and the same assemblies can be used in C# and VB.NET. It appears so far that most of the developers are at least comfortable with C# -- why not depreciate the VB.NET library and instead provide instruction for using the C# assemblies?

Perhaps neither of these suggestions are the right solution, but I think we should at least address the issue.
Jun 26, 2007 at 2:59 PM
Good point.

We definitely thought it would be tough to keep vb project in synch as time goes on. But, made the original commitment to keep both languages. I agree that it is not totally necessary, as even vb users can just as easily use the c# version. But, since Microsoft sponsored this project they really like to have both versions to show how it can be done in either language.

Up til now I have tried to keep the vb source in synch with csharp. As, I don't think it is realistic to ask all contributing programmers to program in both languages. But, I have not had a chance to port the latest (very major changes to vb). I plan to do that in the next couple of days.

I do think the only real safe solution is to deprecate c#, or at least inform users who are getting code directly from the source tree, that the vb is not necessarily up to date.

But for now, I would like to try to keep the vb source alive, and I will take on the task of porting the changes that both you and koroglu have made.