Hi Morgan,

In my case I'm a one-man shop. Having a VB.NET project and a C# project in the same solution works perfectly fine for me. Writing the application using both C# and VB allows me to become proficient in both - which for me is a good thing.

I'm now finding that some clients are now specifying which language they want the apps built in - having experience using both puts me in a good position.

>Al, I understand that you have a lot of VB6 development projects to leverage, but I don't see why anyone would want to have 2 or 3 languages that an application is built on. I mean, .NET gives you that option and it is great, but I see the option main benefit, if I'm in a crunch I can bring any VB.NET, C# or C++ .NET developer to whip out something for me. But, on a whole, for what Thomas was asking I don't see that as a necessarily good option. I mean, if you are going to use C# to develop the middle tier, why not go further and get the "power" of C++. I mean, it seems like it invites disaster, I mean your VB.NET, C# applications can't reuse the same code, unless you put the "reused" code in a different assembly and have them share that. I mean, it is great the .NET allows for this flexiblity, and if there were a good VB.NET control or component that would fit into an application you are writing in C#, it would be great. But, to have two standards of languages it seems like it
>is more work then necessary, I mean your architects have to have "production" level knowledge of both, and know the ins and outs of both languages. If you want to pull develops from Middle-tier to front-end because you need more front end resources for some reason, not only do they have get familiar with the front-end, but they have to brush up on VB.NET. I mean, knowing a language is one thing, but "developing" in a language is much different.
>
>I think it adds another level to have problems at.
>
>Morgan