How does isolated storage do its magic?

  • Thread starter Thread starter Elder Hyde
  • Start date Start date
E

Elder Hyde

For you .NET gurus out there,

Any ideas how isolated storage does its isolation magic? It is quite
smart, it does the things you'd expect it to do. I'm interested in
knowing how they do this!

For instance:

1. If you put your isolated storage code in a dll, it knows that it is
being called from an .exe, so it takes into account the identity of this
calling assembly, and create a unique path for the files accordingly. I
gather we can simulate this using a hash of
Assembly.GetCallingAssembly(). Still no biggie.

2. However, if you put your isolated storage code in a dll, which in
turn is called from another dll, which, again, in turn is called from an
..exe, it also does this correctly. This is still OK, maybe we can use
Assembly.GetEntryAssembly() to get the identity of the .exe.

3. But... in ASP.NET, GetEntryAssembly() returns NULL, so if they had
used it, it wouldn't have worked. Let's say we have a WebApplication,
which calls a function in a DLL, which calls your isolated storage code
in another DLL. How do you get that WebApplication identity?
GetCallingAssembly gives you the second DLL. GetEntryAssembly() returns
null.

After thinking about it, I think they must be doing this recursively.
That is, from your isolated storage code's assembly, trace the callchain
back all the way to the "entry" assembly. So if we have, say, 4 DLLs
called one after another by an .exe, the directory structure will be
something like:

- EXE name (probably hashed)
- DLL1 name
- DLL2 name
- DLL3 name
- DLL4 name

But now I'm getting confused :) What if, say, there are TWO different
functions containing isolated storage code? One in DLL2, the other in
DLL4? If we go by the scheme I was thinking about, the IsolatedStorage
files location for those two will be different. Which may not be what
one would expect--one would expect that for that one .EXE, every
isolated storage data will be stored in one unique location.

So how do they work this magic out? I've been thinking about it for
hours now :)

Thanks in advance for any ideas and suggestions!
Elder.
 
Rotor's implementation can be found in
sscli\clr\src\bcl\system\io\isolatedstorage\ and in
sscli\clr\src\vm\comisolatedstorage.cpp and .h. The IsolatedStorageScope
enum in sscli\clr\src\bcl\system\io\isolatedstorage\isolatedstorage.cs is a
good place to start.

Barry
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks Barry!

One question though: I noticed that by default, projects in vs.net has
the revision number incremented everytime you do a build (even if you
don't change anything). This has the consequence of the FullName of the
assembly being different for every rebuild.

Now, although Isolated Storage does the expected thing (that is, it
still refers to the same set of unique directory names, instead of
generating a new one just because the revision changes), doesn't it mean
that, strictly speaking, it is not isolation by assembly anymore?
Because the moment the FullName changes, it *is* a different assembly,
is it not? So it must be leaving some information out during the
generation of this unique directory names. Any ideas? (I saw some
Evidence being used.. wonder how they're using them. We'll see.)

Very interesting, thanks! :)

Elder
 
The MSDN topic titled "Types of Isolation"
(ms-help://MS.MSDNQTR.2003FEB.1033/cpguide/html/cpcontypesofisolation.htm)
talks about how "assembly identity" works. In particular,

"Assembly identity is the evidence of the assembly. This might come from a
cryptographic digital signature, which can be the assembly's strong name,
the software publisher of the assembly, or its URL identity. If an assembly
has both a strong name and a software publisher identity, then the software
publisher identity is used. If the assembly comes from the Internet and is
unsigned, the URL identity is used. For more information about assemblies
and strong names, see Programming with Assemblies. "

So if your vs.net project isn't strongname signed, the full version number
doesn't appear to be used.

Barry
 
Elder said:
Thanks Barry!

One question though: I noticed that by default, projects in vs.net has
the revision number incremented everytime you do a build (even if you
don't change anything). This has the consequence of the FullName of
the assembly being different for every rebuild.
Click to expand...

You'll find lots of references -- both MSFT and external -- to people pointing
out this is a bad default for a number of reasons, mostly similar to what
you've seen.
 
Back
Top