[This is the advanced follow-up answer in response to Solution 1 and Solution 2]
Strictly speaking, the statement "you can't mix C# and VB.NET in one project" is not correct at all. It is quite possible, but may be impractical and overly complicated. So, for all practical purposes, it's much better to develop code using multiple projects each using a single language and producing a single assembly, each assembly represented in a single executable module. This is just not the most general case.
Now, as I say that "you can't…" statement is wrong, I need to explain how mixing languages in one project is possible. Yes, it is possible. There are two key facts to it:
#1:
It depends on what is called a "project". If it is created by Visual Studio in a standard manner, this is one thing. But, strictly speaking, "project" is something written using the MSBuilt project XML schema and valid semantically. Every one can write such project in a custom way and even develop custom "Tasks" implementing required BSBuild interfaces (
http://msdn.microsoft.com/en-us/library/ms171466.aspx[
^],
http://msdn.microsoft.com/en-us/library/t9883dzc.aspx[
^]). In particular, a custom task can make direct use of C#, VB.NET or any other compiler to use
additional features of them, not presently used by Visual Studio; also the custom project can simply use those compilers directly though the command line — there is a standard task to execute any application and pass a command line parameter line to it, so one can
also use those additional compiler features.
Now, we are coming to the second fact: what "feature" will allow to use more then one language in the same project? But before we discuss it, I want to mentioned yet another opportunity to formally overcome the limitation "single language per project".
As the project can be custom, the nature of the project can be made different from what is used in Visual Studio. In other words, in particular, a project can play a role of the solution and still produce one language per assembly each composed on one executable module, but produce more then one assembly each written in its own language. The difference is just formal: the result is the same as with solution, only under the umbrella of a single project. This is something which is used by some, usually called a "superproject". For example, for the sake of automatic build and support of complex system I personally uses a superproject integrated several solution, each solution actually used as a separate "view" on the code base.
Now, coming back to "additional feature" not used by Visual Studio:
#2:
Visual Studio only supports the special-case simple model where each assembly is just one file. But — look at Reflection — an assembly is composed of executable modules, and each module is not an assembly. So, this model is a model using one executable module per assembly. If one uses a compiler in a custom way, this developer can use a more general feature each compiler is obliged to implement, to be compatible with CLI requirements: creation of separate executable modules (but not assemblies, each such module is a separate filesl the modules can not be executed by themselves in a general case) and adding existing module to assembly. This way, each module could be written in a different language, a single assembly could be produced by a single project, but such project could use different languages. This is what was required to proof.
I hope I've finally clarified this tricky subject.
—SA