Very troubling problems running on Vista Beta

[Dan]

If this is the wrong NG to post this please point me to the correct place...

I've had a few people try my VB app on Vista Beta installations. One of the
problems I'm seeing is that my app can't seem to write information to the
installation folder. Yet no error is being raised when it tries to write
out information. As far as the app is concerned there's no problem. I
noticed this when people who tested the app couldn't find the app's log
file. When they send me directory listings of everything in the
installation folder it was clear that there was nothing present that wasn't
put there by the installation utility.

This really has me troubled. I don't have a Vista Beta installation of my
own to test with. My app writes both a log file and the user's data file to
the installation folder by default. Not only that, my app frequently needs
to be updated. I handle this through a utility that downloads the newer
..exe and deletes the old. If it can't download and write out the new .exe
then my app can't be updated! I can handle (though not be happy with) the
need to write both the log and data file to the \Documents and
Settings\(user name)\Application Data\ folder if Microsoft forces me to do
so. But if the app can't be updated I'm really in a world of hurt.

Has anyone else encountered this problem? Anyone know why an app would not
be allowed to write data to its installation folder yet not get an error
from Vista when it isn't allowed to do so?

 

[Andre Da Costa [Extended64]]

This is really a developer issue, its best if you post it at the following
link:
http://forums.microsoft.com/msdn/showforum.aspx?forumid=120&siteid=1
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta

 

[Chris Altmann]

It could be related to File (and Registry) Virtualization.

Quote from
http://windowsconnected.com/blogs/jerry/archive/2005/12/19/86.aspx :

When an application attempts to do something "bad" like write to an INI file
like "C:\Program Files\PoorlyBehavedApp\Options.ini", Windows will detect
that the user's token does not grant them access to save to that location.
Instead, it will copy the existing file (if it already exists) to
"C:\Users\<your_account>\AppData\Local\VirtualStore\Program
Files\PoorlyBehavedApp\Options.ini". It will then allow the write operation
to succeed to this new file in the VirtualStore folder. Subsequent read
operations for that file will always preferentially use the copy in the
VirtualStore. Here's a simplified flow chart outlining these read and write
operations.

 

[Andre Da Costa [Extended64]]

Hopefully though, someone might have an answer here, so stick around, Zack
might be able to help.
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta

 

[Steve Foster [SBS MVP]]

If this is the wrong NG to post this please point me to the correct
place...

I've had a few people try my VB app on Vista Beta installations. One of
the problems I'm seeing is that my app can't seem to write information to
the installation folder. Yet no error is being raised when it tries to
write out information. As far as the app is concerned there's no problem.
I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.

This really has me troubled. I don't have a Vista Beta installation of my
own to test with. My app writes both a log file and the user's data file
to the installation folder by default. Not only that, my app frequently
needs to be updated. I handle this through a utility that downloads the
newer .exe and deletes the old. If it can't download and write out the
new .exe then my app can't be updated! I can handle (though not be happy
with) the need to write both the log and data file to the \Documents and
Settings\(user name)\Application Data\ folder if Microsoft forces me to
do so. But if the app can't be updated I'm really in a world of hurt.

Has anyone else encountered this problem? Anyone know why an app would
not be allowed to write data to its installation folder yet not get an
error from Vista when it isn't allowed to do so?

Vista has mechanisms to automatically redirect writes to an application
folder to a folder within the user's own space. So you should find the log
files have been auto-relocated to somewhere deep within \Users\<username>.

I don't know about application updates - but I imagine that MS have
something in place for this scenario too.

It's all part of the UAP/LUA stuff - since users generally should not be
running with administrative privileges, they don't have the right to write
to an application's own folder, ergo an application loaded by them has the
same restriction.

 

[Dan]

This is really a developer issue, its best if you post it at the following
link:
http://forums.microsoft.com/msdn/showforum.aspx?forumid=120&siteid=1

Thank you for the link!

 

[Zack Whittaker \(R2 Mentor\)]

I don't know about application updates - but I imagine that MS have

something in place for this scenario too.

You can do this using Visual Studio 2005, and the "Publish" settings of your
application. You can configure your applications to look on a web server to
download the latest build of your product - it's really easy to set up, and
with Windows Server 2003 running with IIS, work's an absolute treat.

It's all part of the UAP/LUA stuff - since users generally should not be
running with administrative privileges, they don't have the right to write
to an application's own folder, ergo an application loaded by them has the
same restriction.

Couldn't have said it better myself ) So yeh, if you can get TechNet or
TechNet Plus, you can then get yourself a copy of Vista to test with. If you
check out the UAP Guidelines,
http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx -
you might find that useful.

All the best )

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: http://msblog.resdev.net
» ZackNET Forum: www.zacknet.co.uk/forum
» VistaBase: www.zacknet.co.uk/vistabase
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, mother or cat. Let's be clear on that one!


--- Original message follows ---

 

[Andre Da Costa [Extended64]]

Is it that thing called Click Once? I remember Microsoft pushing it a lot at
PDC 2003.
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta

I don't know about application updates - but I imagine that MS have
something in place for this scenario too.

You can do this using Visual Studio 2005, and the "Publish" settings of
your application. You can configure your applications to look on a web
server to download the latest build of your product - it's really easy to
set up, and with Windows Server 2003 running with IIS, work's an absolute
treat.

It's all part of the UAP/LUA stuff - since users generally should not be
running with administrative privileges, they don't have the right to
write to an application's own folder, ergo an application loaded by them
has the same restriction.

Couldn't have said it better myself ) So yeh, if you can get TechNet or
TechNet Plus, you can then get yourself a copy of Vista to test with. If
you check out the UAP Guidelines,
http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx -
you might find that useful.

All the best )

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: http://msblog.resdev.net
» ZackNET Forum: www.zacknet.co.uk/forum
» VistaBase: www.zacknet.co.uk/vistabase
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and
not
of my employer, best friend, mother or cat. Let's be clear on that one!


--- Original message follows ---

 

[Randy Birch]

Vista has mechanisms to automatically redirect writes to an application
folder to a folder within the user's own space. So you should find the log
files have been auto-relocated to somewhere deep within \Users\<username>.



I sure hope this can be disabled - what a stupid idea.

--

Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/

Please reply to the newsgroups so all can participate.

 

[Dan]

It's all part of the UAP/LUA stuff - since users generally should not be
running with administrative privileges, they don't have the right to write
to an application's own folder, ergo an application loaded by them has the
same restriction.

Oh yes, we can't let applications write to their own folder. Why if we let
them do that... Actually, I don't see much reason why that should be a
problem. Frankly, I don't see how it makes the system more secure. Just
more difficult for developers like me. Sigh...

 

[Dan]

You can do this using Visual Studio 2005, and the "Publish" settings of
your application. You can configure your applications to look on a web
server to download the latest build of your product - it's really easy to
set up, and with Windows Server 2003 running with IIS, work's an absolute
treat.

Unfortunately I'm not developing with .NET. But how does this help even if
I were? Are you saying the "publish" settings of my .NET app causes Vista
to allow it access to write to the installation folder?

Couldn't have said it better myself ) So yeh, if you can get TechNet or
TechNet Plus, you can then get yourself a copy of Vista to test with.

Unfortunately, I don't have a spare PC to install it to. I guess I'll have
to cough up the money for a new development machine just to test Vista on.

check out the UAP Guidelines,
http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx -
you might find that useful.

Thanks! I'll have a look.

 

[Dan]

Vista has mechanisms to automatically redirect writes to an application
folder to a folder within the user's own space. So you should find the log
files have been auto-relocated to somewhere deep within \Users\<username>.

I sure hope this can be disabled - what a stupid idea.

Which is stupid? The idea of turning it off or the idea that it needs to be
turned off? I honestly don't see how allowing an application that the user
installed to write to the installation folder is a problem.

 

[Randy Birch]

I honestly don't see how allowing an application that the user

installed to write to the installation folder is a problem.

Exactly. My remark was aimed at the concept that the OS would prevent an
installed app from writing to its own folder, ini file or whatever, and
transparently relocate that file to another location.

--

Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/

Please reply to the newsgroups so all can participate.

 

[Zack Whittaker \(R2 Mentor\)]

Kinda yeh... I didn't want to say it because it's not directly that as
such... but weaves into it yeh.

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: http://msblog.resdev.net
» ZackNET Forum: www.zacknet.co.uk/forum
» VistaBase: www.zacknet.co.uk/vistabase
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, mother or cat. Let's be clear on that one!


--- Original message follows ---

Is it that thing called Click Once? I remember Microsoft pushing it a lot
at PDC 2003.
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta

 

[Zack Whittaker \(R2 Mentor\)]

Well, it depends on what you're devloping in. Most software building
applications have an "auto-update" feature in it... so it just depends on
whether you can find it or not.

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: http://msblog.resdev.net
» ZackNET Forum: www.zacknet.co.uk/forum
» VistaBase: www.zacknet.co.uk/vistabase
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, mother or cat. Let's be clear on that one!


--- Original message follows ---

 

[Steve Foster [SBS MVP]]

Vista has mechanisms to automatically redirect writes to an application
folder to a folder within the user's own space. So you should find the log
files have been auto-relocated to somewhere deep within \Users\<username>.



I sure hope this can be disabled - what a stupid idea.

Well, applications saving user-specific information in the application
folder is also a stupid idea. That's what the users profile folder space
is for.

Applications that assume they can do whatever they like is *so* Win31...

Really, this concept is not new - it's been around since NT4 and probably
even NT3. In a sense, it would almost be better simply to fail the writes,
except that application vendors would carry on with the current lazy
answer "make your users local administrators", rather than getting with
the program and making their applications well-behaved. At least MS are
trying to provide a graceful (ish) solution that lets applications work,
without forcing the administrative privilege escalation.

 

[Steve Foster [SBS MVP]]

Which is stupid? The idea of turning it off or the idea that it needs to
be turned off? I honestly don't see how allowing an application that the
user installed to write to the installation folder is a problem.

Then why not set the ACLs accordingly during installation - 99% of
applications that want to write to their own folder don't do this, they
simply expect that users would be local administrators (and indeed if you
call Tech Support the response is "oh yes, make users local
administrators").

It's this abject failure on the part of developers that UAP is trying to
help with.

 

[Steve Foster [SBS MVP]]

Exactly. My remark was aimed at the concept that the OS would prevent an
installed app from writing to its own folder, ini file or whatever, and
transparently relocate that file to another location.

Why should the application have the privilege of writing to its' own
folder? It runs in the context of the user account that starts it, and
inherits their permissions. Users should not generally have privileges to
write to installation folders, only their own profile space. Ergo, that's
where applications should be storing user data.

 

[Steve Foster [SBS MVP]]

Oh yes, we can't let applications write to their own folder. Why if we
let them do that... Actually, I don't see much reason why that should be
a problem. Frankly, I don't see how it makes the system more secure.
Just more difficult for developers like me. Sigh...

I expect that you use HKLM to store user information too, rather than HKCU
when using the registry, right?

 

[Dan]

Exactly. My remark was aimed at the concept that the OS would prevent an
installed app from writing to its own folder, ini file or whatever, and
transparently relocate that file to another location.

I completely agree!