Shared Assembly

  • Thread starter Thread starter Denis
  • Start date Start date
D

Denis

Hi all,
I have the problem to share a dll to 2 different executables.
Every executable ha a reference to the same dll but I need to access to the
same shared objects but it seem that every executable instantiate a
different memory space for the dll .
How can I have a dll in one signle instanced and used by the 2 executables?

Thank you, Denis
 
Denis said:
Hi all,
I have the problem to share a dll to 2 different executables.
Every executable ha a reference to the same dll but I need to access to the
same shared objects but it seem that every executable instantiate a
different memory space for the dll .
How can I have a dll in one signle instanced and used by the 2 executables?
Click to expand...

In general Windows EXE/DLL architecture, this is done using a shared
memory map or you compile the same RDATA segement. I don't see library
reference to Memory Maps wrapping the WIN32 functions:

CreateFileMapping()
MapViewOfFile()

However, I am confident .NET is using maps behind the scene. :-)

In OOPS-like compiled languages, you use classes to wrap the data in
the DLL and then expose the class to the EXE. In VB.NET, use
properties, methods, etc in the DLL class to access the common
storage/shared memory logic.

Example:

Public Class MyDLLClass
Private m_data As Integer
Public Property data() As Integer
Get
Return m_data
End Get
Set(ByVal value As Integer)
m_data = value
End Set
End Property
End Class

The trick is to initialize m_data to the common storage. The general
coding practice is that this is passed from the EXE to the DLL but it
doesn't have to be. The DLL itself can be self contained.

--
 
PS: Keep in mind that when you share resources between two EXE via a
DLL, you MUST have synchronization. Generally, a ReaderWriter logic
suffices in these cases and check for VB.NET reader/writer class or
anything that wraps this fundamental concept.

It would be easy to implement depending on how it works:

Public Class MyDLLClass
Private m_data As Integer
Public Property data() As Integer
Get
LOCK_ALL_WRITING_ALLOW_READING()
Return m_data
End Get
Set(ByVal value As Integer)
LOCK_ALL_WRITING_AND_READING()
m_data = value
End Set
End Property
End Class

Now, the different in other Oops classes, is the local scope concept.
Once the Get/Set logic exits, the unlocking is done automatially. So
in VB.NET you either have to UNLOCK yourself or maybe use the Using
IDisposable wrapper:

Get
dim i as object = m_data
Using LOCK_ALL_WRITING_ALLOW_READING()
i = m_data
end using
return i
End Get
Set(ByVal value As Integer)
using LOCK_ALL_WRITING_AND_READING()
m_data = value
end using
End Set

IDisposable allows for inherit automatic destruction and the VB.NET
"lock" class implements idisposable then it makes it easy to do a
local scope concept.

--
 
If you invoke a DLL from the EXE then the objects of that DLL will be
exclusive to that EXE. .NET pretty much enforces this separation as part of
the security package.

However, if you run a server application that invokes the DLL, that
application can make its objects available to other applications, and that
includes, of course, objects derived from the DLL.

The terminology relevant to this process is remoting and singleton. Remoting
allows an application to access an object that actually exists outside the
application domain. In your case this will be an application domain in
another process on the same machine. Singleton refers to a type of object
which exists as a single instance to process all calls from all clients.

See, for instance:
http://msdn.microsoft.com/en-us/library/ms973857.aspx
http://www.codeproject.com/KB/IP/dotnetremotingbasictutor.aspx
http://www.dotnet247.com/247reference/System/Runtime/Remoting/Channels/Tcp/TcpChannel.aspx
 
MS has introduced a new term for the same beast WCF ( Windows Comunication
Foundation )
so investigate both Remoting and WCF


HTH

Michel
 
Back
Top