469,609 Members | 1,721 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,609 developers. It's quick & easy.

Isolated Storage bug at design time

Hello,

We use several user controls and derived custom controls. Some of
which actually hit the database at design time to show data (such as
filling a list box, etc...)

Our c# client server app uses the .NET Isolated storage libraries for
storing connection string and other info about the application. The
problem is that the Isolated storage bombs at design time (when you
try and view a control that hits the database at design time).

The workaround we have in place is the Isolated storage check is in a
try / catch. If it fails, we load a hard-coded xml file with the same
settings at a specified path that never changes... which defeats the
whole purpose of Isolated Storage.

This isn't a huge issue cuz it only happens at design time and we have
a (hackish) workaround, but I was wondering if anyone has had this
problem and/or knows why it would be happening?

Thanks,
Dave
Nov 16 '05 #1
1 1786
IsolatedStorage is based around evidence and it is possible that the
IsolatedStorageScope you are using isn't getting the appropriate
evidence in order to find your path.

If you are basing anything off of AppDomain or Application evidence
then there is a big chance of error when running in a design-time
environment.

Rather than finding fault in the isolated storage API try to examine why
you need to store credentials at design-time. You can make use of
design-time only properties or other features that were meant for this
operation instead.

--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"malcolm" <ch********@yahoo.com> wrote in message
news:4f**************************@posting.google.c om...
Hello,

We use several user controls and derived custom controls. Some of
which actually hit the database at design time to show data (such as
filling a list box, etc...)

Our c# client server app uses the .NET Isolated storage libraries for
storing connection string and other info about the application. The
problem is that the Isolated storage bombs at design time (when you
try and view a control that hits the database at design time).

The workaround we have in place is the Isolated storage check is in a
try / catch. If it fails, we load a hard-coded xml file with the same
settings at a specified path that never changes... which defeats the
whole purpose of Isolated Storage.

This isn't a huge issue cuz it only happens at design time and we have
a (hackish) workaround, but I was wondering if anyone has had this
problem and/or knows why it would be happening?

Thanks,
Dave

Nov 16 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.