|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Shared AssemblyHi 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 wrote:
> Hi all, In general Windows EXE/DLL architecture, this is done using a shared > 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? 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. -- Show quoteHide quoteMike wrote: > 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. > > -- > 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 > 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 >> >
My.Settings Questions
Too many items in listbox? RichTextBox Text Popup Odd problem with Me.Hide() and Me.Visible = False Enable/Disable Checkboxes based on Parent Check value? Accessing oledb reader without moving to next record GotFocus event never fires for form Screen Resolution 4 Killer Ways To Make $30,000 Per Month |
|||||||||||||||||||||||