Exception using Isolated Storage in ASP.NET on a hosted server

  • Thread starter Thread starter Rick
  • Start date Start date
R

Rick

I had assumed that Isolated Storage was the thing to use in a hosted
environment. My code to do so works fine on servers where I have full
access. I'm getting the following exception on the hosted environment:

System.IO.DirectoryNotFoundException: Could not find a part of the path
"*". at System.IO.__Error.WinIOError(Int32 errorCode, String str) at
System.IO.IsolatedStorage.IsolatedStorageFile.GetFileDirectoryNames(String
path, String msg, Boolean file) at
System.IO.IsolatedStorage.IsolatedStorageFile.GetRandomDirectory(String
rootDir, Boolean& bMigrateNeeded, String& sOldStoreLocation) at
System.IO.IsolatedStorage.IsolatedStorageFile.InitGlobalsNonRoaming(IsolatedStorageScope
scope) at
System.IO.IsolatedStorage.IsolatedStorageFile.GetRootDir(IsolatedStorageScope
scope) at
System.IO.IsolatedStorage.IsolatedStorageFile.GetGlobalFileIOPerm(IsolatedStorageScope
scope) at
System.IO.IsolatedStorage.IsolatedStorageFile.Init(IsolatedStorageScope
scope) at
System.IO.IsolatedStorage.IsolatedStorageFile.GetStore(IsolatedStorageScope
scope, Type domainEvidenceType, Type assemblyEvidenceType) at
System.IO.IsolatedStorage.IsolatedStorageFile.GetUserStoreForDomain()
at AcronymService.Acronym.LoadAcronymsDocument() in
C:\Projects\AcronymService\Acronym.asmx.vb:line 565 at
AcronymService.Acronym.GetAcronymsDocument() in
C:\Projects\AcronymService\Acronym.asmx.vb:line 529 at
AcronymService.Acronym.GetAcronymsVersion() in
C:\Projects\AcronymService\Acronym.asmx.vb:line 190



This happens regardless of whether I use Assembly or Domain as the
basis:

Dim IsolatedFile As IsolatedStorageFile

IsolatedFile = IsolatedStorageFile.GetUserStoreForAssembly
or -
IsolatedFile = IsolatedStorageFile.GetUserStoreForDomain

Any ideas?
 
I'm not sure what exactly is causing your error, but I wouldn't recommend
using isolated storage from ASP.NET, much less on a hosted server.

Isolated storage works on a per-identity and per-assembly basis. So you're
using the store allocated to the identity under which your web application
is running, usually the ASPNET account (on W2K) or NETWORK SERVICE (XP and
2003).

Isolated storage is better suited for rich client applications. Try using a
database for this. I'll admit there are scenarios where you could
theoretically use the technology from a web app, but these are the exception
and not the rule.

The MSDN docs identify "persistent web application storage" as a solution to
normal I/O restrictions; however in your hosted scenario you're stepping on
everyone's toes =) Also, you need specific permissions and a quota enabled
by an administrator on the server to use this successfully, something that
few shared hosting providers are going to do nowadays.
 
Thanks for the insight! It would still seem that this should be
workable, especially for small amounts of data. If my hosting service
won't support it, I guess I can move to a database, or a configurable
persistence storage mechanism. At least one server to which I would like
to deploy my application has a SQL Server db to which I have access. A
second server doesn't, although I could add one. But, certainly, the use
of isolated storage to persist a relatively small amount of data (~100K)
seems reasonable.

You say I could be stepping on other applications. Does the Assembly
store pertain to the ASP.NET assembly, or my own assembly? If the
(shared) ASP.NET assembly, I agree that some coordination mechanism with
other users would be needed. If my assembly, then I see no problem other
than disk quota.

Regards - Rick.
 
I'm in exactly the same boat...I have working software, deployed on Windows
2003 without SP1, using IsolatedStorage, that is accessed by a web
application. I've confirmed that "something" in Windows 2003 SP1 has broken
the ability for exactly the same code to operate successfully. As you
suggested, I will be changing future code to use an alternate storage method.
However, I really need to make my existing code be able to run on SP1. If we
(Rick and I) knew what security/trust/permission had to be tweaked to correct
the problem, it sure would make life easier.
 
Back
Top