Here's one for the gurus

  • Thread starter Thread starter Gary Morris
  • Start date Start date
G

Gary Morris

Hello all,

I've thought about this for a while, but can't seem
to find any examples OR explanations, so I'm just
gonna throw it out there.

I know that .NET allows for the use of multiple
programming languages, and I know all about how
to, say, write a .dll in C# and then use it in a VB.NET
application by referencing it in the project (or from
the command line compiler). What I am wondering
is, is there a way to use multiple languages and then
compile them all into the same assembly as
embedded entities?

Say I had two programmers working on a project.
One is good with C# and the other just cannot get
C# at all and insists on using VB. Once the two have
written their respective classes, etc., and the project
is ready to be compiled, can everything be put into
one assembly WITHOUT referencing anything?
After looking around, I have not come across
anything that looks like it will work, or maybe I am
just missing it altogether. If this is not clear, here is
what I mean:

I have One.cs and Two.cs

Now, I can just use "csc One.cs Two.cs" and make
one assembly that does not necessarily rely on any
other assembly (except normal System.* and such).

What if I have One.cs and Two.vb? Is there any way
to compile these two together like the above?

The only way I can think of is to give the two the same
namespace, compile both with their respective
compiler, and then use ILDASM to dump them both.
After that, I could just ILASM the two together and I
have actually done that. I'm just hoping that this is
not the only way. Surely MS didn't do THAT to us, did
they?
 
I'm not exactly sure what you're asking here, but if I'm getting the part
about "One.cs" and Two.vb" maybe creating modules instead of assemblies will
help. Look in the .NET reference for "Multifile Assembly Example". I think
..netmodules are what you're looking for. The only problem is that Visual
Studio does not support this type of output so you'll have to build from the
command line or use something like nAnt.

Still, the "way of .NET" is to create lots of little assemblies that
encapsulate functionality. So I don't see why it's a big deal to just
compile the VB code and the C# code into their corresponding assemblies? If
you have dependency issues you might want to create a third assembly with
interfaces and reference that instead of having the two implementation
assemblies depend on each other.
 
In traditional programming environments, you would compile both something
like a.cs and b.vb into a.obj and b.obj (.obj is an "object module"), and
then "link" them together into a single executable.

The current .Net toolset doesn't quite allow this. You can "fake it", just
as you outline, by doing something like compiling a.cs and b.vb, and then
using a disassembler to disassemble them to .il code, and then using an
assembler to assemble and link them both together into an executable.
That's kind of kludgy, but it definitely works.

In Whidbey, I believe the plan is to allow the .Net "linker" (which I think
is al.exe - I don't use it much) to (optionally) statically link .netmodule
files together, instead of just the current model where an executable is
built that has a reference to the .netmodule, and requires the .netmodule as
a separate file. So Whidbey will directly support what you are talking
about.

--Don
 
Thanks, fellows,

That pretty much tells me what I wanted to know. I have fooled around with
the .netmodules, at first thinking that these were intended to be embedded
into an assembly at compile time, but soon found that not to be the case.

As for al.exe, I haven't really done much with it (yet), though it looks
like it
can accomplish what I'm after.

I'm not really averse to using referenced assemblies, in fact they are
indispensable with a large project. I was just thinking of what could happen
in an environment where C#, VB, JS, and even Delphi.net were being used
to create a project. Sure, it might be just as easy to assign the C# guy all
of the code for a single assembly instead of trying to tie an assembly
together from multiple languages, but there might be a situation where this
would not be feasible. In that case, I would hope that there would be a way
to compile the assembly using code from two or more languages, and now
I know that there is, it's just not as convenient as using one compiler.
 
Back
Top