Allow multiple languages (C#,VB,F#) in the same project
Now with Roslyn this could be possible.
It's very annoying that you have to convert C# to VB just to include a class/function/snippet in your VB project, and viceversa.
If all code compiles to MSIL, then why we cannot use different NET languages in the same project.
Another example is a function in F#, you may want to use some functions that will simplify/improve your project (C#/VB) and it's better to do it in a functional language, but you don't want to code all your project in F#, nor want to create a separate project in F# with its DLL just to include a couple of functions/lines. We want to just Copy+Paste a few lines of F# code in a file inside your C#/VB project.
.NET is about interoperability, you can use other "compiled" (MSIL) code in your project no matter the language it was written, but doing the same at the CODE level will open a new world of possibilities.
Let Roslyn be used with the VB6 programming language.
And add support for VB6 programming too.
As it becomes ever more apparent that Microsoft is dropping first class language status for VB, it would make it much easier to convert to c# if existing vb source modules could be mixed in a project with new code in c#. I also agree with the other comments of the advantages of using the best language for a particular task. This should be one of the features a common target language provides. Thank you
Richard Kargher commented
Almost as good would be for a way that a project could "reference" a *.netmodule file. That would sidestep a lot of the IDE trickiness that Eric Butler pointed out. Making a *.netmodule is already a straightforward step, and maybe the option to make one alongside its analogue DLL could make this even simpler.
So what I'm envisioning is this:
1. Class (DLL) projects have an option to generate a .netmodule along with the usual DLL.
2. Other projects may then reference the DLL for purposes of development under the IDE. The IDE continues to build utilizing DLLs as is currently done.
3. With a separate tool (or perhaps activated by a setting within the IDE for a config named "Release"?), a final build could be made utilizing the solution file, project files, and whatever available .netmodule files (assumed to be located alongside their respective DLLs). The resulting DLL or EXE of this final build will not reference nor require any referenced DLL that has its respective .netmodule file available.
The only wrinkle I can see in this approach is what to do about Friend/internal members. Otherwise this seems quite workable without too much effort to make a go of it.
David Nuttall commented
Each compiler operates at the file level, so I would expect that you would not be able to put C# code and VB.Net code in the same file, but if set up properly in .cs and .vb files, with proper references, they could refer to each other inside the same project. In VS2015, a project is stuck with one language at a time. I can be multi-lingual, why can't my programming?
André Silva commented
They had promised this and VB/C# conversion inside VS for VS 2015, but it seems neither of them made it. I hope for at least an explanation from MS.
Eric Butler commented
I like the idea, and voted for it, however, dealing with project settings might be an issue. Consider in VB, there is currently no support for Unsafe, but in C# there is, except, you have to explicitly allow it in project settings. If this were to be implemented, then there would have to be sections defined for each language's specific settings. And probably many other things.
But I still love the idea and had cases before where I wished I could have done it without creating a separate project.