IsolatedStorage question

[Guest]

I've been looking into the use of Isolated Storage and had a few questions:

1. If I use it in a MyIso.dll called by Iso1.exe, in storeadm /list I see
the assembly and domain sections both refer to the path to Iso1.exe. I
thought from my reading it would refer to MyIso.dll since that's what really
makes the Iso method calls. If I call it from Iso2.exe, or make a copy of
Iso1.exe somewhere else, it still shows paths to the respective exes (note
the dll is carried along in each of the directories).

2. I've read that if I want to share storage between apps I can sign
MyIso.dll with a strong name. Then no matter where it's loaded from it
points to the same storage. But in light of #1, wouldn't use of a
strong-named dll still result in separate references to the exes that use it?

3. If I'm strongly naming MyIso.dll, does it add anything to also install it
into the GAC? I'm guessing GAC-based dlls are physically only loaded once,
whereas non-GAC strongly-named MyIso.dll would load more than once but still
refer to the same Iso storage directory.

Thanks!

 

[Guest]

I figured out my 1st 2 problems. I'd been using the EntLib caching block,
which in turn uses isolated storage. I didn't realize under the covers it
was get a "store" by calling the GetUserStoreFromDomain() api call, which
always gives separate stores for 2 different exes. If I switched that to
GetUserStoreForAssembly() instead, AND have the EntLib be signed
(strong-named), then

a) storeadm /list shows only a single partition, and it refers to the dll
that uses the Iso apis, not the exe

b) The exe doesn't have to be signed, and if you have 2 exes that use the
signed EntLib from 2 different load locations, they both use the same
isostorage partition, which is what I was after.

Still not sure about the GAC - the above works whether the signed EntLib is
in the GAC or not, but I assume there's a performance gain if it's in the GAC
and used by multiple apps.