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:
[url]http://forums.microsoft.com/msdn/showforum.aspx?forumid=120&siteid=1[/url]
--
--
Andre
Windows Connect | [url]http://www.windowsconnected.com[/url]
Extended64 | [url]http://www.extended64.com[/url]
Blog | [url]http://www.extended64.com/blogs/andre[/url]
[url]http://spaces.msn.com/members/adacosta[/url]

"Dan" <Dan@NoSpam.com> wrote in message
news:foOdnUbwsNcx_ZLZnZ2dnUVZ_tudnZ2d@comcast.com. ..

> 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?
>
>
>

[Chris Altmann]

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

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

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\VirtualStor e\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.

"Dan" <Dan@NoSpam.com> wrote in message
news:foOdnUbwsNcx_ZLZnZ2dnUVZ_tudnZ2d@comcast.com. ..

> 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]]

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

"Dan" <Dan@NoSpam.com> wrote in message
news:foOdnUbwsNcx_ZLZnZ2dnUVZ_tudnZ2d@comcast.com. ..

> 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?
>
>
>

[Steve Foster [SBS MVP]]

Dan wrote:

>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.

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

[Dan]

"Andre Da Costa [Extended64]" <andred25@hotmail.com> wrote in message
news:uqyc0ZwQGHA.6084@TK2MSFTNGP10.phx.gbl...

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

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 :o) 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,
[url]http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx[/url] -
you might find that useful.

All the best :o)

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: [url]www.zacknet.co.uk[/url]
» MSBlog on ResDev: [url]http://msblog.resdev.net[/url]
» ZackNET Forum: [url]www.zacknet.co.uk/forum[/url]
» VistaBase: [url]www.zacknet.co.uk/vistabase[/url]
» 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]" <steve.foster@picamar.co.uk> wrote in message
news:xn0eji09yb6wqt001y@msnews.microsoft.com...

> Dan wrote:
>

>>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.
>
> --
> Steve Foster [SBS MVP]
> ---------------------------------------
> MVPs do not work for Microsoft. Please reply only to the newsgroups.

[Andre Da Costa [Extended64]]

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

"Zack Whittaker (R2 Mentor)" <admin@zacknet.co.uk> wrote in message
news:%23XGS2ExQGHA.5728@tk2msftngp13.phx.gbl...

>> 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 :o) 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,
> [url]http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx[/url] -
> you might find that useful.
>
> All the best :o)
>
> --
> Zack Whittaker
> Microsoft Beta (Windows Server R2 Beta Mentor)
> » ZackNET Enterprises: [url]www.zacknet.co.uk[/url]
> » MSBlog on ResDev: [url]http://msblog.resdev.net[/url]
> » ZackNET Forum: [url]www.zacknet.co.uk/forum[/url]
> » VistaBase: [url]www.zacknet.co.uk/vistabase[/url]
> » 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]" <steve.foster@picamar.co.uk> wrote in message
> news:xn0eji09yb6wqt001y@msnews.microsoft.com...

>> Dan wrote:
>>

>>>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.
>>
>> --
>> Steve Foster [SBS MVP]
>> ---------------------------------------
>> MVPs do not work for Microsoft. Please reply only to the newsgroups.

>
>

[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
[url]http://vbnet.mvps.org/[/url]

Please reply to the newsgroups so all can participate.

[Dan]

"Steve Foster [SBS MVP]" <steve.foster@picamar.co.uk> wrote in message
news:xn0eji09yb6wqt001y@msnews.microsoft.com...

>
> 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]

"Zack Whittaker (R2 Mentor)" <admin@zacknet.co.uk> wrote in message
news:%23XGS2ExQGHA.5728@tk2msftngp13.phx.gbl...

>> 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.

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?

>> 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 :o) 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,
> [url]http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx[/url] -
> you might find that useful.

Thanks! I'll have a look.

[Dan]

"Randy Birch" <rgb_removethis@mvps.org> wrote in message
news:uFM34WxQGHA.1160@TK2MSFTNGP09.phx.gbl...

> 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
[url]http://vbnet.mvps.org/[/url]

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: [url]www.zacknet.co.uk[/url]
» MSBlog on ResDev: [url]http://msblog.resdev.net[/url]
» ZackNET Forum: [url]www.zacknet.co.uk/forum[/url]
» VistaBase: [url]www.zacknet.co.uk/vistabase[/url]
» 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]" <andred25@hotmail.com> wrote in message
news:uzaKrWxQGHA.5584@TK2MSFTNGP12.phx.gbl...

> Is it that thing called Click Once? I remember Microsoft pushing it a lot
> at PDC 2003.
> --
> --
> Andre
> Windows Connect | [url]http://www.windowsconnected.com[/url]
> Extended64 | [url]http://www.extended64.com[/url]
> Blog | [url]http://www.extended64.com/blogs/andre[/url]
> [url]http://spaces.msn.com/members/adacosta[/url]
>
> "Zack Whittaker (R2 Mentor)" <admin@zacknet.co.uk> wrote in message
> news:%23XGS2ExQGHA.5728@tk2msftngp13.phx.gbl...

>>> 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 :o) 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,
>> [url]http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx[/url] -
>> you might find that useful.
>>
>> All the best :o)
>>
>> --
>> Zack Whittaker
>> Microsoft Beta (Windows Server R2 Beta Mentor)
>> » ZackNET Enterprises: [url]www.zacknet.co.uk[/url]
>> » MSBlog on ResDev: [url]http://msblog.resdev.net[/url]
>> » ZackNET Forum: [url]www.zacknet.co.uk/forum[/url]
>> » VistaBase: [url]www.zacknet.co.uk/vistabase[/url]
>> » 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]" <steve.foster@picamar.co.uk> wrote in message
>> news:xn0eji09yb6wqt001y@msnews.microsoft.com...

>>> Dan wrote:
>>>
>>>>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.
>>>
>>> --
>>> Steve Foster [SBS MVP]
>>> ---------------------------------------
>>> MVPs do not work for Microsoft. Please reply only to the newsgroups.

>>
>>

>
>

[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: [url]www.zacknet.co.uk[/url]
» MSBlog on ResDev: [url]http://msblog.resdev.net[/url]
» ZackNET Forum: [url]www.zacknet.co.uk/forum[/url]
» VistaBase: [url]www.zacknet.co.uk/vistabase[/url]
» 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 ---
"Dan" <Dan@NoSpam.com> wrote in message
news:AcOdnX_SUocfB5LZRVn-rA@comcast.com...

> "Zack Whittaker (R2 Mentor)" <admin@zacknet.co.uk> wrote in message
> news:%23XGS2ExQGHA.5728@tk2msftngp13.phx.gbl...

>>> 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.

>
> 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?
>

>>> 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 :o) 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,
>> [url]http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx[/url] -
>> you might find that useful.

>
> Thanks! I'll have a look.
>

[Steve Foster [SBS MVP]]

Randy Birch wrote:

>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]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

[Steve Foster [SBS MVP]]

Dan wrote:

>"Randy Birch" <rgb_removethis@mvps.org> wrote in message
>news:uFM34WxQGHA.1160@TK2MSFTNGP09.phx.gbl...

>>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.

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]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

[Steve Foster [SBS MVP]]

Randy Birch wrote:

>>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.

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]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

[Steve Foster [SBS MVP]]

Dan wrote:

>"Steve Foster [SBS MVP]" <steve.foster@picamar.co.uk> wrote in message
>news:xn0eji09yb6wqt001y@msnews.microsoft.com...

>>
>>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...

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

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

[Dan]

"Randy Birch" <rgb_removethis@mvps.org> wrote in message
news:u%23yz%23xyQGHA.5116@TK2MSFTNGP10.phx.gbl...

> >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.

I completely agree!