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

Reply via email to