Instead of mysterious "merging" (ever tried to define formally what is that?), you should better use the civilized way, the way it is supposed to be used in .NET.Strictly speaking, there is another approach: using executable modules without manifests. You could write them in different language and put in one assembly. You would have, say, two executable files (each representing a module), only one of them representing the assembly. The problem is that Visual Studio does not support multiple modules in a single assembly, so you would need a custom project files and other hassles. Why, if you can use different assemblies?
Use you C# application, the one you want to reuse in your other application, as a class library assembly. You may need to re-work it to be usable: abstract out some too concrete stuff, make the methods, properties and events you need to use from outside assembly public, and get rid of the entry point (you static
Main method) and other redundancies. However, if you don't do this last step, the solution will work anyway, but it will appear contaminated with your legacy stuff. You don't even need to rename you assembly from .EXE to .DLL — for .NET, this is totally insignificant. From the standpoint of the OS user, however, it's better to rename, to avoid accidental attempts to "run" this assembly as application. However, this danger is also not very significant.
And then, reference this assembly in your VB.NET application and use. The using code would be absolutely identical to the code if the C# code would be written in the same assembly.
Don't even think about a single-assembly solution. It makes no sense at all.
Also, please understand that Visual Studio supports only the assemblies written in different languages, so using more than one assemblies is a must.