When there are multiple assemblies there are multiple singletons

  • Thread starter Thread starter 6tc1
  • Start date Start date
6

6tc1

Hi all, I'm having a problem where in my solution that contains
multiple projects - I instantiate a singleton class in one assembly and
then if another assembly tries to use that singleton class another
instance of it is created.

Basically:

--Assembly 1 (the executable)--
-Main.cs-

Singleton singleton = Singleton.Instance;
singleton.setValue("test");

--Assembly 2--
-Foo.cs-
Singleton singleton = Singleton.Instance;
String testing = singleton.getValue();
Console.Out.Writeline("test: "+testing);

The console outputs null because apparently two asseblies can't use the
singleton pattern in a cohesive manner?

Novice
 
Singleton should work across assemblies if they are in the same process. Is
your implementation correct? Make sure you are using static variables
correctly. Have you debugged your code?
 
This isn't completely true. Assuming the singletons are stored as
static variables, the singletons can be shared across the same app domain,
not across the process.

You could run multiple app domains in the same process, and each one
would have it's own copy of the static variable.
 
Are they *exactly* the same assembly? In particular, if they are strongly
named, then they must be *exactly* the same version, otherwise they count as
completely independent assemblies.

Marc
 
Can you elaborate on what you mean Marc? I think the problem may
actually does relate to the naming, specifically the namespace. I
tried using the same pattern in a very small program and the problem
didn't occur. I thought the problem might because I a bunch of
"using" statements and somehow the same class in one namespace is
actually getting compiled into two separate classes in compiled code -
therefore, perhaps the problem wouldn't have occured if I have fully
qualified the singleton class's name.

Thoughts?

Novice
 
It doesn't really relate to the namespaces, per se, unless you are using
reflection to create the objects by name...

If you are strongly-naming your assemblies (that is, you are signing them
with an SNK or PFX), then when you reference that assembly the reference
includes not only the assembly name (MyLibrary), but also the exact version
number and a hash-value of the SNK. In your source-code, it might say
"MyObject.StaticMethod()", but at runtime this is (essentially) "{MyObject
version 1.0.123.12315 signed by <hash>}.StaticMethod()".

If you re-build your library (either as a different version or with a
different SNK) and get another assembly in the AppDomain to reference the
new version, it could ask for "{MyObject version 1.0.324.23421 signed by
<hash>}.StaticMethod()}"; although they look similar, they are completely
different objects, and will not play well together; you would not, for
instance, be able to cast between them... Version policies in the GAC (if
you use GAC - personally I don't like to) can be used to say "if somebody
asks for 1.0.123.12315, then give them 1.0.324.23421 instead", but otherwise
you could get both in parallel... I think... maybe

Not sure if this *is* your issue, or even how much of this will happen in
reality... but the short of it is:

Objects are scoped by their assembly; strongly-named assemblies are
determined by their name, their full version, and their hash... If *any* of
these are different, you actually have 2 different objects.

Marc
 
Actually, I misunderstood your example - it is even easier, then:

My previous statement holds: "Objects are scoped by their assembly"...

If you have Assembly1.MyObject and Assembly2.MyObject, then it doesn't
matter if MyObject is the same source-code file, they are completely
unrelated objects at runtime... if anything in Assembly1 asks for MyObject
it gets its version (from Assembly1)... and if anything in Assembly2 asks
for MyObject it gets its local version (i.e. from Assembly2).

The solution is to use what I thought you were doing... you create a shared
assembly to host your singleton...

Create MyLibrary that contains MyObject, and reference this from both
Assembly1 and Assembly2... Now when either Assembly1 or Assembly2 attempt to
use MyObject, it gets the one from MyLibrary : presto, job done, go down pub
(or whatever)

I thought that you had already done this fundamental step, and that you were
still getting 2 versions... which would only be possible if Assembly1 and
Assembly2 were somehow using parallel versions of MyLibrary.

Let me know if this helps...

Marc
 
True. I sometimes use the terms "process" and "app domain" interchangeably.
A habit that I should break.


Nicholas Paldino said:
This isn't completely true. Assuming the singletons are stored as
static variables, the singletons can be shared across the same app domain,
not across the process.

You could run multiple app domains in the same process, and each one
would have it's own copy of the static variable.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter Rilling said:
Singleton should work across assemblies if they are in the same process.
Is your implementation correct? Make sure you are using static variables
correctly. Have you debugged your code?
Click to expand...
Click to expand...
 
I REALLY appreciate you taking the time to explain this - but I think
you may misunderstand (my fault no doubt). I don't actually have two
different Singleton classes in 2 different assemblies. My concern
stems from my experience with compilers and how qualified names
sometimes work in them.

Basically I had a concern that I had created a single cs file in one
project (creates a dll for that project) and this single class was
actually getting compiled into two separate managed classes in the
MSIL. Therefore, my theory was that when I used the Singleton class in
one project it would compile into a Library1.Singleton and in the other
project it woudl get General.Singleton.

Thoughts?

Thanks,
Novice
 
Back
Top