Thanks for the reply Ian. I took a step back to an "Hello World" example and all was well with that.
The reason my actual code was failing is related to our use of a plugin architecture based upon SharpDevelop. The plugin assembly contained all the code and is required to be present in a plugins directory. Remoting expects the implementation to be in the bin or the GAC, so I had also copied the plugin to the bin (against DRY rules). The plugin loaded the implementation from it's assembly and the remote call got it's implementation from the bin. The CLR I guess does what it does and inits the statics on a per assembly basis. This has also caused us problems with interface casting. Simple refactoring into smaller assemblies and proper deployment sorted out the problem, I could also have used the GAC for the original version of the assembly I guess. We live and learn. Norman Burkies System Engineer High Integrity Solutions Ltd 7 Romsey Industrial Estate Great Bridge Road Romsey, Hampshire SO51 0HR United Kingdom Tel: +44 1794 525622 (Direct) +44 1794 525610 (Switchboard) Fax: +44 1794 525611 email: [EMAIL PROTECTED] IMPORTANT NOTICE: Information contained in this correspondence is proprietary to High Integrity Solutions, Ltd. (HIS). This information is intended only for the recipient. By reading and retaining this correspondence, recipient agrees to hold the information in confidence and shall not use the information for other than the intent stated or implied in the correspondence. This information shall not be copied or otherwise distributed to others without the express and prior written permission of HIS. Unauthorized disclosure could cause irrecoverable commercial harm to HIS. Transmission of this information is in commercial confidence and does not provide a right to use to any party. -----Original Message----- From: Griffiths, Ian [mailto:[EMAIL PROTECTED] Sent: 10 February 2004 19:55 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Appdomain Singleton classes and access from Remoted method Can I see the code you're using for the singleton? I've written remoting-based applications that do exactly what I think you're describing. I have a remoting façade class which uses SingleCall, and this then accesses a singleton object. It is, as you say, a fairly common thing to want to do. I've never had any problems with it. If extra singletons are getting created, then the first thing to look at would be whatever code you are using to implement the singleton pattern. -- Ian Griffiths - DevelopMentor (RSS: http://www.interact-sw.co.uk/iangblog/rss2.0 ) > -----Original Message----- > From: Norman Burkies > > I have a problem which would normally be simple to solve (DCOM C++) > but is causing me grief when attempting an implementation with .NET, > C# and Remoting). > > Simply put I have a service (or just a console host) which scans some > sensors and stores the data in a singleton object (based on the > example in the Microsoft Enterprise Solution Patterns document - I > have tried them all). I am attempting to use the same service > (console) to host a .NET remote interface which provides application > access to this data. Note I am not attempting to remote the singleton > I just wan't to access it from both the internal threads and the > runtime remoting thread hosting the remote method call. > > Multiple internal threads can synchronise with and access the > singleton normally, however the remote access SingleCall methods do > not 'see' the same singleton. The runtime appears to create a new > instance of the singleton (new static data) on first access (I can see > the contructor being called). The remote object method instance and > the internal service threads appear to be executing within the same > AppDomain. > > Is this an impossible solution? Is there something else I should know > about (Contexts maybe). > > This must be a fairly common thing to want to do say implementing an > in memory global sesion cache for instance. =================================== This list is hosted by DevelopMentor® http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
