Home All Groups Group Topic Archive Search About
Author
8 Jun 2009 10:19 AM
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

Author
8 Jun 2009 2:18 PM
Mike
Denis wrote:
> 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?

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.

--
Author
8 Jun 2009 2:37 PM
Mike
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.

--


Mike wrote:
Show quoteHide quote
> Denis wrote:
>> 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?
>
> 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.
>
> --
>
Author
9 Jun 2009 4:52 AM
James Hahn
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

Show quoteHide quote
"Denis" <spamcontainer@yahoo.com> wrote in message
news:SA5Xl.18292$1s6.630@twister2.libero.it...
> 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
>
Author
9 Jun 2009 5:50 AM
Michel Posseth [MCP]
MS has introduced a new term for the same beast WCF   ( Windows Comunication
Foundation )
so investigate both Remoting and WCF


HTH

Michel



Show quoteHide quote
"James Hahn" <jh***@yahoo.com> schreef in bericht
news:%23uAmR4L6JHA.1380@TK2MSFTNGP05.phx.gbl...
> 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
>
> "Denis" <spamcontainer@yahoo.com> wrote in message
> news:SA5Xl.18292$1s6.630@twister2.libero.it...
>> 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
>>
>