C# and VB.NET code in the same EXE

  • Thread starter Thread starter Nathan
  • Start date Start date
N

Nathan

I am working with a fellow developer on a small project. I started in
VB6, but after her C# training we decided to build the application in
..NET. Rather than rewrite the VB6 code, I continued in VB6 then
converted it to VB.NET using the upgrade wizard, while she started in
C#. The VB.NET project has one windows (UI) form an some intensive
background processing (a report engine) and the C# code has the rest
of the UI which updates an Access Database.

The problem is we thought we could put both projects into VS.NET at
the same time and build a single EXE - but we can't get it working!
The C# project will not pick up the VB.NET form, so when we try and
compile it says it doesn't know what the form is defined as - we have
tried adding a reference and a dependancy, but neither has worked. Is
it possible to build a single Windows EXE using both C# and VB.NET
code? If so, what would the C# code look like that opens the VB.NET
form, and what do we have to do to the C# project to get it to see the
objects defined in the VB.NET form??

If it's not possible, and we have to compile the VB.NET code into a
DLL, will the C# code still be able to open the form from the VB.NET
dll, or will we have to move the windows form into the C# project and
just leave the processing code (no UI) in the VB.NET dll??

Any help would be appreciated!
 
Nathan,

It is possible to have both VB.NET and C# code in the same assembly (EXE or
DLL) but you can't do it with Visual Studio, you have to use the command
line tools.

The easiest thing to do would be to make the VB.NET project into a DLL and
reference it in the C# app. There's no problem having forms or controls in
your DLL, .NET just treats them like any other class.

Hope this helps.
 
In short that may be the answer you are looking for. However, the longer
answer is that multifile assemblies don't really solve the common problem,
and that is shipping a single physical file that contains VB and C# code.
Using a multifile assembly you'll end up with a C# module file, a VB module
file, and an assembly that references both of these. All three files are
required to run the program. If you managed to instead create a VB library
assembly and simply reference that in your C# application, you'd only have
to ship two files.

There are obviously reasons for multifile assemblies, but until they make it
possible to merge all of the information into a single physical assembly, it
probably won't be much help.
 
Nathan said:
I agree that while the
multi-file assembly will work, the easiest way around our problem will
be to recode the VB.NET form into the C# project and have the UI in a
single project,
Click to expand...

One thing I found, when moving a VB.NET form to a C# form is to use the
designer. I created a blank form in C#, setup the properties (size, etc.)
to be identical to the VB form. Then, with both forms open in the designer,
just start selecting, copying and pasting the controls from VB over the C#.
This saved me about half of the typing (since it got all the placement,
properties, etc of the controls). For example, copying and pasting the
TabControl brought 5 tab-pages with probably 50 or so controls.

Then you just have to port over the event handlers (button click, etc) which
are hopefully pretty dumb little functions...

Good luck!
 
Back
Top