Re: Creating directories on Vista machines using .NET

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi guys,

Thanks for your answers.

Pete: The Access database definitely isn’t opened elsewhere. I run the
installer on a clean VM Ware virtual machine and kick if off for the first
time. The test code only connects to the database when the test button is
clicked, so there’s no way it could be opened elsewhere. As Jeffery points
out, the “All Users” folder you recommended isn’t available to a standard
user. Point taken about the World not needing another application installed
in a non-conventional way. However, my boss would rather have an application
installed in a non-conventional way than not at all! I will endeavour to find
a more standard solution, but if I can’t, it’s going to be the root directory
solution.

All: Sorry for the confusion regarding the documents and settings folder not
being on Vista. I actually decided to perform my virtual tests on XP for now,
since, as has been pointed out, the same security problems exist on XP and
Vista (and probably older operating systems too). Ultimately, I require a
solution that works for all operating systems that support .NET. I will be
running the tests on my virtual Vista machine too.

Jeffrey: I do definitely need the database in the Access database to be
common to all users (i.e. not duplicated) and editable by all users. I think
I’ve explained this above. There are many reasons for this, one being: If
user A creates data, user B needs to be able to view and edit that data as
well. For instance, if user A enters a product key to unlock features, a list
of these unlocked features is stored in the Access database (encrypted and
tamper-proof!). When user B logs on, they must also be able to access the
features unlocked by A without re-entering the product key. As I say, there
are many other reasons why we need to have a single shared writable data
store, due to the nature of our product. We’ve made the data access layer
that interacts with Access database completely thread safe, since it is
possible that two or more threads operating within the UI may try to use the
Access database at the same time, so we’ve no worries there. It is worth
noting that the data in the database can (and will) change at any time, and
so using a .NET config file is not an option, and we can’t go with an
in-memory solution (and write to data store later) since the volume of data
we’re storing is too large for this. (By the way, we’re not actually writing
a game; I’ve been referring to games because they generally do the same thing
we’re trying to achieve.)

Pete: It is also not viable to have the shared data edited under
Administrator rights, and then have users on read-only access. Many of our
customers have small office setups, and contract their IT functions out to
third parties. Office based staff do not generally have access to
administrator passwords (since they are not trusted!), and so they would have
to get their IT providers to make a site visit every time they wanted to
change the data in the database. Depending on the contract, each visit could
be costly. Even if we only stored features in the database, it would
discourage users for purchasing new features if they had to get their IT out
every time they needed to enter a new product key! As I’ve mentioned though,
the Access database also contains data created by users as they use the
product, and it is not uncommon for a hundred or so records to be created or
edited each time the product is used.

We have no other alternative to using a shared Access database, so can we
take that as a given from now on? (Of course, I’d be interested to hear about
other solutions, but we can’t escape the fact that we need a shared, writable
data store.)

I like the idea of writing a Windows Service to act as a shared data
manager, although I think this is overkill for what we need to do. I’m
guessing that adding a Windows Service to our application would cause us
issues further down the line, since our users install the product themselves
from a CD. I dread to think what sort of installation issues they might
encounter! Am I being over pessimistic here?

The idea of keeping the Access database near the root of C:\ is a nice
compromise: keep the code secure in Program Files, and only reduce the
security on items that need to be shared. Pete: How could I install the
Access database to the “Application Data” folder at install time AND ensure
that all users can access this directory? Is it possible to alter directory
permissions at install time using the .NET installer?

Apologies for my naivety here; I do appreciate your time in helping me.

Cheers,

Steve.


"Peter Duniho" wrote:

On Tue, 15 May 2007 20:33:41 -0700, "Jeffrey Tan[MSFT]"
<jetan@xxxxxxxxxxxxxxxxxxxx> wrote:

Yes, normal user does not have write permission to the "All Users"
directory, so this error is expected. I have original pointed this out in
the last reply of link below:
http://www.thescripts.com/forum/thread638856.html

Sorry...you're right. I must have gotten the general "All Users"
permissions mixed up with the "Documents" folder under that one (which
does default to being open to all members of the "Users" group).

Still, the application's setup program could create a special folder under
"Application Data" that does have the "Users" permissions set to including
writing. IMHO, this is a better solution that creating a new directory at
the root level of the drive, and should still be applicable under Vista (I
have limited experience there, but it's my recollection that it still has
a general "all users" sort of directory somewhere).

I still think it's not a great idea to have users generally sharing data.
It seems to me that allowing one user to modify data used by another user
is a security issue, as well as simply being a usability issue. If there
are data that need to be configured for all users, that data should be
configured by an administrator. For example, installing license keys that
unlock functionality, or downloading data that enables or supports some
features. Once an administrator has done these operations, then all users
can take advantage of them having only read access to it.

Pete

.

Relevant Pages

  • Re: Creating directories on Vista machines using .NET
    ... One thing that the Access database does is maintain settings relating to the ... dialog box asking which account to run the install under. ... even if I run the install using administrator rights, ...
    (microsoft.public.dotnet.framework)
  • RE: About ADOCE3.1 installing on PPC 2003
    ... is included in SDK. ... Please note that you should have ADOCE 31 SDK, Pocket PC SDK 2002 and Pocket ... I think that with adoce you can access to Sql Server or MS Access database, ... > Who can tell me how to install it and access Oracle Lite by ADOCE? ...
    (microsoft.public.windowsce.embedded.vc)
  • VS2005 - Installer ?
    ... I've built a fairly simple program; has a small access database with the ... usual add/change/delete functions. ... the deploy wizard to build a setup file & tried to install on an W2003 ... sure if it was needed or not) I added all the namespaces that the project ...
    (microsoft.public.vstudio.development)
  • VS2005 - deployment / installer ?
    ... I've built a fairly simple VBnet program; has a small access database with ... usual add/change/delete functions. ... the deploy wizard to build a setup file & tried to install on an W2003 ... sure if it was needed or not) I added all the namespaces that the project ...
    (microsoft.public.vsnet.debugging)
  • Install/Start Up Error
    ... I tried to install on a computer running Windows 2000, ... received an "Error 1919: Error Configuring ODBC data ... source: MS Access Database, ... project using our default Project Guide, ot you can retry ...
    (microsoft.public.project)