Mixing C# & Vb in the Same Project

Mixing C# & VB In The Same Project

No, you can't. An assembly/project (each project compiles to 1 assembly usually) has to be one language. However, you can use multiple assemblies, and each can be coded in a different language because they are all compiled to CIL.

It compiled fine and didn't complain because a VB.NET project will only actually compile the .vb files and a C# project will only actually compile the .cs files. It was ignoring the other ones, therefore you did not receive errors.

Edit: If you add a .vb file to a C# project, select the file in the Solution Explorer panel and then look at the Properties panel, you'll notice that the Build Action is 'Content', not 'Compile'. It is treated as a simple text file and doesn't even get embedded in the compiled assembly as a binary resource.

Edit: With asp.net websites you may add c# web user control to vb.net website

Why is mixing VB.Net and C# in the same solution not recommended?

There is no real reason to avoid this, other than adding complexity from having two languages in one "solution".

Your scenario (working with a legacy product, but adding new features) is a valid reason to have both languages used in a single solution, in my opinion.

Mixing VB.Net and C# Code in an ASP.Net Web Site project?

From http://msdn.microsoft.com/en-us/library/t990ks23.aspx:

Multiple Programming Languages in the App_Code Folder

Because the source code in the App_Code folder is compiled into a single assembly, all the files in the App_Code folder must be in the same programming language. For example, the App_Code folder cannot include source code in both Visual Basic and C#.

However, you can configure your Web application to treat subfolders of the App_Code folder as separate compilable units. Each folder can then contain source code in a different programming language. The configuration is specified by creating a codeSubDirectories element in the compilation element of the Web.config file and adding a reference to the subfolder. The following example illustrates how you would configure subfolders named VBCode and CSCode to compile into separate assemblies:

<compilation debug="false">
    <codeSubDirectories>
        <add directoryName="VBCode" />
        <add directoryName="CSCode" />
    </codeSubDirectories>
</compilation>

The references to the VBCode and CSCode subfolders do not need to include any information about what programming language is contained in the subfolder. As with the App_Code folder itself, ASP.NET infers the compiler to use based on the files in the subfolder.

How to include a VB project in a C# Solution

I added a VB console application

And why would you think that that was a good idea, given that step 4 specifically refers to a VB Class Library Project? If you are told that you need a Class Library project, add a Class Library project. The screenshot even names the project "VBClassLibrary"/

Dealing with C# and VB.net Projects in same solution

There is nothing you are doing wrong here. This is an unfortunte side effect of how Visual Studio is designed. When you have two projects in different languages a reference between them does not behave like a project reference but instead resembles a file reference.

Project to Project references of the same language share a single language service. Hence it is in control of all of it's code and can provide special live content benefits. The primary one being the goto definition and instant intellisense. There is just no facility in Visual Studio today to allow language services to communicate with each other across the reference boundary like you desire.

Mixing C# and VB.Net in ASP.Net error

There is a duplicate 'system.web.extensions/scripting/scriptResourceHandler' section defined message will appear if you're trying to run a .NET 3.5 project in .NET 4.x application pool, since machine.config of .NET 4.x already has scriptResourceHandler section (you can check in %Windir%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config):

<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
    <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

        <!-- this section causing duplicate error for .NET 3.5 projects -->
        <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
        ...
    </sectionGroup>
</sectionGroup>

Also if you're checking web.config in the same directory as machine.config, the ScriptResourceHandler is already registered there:

<httpHandlers>
    ...

    <!-- this handler is already registered in .NET 4.x default web.config -->
    <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="False"/>

    ...
</httpHandlers>

FYI, I found that configSections element on .NET 3.5 projects has scriptResourceHandler section like this:

<configSections>
    <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
      <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
        <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
        <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
          <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="Everywhere" />
          <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
          <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
          <section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
        </sectionGroup>
      </sectionGroup>
   </sectionGroup>
</configSections>

Try remove duplicated scriptResourceHandler section in configSections marked with version 3.5.0.0 above and try to build again, or if you don't want to upgrade the project just change IIS application pool to use version 2.0 instead.

NB: I tried to create a new MVC project from template in VS 2010 using .NET 3.5 and found that both C# & VB are available as compiler language="c#;cs;csharp" & compiler language="vb;vbs;visualbasic;vbscript".

References:

MSDN Blog: There is a duplicate scriptResourceHandler section defined

IIS7 deployment - duplicate 'system.web.extensions/scripting/scriptResourceHandler' section

Using C# and VB.NET in one solution

Yes, you can't mix languages within the same project, but you can add as many projects written in different languages as you like, to the same solution. (This is sometimes very useful, especially when it comes to having portions written in C++/CLI, which are able to do things which would be impossible to do in C#/VB.NET.)

Mixing VB.net code with c# code

Your DLL is not a C# DLL, it's a .NET DLL. Once compiled, all you have is IL - doesn't matter what language it came from. Should be no problem, unless you encounter one of the odd edge cases where the DLL's interface includes something that is not supported by Visual Basic. But this would be very much an edge case.

The Common Language Specification, or CLS, defines the subset of .NET features that must be supported by a .NET language, and if your DLL is CLS compliant, then you can use it with no problems. If you are confused about the difference between the CLS, CTS, CLR etc, then I found the coverage of it in this book very helpful, though it is primarily a C# book.

---

Related Topics