I agree about multiple changes not being supported. Didn't even consider that.
:)
Side note: Interesting. That's not how GitHub works. Pull requests are 1:1 with
merges into the target branch hosted on the site. (Well, if you use the web
site pull request functionality, anyway - not sure if CodePlex works that way
since I only ever got one pull request into one of my projects and I politely
rejected it because it didn't fit with the overall tenets of the project - to
which the developer agreed.)
Heath Stewart
Software Design Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths
From: r...@robmensching.com
To: wix-devs@lists.sourceforge.net
Date: Thu, 23 Jan 2014 18:15:54 +0000
Subject: Re: [WiX-devs] Burn package location WIP:4278
Yes, moving is a separate executable. Admins would need to set policy up front
or get some “yet to exist tool” to move it. You are also correct, Burn would
need to be able to fallback to the default location.
I don’t think Burn needs to try to find multiple caches if the policy changes
many times. That’s a “don’t do that” type thing. <smile/>
Side note: You probably pushed another change before the accepted changes were
pushed back. Accepting doesn’t mean the changes are necessarily in the repo
yet… just that they will be.
From: Heath Stewart [mailto:hea...@outlook.com]
Sent: Thursday, January 23, 2014 8:59 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Burn package location WIP:4278
That could work. The only downside I see is that redefining it doesn't actually
move it, unlike the APIs that support KNOWNFOLDERIDs. Then again, a separate
executable - or baking such functionality into the
Burn engine itself (which I considered but doesn't seem right and potentially
too much burden on BAs) - would be necessary anyway so this may not be an issue.
But I think that mainly replaces the KNOWNFOLDERID. We'd still need to consider
older (current) versions of Burn and newer versions of Burn would still have to
fall back to the current package cache location.
I do believe, however, that would also solve the problem of having to define a
separate, new folder, though, since redefining a KNOWNFOLDERID (with the
appropriate flags as documented in the WIP currently) also moves the directory.
Changing a reg policy key
wouldn't.
So maybe something like (HKLM|HKCU)\Software\Policies\Package Cache @ Location
(or could make it the default value as well)?
On a side note, I sent another pull request to remove the “draft” flag but for
some reason the previous commit you already accepted is in the pull request as
well. I pull the upstream “wixweb” branch and merged
the FETCH_HEAD before pushing back into my fork. Did you cherry-pick or
something?
- Heath from his Surface Pro
From: Rob
Mensching
Sent: Thursday, January 23, 2014 8:30 AM
To: Windows Installer XML toolset developer mailing list
Cc: Heath Stewart
I read the WIP to “Allow administrators and users to redefine the payload cache
locations” and wondered if an easier solution that would also work for Windows
XP would be to use Policy keys to override the default location of the package
cache. Policy is already well supported by administrator tools and we already
have polutil.cpp in dutil.lib to do the heavy lifting.
It would also avoid the elevation concerns. For example, can you register
per-user knownfolders without elevation? The MSDN documentation says you can’t:
Note This method updates
HKEY_LOCAL_MACHINE and therefore needs to be run in the context of an
administrator. Setup programs need administrator privileges to register or
unregister a known folder.
But it’s been unclear before. <smile/>
Thoughts?
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
