Hamed wrote:
Hello
Every where in .NET books is mentioned that VS.NET is a seamless cross
platform environment. We have two groups of programmers that some are
VB programmer but others prefer to use C#. Is it possible to have a
project that accepts both kind of sources? I mean for example one
class is in VB.NET and the other in C#. Then one can trace or debug a
mixed code that switches between several languages code. In general
when I want to create a project, I should define the programming
language and then I can't add a source of a different language to it.
A single compiler will only compile code in a single language (the exception
is C++ *if* you consider C, C++ and managed C++ as different languages).
VS.NET projects are inherently single compiler - a project uses a single
compiler for all source files - thus projects can only be used to compile
source files of one language.
However, .NET IL is not language specific (I hate the term common language
runtime, because the runtime only JIT compiles and runs one language -
*Intermediate Language*). The problem is getting IL from different high
level languages into the same assembly. .NET has a solution in modules, but
VS.NET does not support this (well, for C# and VB.NET) because it does not
give you access to the appropriate command line switches. This means that
you have to use a makefile, and perhaps the VC++.NET makefile project is
your best approach here. The basic steps are:
1) create a module (use /t:module for both C# and VB.NET) for the source
files of each of the languages you use (ie one module for C#, one for
VB.NET)
2) create the assembly from the modules
a) for a 'VB.NET' assembly compile all .vb source files with vbc and add
the C# module with /addmodule, this gives you two files the assembly
manifest file (exe or dll) and the .netmodule, or
b) for a 'C#' assembly compile all .cs source files with csc and add the
VB.NET module with /addmodule, this gives you two files the assembly
manifest file (exe or dll) and the .netmodule, or
c) you can link the VB.NET and C# module with al.exe, , this gives you
three files the assembly manifest file (exe or dll) the C# and the VB.NET
..netmodules
3) Deploy all the modules in the assembly as one unit (even though
physically you may have more than one file in the assembly).
Note that 'public' and 'private' accessibility of a type does not apply
*within* the assembly, so one module can access the private (internal) types
in another module in the *same* assembly. However, the assembly exports
*all* of the public types exported from all of the modules.
A multimodule assembly does have memory advantages: if you put rarely-used
types in one module, that module will only be loaded when one of its types
is referenced, when the type is first used. If the rarely-used types are
never used in an execution of the assembly, the module is not loaded. When
you create a module and add it to an assembly, the compiler adds a hash of
the module to the assembly manifest file (assuming the assembly has a strong
name). When the module is load the runtime hashes the module and checks this
with the hash in the assembly manifest file. This ensures that the module
has not been tampered.
Of course, if you look at the framework you'll see that none of the
Microsoft assemblies are multimodule. I guess the reason is that under
Windows files are loaded into memory in chunks of page size (4096 bytes), a
multimodule assembly is likely to take up more memory than a single module
assembly, and the more modules you have , the more memory that will be
wasted. In general terms a process that is optimized for size will run
faster (due to less page swaps) than a process optimized for speed.
Richard
--
my email
ev******@zicf.bet is encrypted with ROT13 (
www.rot13.org)
sign up for my free .NET newsletter at
http://www.wd-mag.com/newsletters/ 
