Linking to a .NET dll from C#

[Bob Bryan]

I am trying to find out if its possible to do the following from C#:

1. Determine if a certain managed .NET dll or assembly is loaded into memory
or not. If not, then load it.

2. If the dll is already loaded, then get a reference to it so that its
members can be called directly. The apps that will be using the dll already
knows all the methods.

3. There are several apps (exes) that will be using the dll and I'm
wondering if there is a way to dynamically link to a specific dll that is
already in memory and get back a reference (or pointer) that will be just as
fast as if each app had used static linking.

Can this be done, if so an example or link would be appreciated.

 

[Cor Ligthert[MVP]]

Bob,

Has this any goal, I did this when memory in Dos was limited to 640Kb (and
there was absolute nothing more for a program despite all kinds of extended
memory possibilities)

But now I don't see any reason anymore for that.

I am curious why you want this.

Cor

 

[Bob Bryan]

Cor,

The application is for a destination gateway that a client is using for
obtaining price quotes and performance is absolutely critical. The users of
this data will all be on the same computer per the client's request (trust
me on this issue - I am aware that other price servers usually use a socket
connection to communicate price updates to clients on other machines). I
suppose another way to do it would be to use shared memory or memory mapped
files.

In the past when using VC++, I believe we used COM and called CreateInstance
on the object which would return a pointer to the object and then method
calls were very efficient - like makiing a virtual method call in C++. This
was many years ago though so I'm a little rusty and don't remember if we
used a different technique to actually link to an existing dll or not. The
question is - can something like this be done in a managed .NET language
like C#, and if so what is the best way? Should we consider using com
interop for this? Thought com was dead...

Bob

 

[Cor Ligthert[MVP]]

Bob,

Why not simply an ASP.Net application?

Be aware that a simple Net exe does mostly not take much bytes because a lot
is in the Framework.

Cor

 

[Jesse Houwing]

Hello Bob,

Cor,

The application is for a destination gateway that a client is using
for obtaining price quotes and performance is absolutely critical.
The users of this data will all be on the same computer per the
client's request (trust me on this issue - I am aware that other price
servers usually use a socket connection to communicate price updates
to clients on other machines). I suppose another way to do it would
be to use shared memory or memory mapped files.

In the past when using VC++, I believe we used COM and called
CreateInstance on the object which would return a pointer to the
object and then method calls were very efficient - like makiing a
virtual method call in C++. This was many years ago though so I'm a
little rusty and don't remember if we used a different technique to
actually link to an existing dll or not. The question is - can
something like this be done in a managed .NET language like C#, and if
so what is the best way? Should we consider using com interop for
this? Thought com was dead...

Though I believe you're looking for a little extra performance that has no
real merit here, there are a few things to consider.
1) Place the shared assembly in the GAC, so that all apps will share the
same binary
2) Use pre-compilation to create native images of these assemblies

If you want only one instance live at any time, you could host this 'layer'
so you want in a service and use WCF through a local transport (named pipes
or net.tcp) in combination with binary serialization. It would mimic the
COM solution, but at the same time would be an all .NET way to go.

If these machines you're working on are Vista or newer, you could use the
Host Activation Service to make the hosting of the WCF library a little simpler.

Lastly, there are tools out there (like XenoCode Postbuild) that allow you
to actually statically link any assemblies and merge them into the application.
These tools will sometimes even allow you to link the whole framework with
your application. Be aware that in these scenarios you're responsible for
patching and updates, as the application will no longer rely on the clients
machine to keep the framework up to date.

Hope this helps,

Jesse

 

[Bob Bryan]

Why not simply an ASP.Net application?

I want something that is very efficient and very fast. I'm not sure how
using an ASP.Net app would apply... In any case, I have come up with a
better solution. Instead of having multiple exes using a single dll
assembly that provides functions and some shared data, why not have several
dll assemblies be incorporated into one exe? Very efficient and much easier
to implement. Although, there are some advantages to having multiple exes
and the client might still want this approach. So, I'm still interested to
see if anyone knows a way to access a single dll assembly that is already in
memory from multiple exes that is just as fast, or not much slower than
using a reference from static linking.