Develop Reference

combine c# class and vb.net classes

I am using asp.net 2012 and have c# class project where I would like to include some existing vb.net classes.
What would be the best way to be able to use both c# and vb.net classes?

Either convert the vb.net classes into C# or put the vb.net classes into their own assembly and add a reference to the assembly.

put the VB.NET classes in a project of its own and then reference that project, just as you would any third party control.

As already mentioned, one of the alternatives is to convert c# to vb.net or vice-versa.
You can find many pages in the internet to do that, like these ones:
http://www.developerfusion.com/tools/convert/vb-to-csharp/
http://www.developerfusion.com/tools/convert/csharp-to-vb/
If you convert the code from one language to the other make sure you test the changes properly.
If you decide to keep VB.NET code in a separate Visual Studio project and reference it in the C# code you need to ensure that the VB.NET code is CLS compliant. This is a good starting point:
Writing CLS-Compliant Code
See also:
Cross-Language Interoperability

Make C# a .NET library and include it in your VB.NET/ASP.NET project.
Follow this http://msdn.microsoft.com/en-us/library/t990ks23.aspx for more info...

Why are Visual Studio projects restricted to a single language?

This is question is inspired by the question: In what areas does F# make "absolute no sense in using"?
In theory, it should be possible to use any .NET supported language in a single project. Since every thing should be compiled into IL code, then linked into a single assembly.
Some benefits would include the ability to use say F# for one class, where F# is more suited to implement it's function, and C# for another.
Is there some technical limitation I'm overlooking that prevents this sort of setup?

A project is restricted to a single language because, under the hood, a project is not much more than an MSBuild script which calls one of the command-line compilers to produce an assembly from the various source code files "contained" in the project folder. There is a different compiler for each language (CSC.exe is for example the one for C#), and what each project has to do to turn its "contained" source code into an assembly differs with each language.
To allow multiple languages to be compiled into a single assembly, the project would basically have to produce an assembly for each language, then IL-Merge them. This is costly, requires complex automation and project file code generation, and in most circumstances it's a pretty fringe need, so the VS team simply didn't build it in.

While projects are restricted to a single language, a solution is not... and solutions can contain multiple projects.

As others mentioned, a project is a stand-alone unit that is compiled by a single compiler.
I hear the question about including e.g. one F# type in a larger C# project quite often, so I'll add some details from the F# specific point of view. There are quite a few technical problems that would make it really difficult to mix F# and C# in one project:
C# compiler sees all classes, while F# type declarations are order-dependent. I'm not sure how would you even specify what types should the F# code see at which point.
F# compiler needs to know how declarations are used in order to infer types. Would it also get usage information from the C# compiler?
The two compilers use different representation of types. When compiling, there are no System.Type information, so how would they share the information? (Both of them would need to agree on some common interface that allows them to include language-specific information - and the information may be also incomplete).
I think this is enough to explain that doing this is not just a feature that may or may not be done depending on the schedule. It is actually an interesting research problem.

For what it's worth, it's possible to have ASP.NET projects that use C# and VB.NET (or anything else, you define the compilers in web.config), just in different files.

All code files are processed by a single compiler. That's why a project can only contain a single language.
Mixing languages may not make much sense either, since each language generates it's own IL.
This of course doesn't restrict you form having multiple projects from different langauges in the same solution, since each project is compiled independently

Consider using ILMerge if you want to maintain a single .exe or .dll built by a number of different compilers.

Technically, you can mix languages in a single project, if one (or more) of those languages are scripting languages. See How to use Microsoft.Scripting.Hosting? for more details.
I know this isn't what you were talking about, but it's a little fun fact if you weren't aware.

The project file is nothing but an elevated list of command line parameters to the relevant compiler. A file with the extension of .csproj contains the parameters for a C# compiler, .vbproj for the VB.NET compiler and so on.
You can however create two or more projects in the same solution file, one for each language and then link them together in one exe file using ILMerge.

Possible to combine C#.net, VB.net and ASP.net?

I want to build a website in ASP.net, and to integrate a module which is written in C#(too complicated to rewrite in VB or ASP).
Now I just want to know whether it is possible to have a website that integrates all three?
Thank you.

Yes. You can have a WebSite integrating all three.
Just make your complicated C# a .NET library and include it in your VB.NET/ASP.NET project.

I think you only have to reference the dll's from your modules which are written in c# or VB to call your public functions. I've done this in a windows form application and it worked fine.

You may also want to consider simply learning C#. Most of what you know from VB.NET is directly usable in C#, since most work involves using framework classes and the languages share most features.
It is mostly a matter of syntactic preference, and while a new syntax may sting your eyes for a bit the learning curve will be steep and soon you will have left your old preferences behind.

You have a couple of options when integrating languages in ASP.NET. If you're creating a "web site" (as opposed to a "web application" which can use only one language) then each page can use a specified language, because essentially each page is compiled separately. Some can use VB, some can use C#. No problem.
However, what you describe sounds even simpler. You claim that there is an existing C# module which you want to use in your VB website. Is this module compiled into its own assembly? If that's the case then the language that was used to create the assembly is immaterial. Once it's compiled, it's a .NET assembly and can be referenced by any .NET language. It's no longer a matter of VB vs. C# (or any other language) once it's compiled.
If it's not a compiled assembly, but rather a bunch of class files, can it be compiled as its own assembly? That's generally good for keeping things modular. Within a single .NET solution you can have each project use different languages without problem. This module can be a library project written in C# and your site can be a web site (or web application) project written in VB, which references the library project.

Since all these assemblies ultimatly use the same CLR (hence the name Common Language Runtime), they can be used together with no problem.

Converting a C# class library to C++ on Red Hat Linux

We have developed a C# class library on VS 2008. We want the same functionality as a C++ library on Red Hat Linux. How do we accomplish that?
I am sure we are not the first to migrate C# to C++. Are there any automated tools to convert the source code?
We know about Mono, but we would very much prefer C++ source code.
About 15% is the useful code, the rest 85% are unit tests using NUnit.
At the very least we do want to migrate all the unit tests as source code.
We used Reflector, which did almost all the work for us. The only thing it screwed up were constructors.
Consider the following C# code:
public MyClass() : this(1,2,3){}
it should be converted to
public MyClass() : {this(1,2,3);}
but Reflector converted it to
public MyClass() : {MyClass(1,2,3);}

um, are you asking for a general-purpose c# to c++ code converter that also switches platforms?
No problem, it's called a human, and you can hire or contract one from many different locations.
You may also want to look at the Mono Project, which has a fully functional c# compiler and .net runtime for various other platforms (including RH Linux). This way you would not need to recode the library into c++, although you may need to change the code in small ways if you're using things that mono does not support.

You can get a head start by first converting to C++/CLI (the .NET flavor of C++). Red Gate's .NET Reflector supports conversions between .NET languages (you need a plugin to decompile to C++/CLI) and there are other tools as well.

I don't think there's any way to automatically translate C# to C++, if that's what you're asking, so I don't think you could get the C++ you want without manually writing it. Maybe you can use the C# itself instead via Mono...?

Unfortunately, I'm not aware of any such tool. However, translation from C# to C++ should be easier than C++ to C#. The features C# supports but C++ doesn't (say, reflection, and defined behavior in certain cases -- like order of evaluation) is much smaller and easier to work around than the features C++ has but C# doesn't (looking at just C++ templates, you have template functions with the ability to deduce type arguments, passing compile-time constants as template arguments, partial template specialization, complete template specialization, CRTP, substitution failure is not an error, etc.).

Is there a particular reason you prefer C++ in RHEL ? If not Mono is a better solution.

IronPython vs. C# for small-scale projects

I currently use Python for most of my programming projects (mainly rapid development of small programs and prototypes). I'd like to invest time in learning a language that gives me the flexibility to use various Microsoft tools and APIs whenever the opportunity arises. I'm trying to decide between IronPython and C#. Since Python is my favorite programming language (mainly because of its conciseness and clean syntax), IronPython sounds like the ideal option. Yet after reading about it a little bit I have several questions.
For those of you who have used IronPython, does it ever become unclear where classic Python ends and .NET begins? For example, there appears to be significant overlap in functionality between the .NET libraries and the Python standard library, so when I need to do string operations or parse XML, I'm unclear which library I'm supposed to use. Also, I'm unclear when I'm supposed to use Python versus .NET data types in my code. For example, which of the following would I be using in my code?
d = {}
or
d = System.Collections.Hashtable()
(By the way, it seems that if I do a lot of things like the latter I might lose some of the conciseness, which is why I favor Python in the first place.)
Another issue is that a number of Microsoft's developer tools, such as .NET CF and Xbox XNA, are not available in IronPython. Are there more situations where IronPython wouldn't give me the full reach of C#?

I've built a large-scale application in IronPython bound with C#.
It's almost completely seamless. The only things missing in IronPython from the true "python" feel are the C-based libraries (gotta use .NET for those) and IDLE.
The language interacts with other .NET languages like a dream... Specifically if you embed the interpreter and bind variables by reference.
By the way, a hash in IronPython is declared:
d = {}
Just be aware that it's actually an IronPython.Dict object, and not a C# dictionary. That said, the conversions often work invisibly if you pass it to a .NET class, and if you need to convert explicitly, there are built-ins that do it just fine.
All in all, an awesome language to use with .NET, if you have reason to.
Just a word of advice: Avoid the Visual Studio IronPython IDE like the plague. I found the automatic line completions screwed up on indentation, between spaces and tabs. Now -that- is a difficult-to-trace bug inserted into code.

I'd suggest taking a look at Boo [http://boo.codehaus.org/], a .NET-based language with a syntax inspired by Python, but which provides the full range of .NET 3.5 functionality.
IronPython is great for using .NET-centric libraries -- but it isn't well-suited to creating them due to underlying differences in how the languages do typing. As Boo does inference-based typing at compile time except where duck typing is explicitly requested (or a specific type is given by the user), it lets you build .NET-centric libraries easily usable from C# (and other languages') code, which IronPython isn't suitable for; also, as it has to do less introspection at runtime, Boo compiles to faster code.