>
>I use C# for the middle tier of my .NET apps (I built a tool to generate all the data access and data manipulation C# class code for the SQL Server databases used in my solutions).
>
>For the front-end, I prefer VB.NET - so that I can leverage (at least to some extent) the last three years of using VB6 almost exclusively in my development projects.
>

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