General dot net questions.

[Ken Varn]

I have a couple questions/comments concerning dot net and the future of dot
net development. If someone could address these, please do so.

First of all, with the advent of .net and the use of namespaces, why can't I
reference a public class that is contained in an EXE from another EXE? It
seems that the only way to access other classes from other process is
through a DLL. In comparison to Java, where all compiled code goes into a
..class file, .net still keeps the separation of DLL and EXE. Why not
eliminate the EXE and DLL connotation and simply have a compiled output file
that can assume either role? i.e., Compiled modules have a new .NET
extension which can either function in the DLL or EXE role.

Next, when building code I have to decide whether to create a managed C++
project, C# project, or VB Project. None of the project types are
interchangeable. i.e., I cannot add C++ modules to a C# project unless they
are in a DLL. Why not just have the ability to create a .net project that
supports modules that can be any of the supported languages, thus allowing
compilation to be intermixed in projects? I should be able to have a
project that contains both C# and C++ source files and have the compiler do
the compilation as necessary.

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.
va***@diebold.com
-----------------------------------

[Jon Skeet]

Ken Varn <va***@diebold.com> wrote:

I have a couple questions/comments concerning dot net and the future of dot
net development. If someone could address these, please do so.

First of all, with the advent of .net and the use of namespaces, why can't I
reference a public class that is contained in an EXE from another EXE?
You can - just not with Visual Studio .NET :(
It seems that the only way to access other classes from other process is
through a DLL. In comparison to Java, where all compiled code goes into a
.class file, .net still keeps the separation of DLL and EXE. Why not
eliminate the EXE and DLL connotation and simply have a compiled output file
that can assume either role? i.e., Compiled modules have a new .NET
extension which can either function in the DLL or EXE role.
Yes, that would be nice - and would also mean it wouldn't need things
like a DOS header etc, which are really relics. On the other hand, we'd
then need a new loader which new about them...
Next, when building code I have to decide whether to create a managed C++
project, C# project, or VB Project. None of the project types are
interchangeable. i.e., I cannot add C++ modules to a C# project unless they
are in a DLL. Why not just have the ability to create a .net project that
supports modules that can be any of the supported languages, thus allowing
compilation to be intermixed in projects? I should be able to have a
project that contains both C# and C++ source files and have the compiler do
the compilation as necessary.

I think that would probably be a bad idea from a maintenance point of
view, but again you can do it with the command line compiler using an
assembly of many modules. That probably means you can do it with NAnt
too...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Guinness Mann]

In article <eN**************@TK2MSFTNGP12.phx.gbl>, va***@diebold.com
says...

I have a couple questions/comments concerning dot net and the future of dot
net development. If someone could address these, please do so.

First of all, with the advent of .net and the use of namespaces, why can't I
reference a public class that is contained in an EXE from another EXE? It
seems that the only way to access other classes from other process is
through a DLL. In comparison to Java, where all compiled code goes into a
.class file, .net still keeps the separation of DLL and EXE. Why not
eliminate the EXE and DLL connotation and simply have a compiled output file
that can assume either role? i.e., Compiled modules have a new .NET
extension which can either function in the DLL or EXE role.

Next, when building code I have to decide whether to create a managed C++
project, C# project, or VB Project. None of the project types are
interchangeable. i.e., I cannot add C++ modules to a C# project unless they
are in a DLL. Why not just have the ability to create a .net project that
supports modules that can be any of the supported languages, thus allowing
compilation to be intermixed in projects? I should be able to have a
project that contains both C# and C++ source files and have the compiler do
the compilation as necessary.

I don't know about you, but when I write software I first concentrate on
getting it to work in a special case. Then I generalize it. Then I
refactor and consider expanding the scope.

I suspect that's what is going on here. I would be surprised if all
your wishes weren't realized over the next few years.

-- Rick