There's not a huge amount of difference between VB.NET and C#, and he'd
prefer to go the C# direction. By not a huge amount of difference, I mean
that VB.NET exposes you to a lot of the object oriented paradigm that you
used to be able to ignore, but in VB.net, you can't.
I could really care less which he uses. If he wants to learn C#, I'm all for
it. As long as the components interoperate and we can find programmers in
the future to maintain his code, should he decide to leave, I'm not real
concerned. Since the rest of the shop is C++, I'd kinda like him to be
moving towards C++, but C# is close enough that I'd easily be able to follow
his code. Also, the C++ coding standards we have will be easier to apply to
C# than VB.Net
----- Original Message -----
From: "Jonothon Ortiz" <jon@x...>
To: "Dotnet_Framework" <dotnet_framework@p...>
Sent: Tuesday, June 12, 2001 2:34 PM
Subject: [dotnet_framework] RE: Migrating to .NET
> If you have a VB programmer then I suggest you keep him working with
> It will have basically the same power and functionality that C# will have.
> Jonothon Ortiz
> Senior Web Developer
> Xnext, Inc.
> Ph: xxx.xxx.xxxx
> or 888.84.XNEXT
> -----Original Message-----
> From: Pete Davis [mailto:pdavis@q...]
> Sent: Tuesday, June 12, 2001 12:19 PM
> To: Dotnet_Framework
> Subject: [dotnet_framework] Migrating to .NET
> I have been busy completing a year long project, developing a system
> that's based on some 40+ COM+ components written in VC++.
> We have a VB programmer in the group who wants to get into C#. We all
> want to eventually migrate the existing components to .NET, even if we
> have to rewrite them from scratch. That's not such a big deal.
> My question is this: If we were to upgrade a few components at a time,
> would there be any issues involved? More accurately: If I write a .NET
> component in managed C++, if I expose the same interface and use the
> same GUIDs as the existing component, will the other components go on to
> use that component without a problem?
> Of course, the better path would probably be to create a new interface
> and do a numeric versioning of the interfaces, but if the interface
> isn't going to change, I'd rather just replace the component with a
> managed C++ version.
> Also, do .NET components work the same as far as pooling and that kind
> of stuff is concerned? Honestly, I don't know anything about the
> administration side of .NET. I've only read some of the literature on
> managed C++ and C#.