Having Assembly entrypoint in DLL library

[Guest]

I use two classes to manage the Main() command line (and alot of other stuff)
for my prototyping environment.

I tryed putting the MainClass in a DLL and just having the other class
(which gets modified on a per project basis) as the 'program.cs' file (the
only *.cs file).

I keep getting 'Main() not defined error' even though it was defined via the
DLL reference in the project.

Has anyone created a 'rapid development' environment where the Main()
entrypoint
is NOT in any *.cs file for a console application?

 

[vj]

I am not sure if this sounds alright.. How can you have a entry point in a
project or file other than the main executable or Dll file?

VJ

 

[Guest]

Simple example - A 'Simple Assembly Platform'.

The 'Platform' decouples the 'Static side effects' of a static Main() entry
point.
So using a singleton pattern as the 'platform driver' (which contains
main()) you
instantiate an 'Assembly Platform' class.

The Main() routine then 'enters' the 'Instance entrypoint()' (no static side
effects).

Use case : I'm a developer. I can 'turn over' the assembly platform as a
'new object class' (ie. just a normal C#class) by just dropping the
'platform' it inherits.
The utility is my 'new class' only has 'static stuff' that is meant to be
static VS being forced to be static from the static Main().

The real gain is using a GOF command pattern based assembly platform (not
the simple platform described above).

With a 'Command Platform' (for rapid development) you just need to define a
command line lexicon and an command execution unit. The lexicon is processed
by the command line processor which binds the command on the command line to
the delegate driven execution unit.

The 'rapid development' point is error logging, exception processing,
command line processing, etc is done by the 'Assembly Platform'. This
'platform' can then be dropped (via dropping the inheritance) and directly
'tied' to the execution unit (a class) as a 'execution unit driver'
(basically a client class).

Furthermore by replacing the inherited platform with a new 'EOP' (Event
Observer Pattern) client interface the 'execution unit driver' can be
automatically bound to the execution unit by a framework specific binder
(class).

In summation the context of an 'Assembly Platform' allows you contain the
main entry point and provide a complete component (ie. assembly)
infrastructure that is library (DLL) based.

On final compile the DLL platform library can be statically replicated in
each component that comes off the line. I would prefer the components thus
generated all shared a single copy of the 'Assembly platform' INCLUDING the
entry point.

So we make a compromise and statically link in the 'platform entry point' (A
DLL) and this in turn brings in (via inheritance) the rest of the 'Assembly
Platform' via your standard shared DLL.

So, I may have chose a poor term for the 'Platform entry point' compiled
module. Perhaps I should have said 'platform entry point' (A static LIB) that
gets compiled into the final component (assembly). The static LIB contains
the Main().

I tryed some approaches to do this but ran into problems when
referencing/linking the static LIB 'Platform entry point' into the VS.NET
2005 project.

Thanks for your response as my answer helps me to articulate the problem
(hopefully) a little better.

 

[Guest]

By the way.

The 'execution unit' is what you are really working on.

The command line processing and everything else just lets you drive you
execution unit as if it was a DOS utility.

Then you drive/test/play the execution unit using XML config and batch files.

This complements the unit test envrionment as well as reusing a standardized
component infrastructure (error logging, exception processing).

Finally a variety of assembly platforms exist (stratified on complexity) so
you just avoid 'redoing' stuff (like top level exception catching or command
line processing).