Hi there,
did you find any solution for this problem?
I`m trying to keep validation on ms business 2011 server but got the same
error... I really want to keep ICE validation but can not grand admin rights
to build service...
THanks
--
View this message in context:
To my knowledge, ICE validation requires elevated permissions.
Personally, every build server I've ever set up had the build account with
admin privs.At my last job we had 50+ build VM's with infrastructure in
place to apply the base snapshot and start the VM before each build so that
Yeah, but problem here is that our build server is also domain controller :(
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Build-WiX-Projects-via-msbuild-using-TFSPreview-Hosted-Build-Servers-tp7418321p7590422.html
Sent from the wix-users
I'm sorry, that's a really bad choice. Surely you can come up with the
money to put it some place better?
If money is tight, consider o/s virtualization. I run a small consulting
practice out of my home. Many of my infrastructure services have been
moved to the cloud: Mail, Blog, Web
Use util:XmlConfig. There's a VerifyPath attribute that will allow to verify
whether a path already exists on create and only run if the path does not
exist. I use it for a similar purpose to yours (only mine are for server
elements).
--
John Merryweather Cooper
Build Install Engineer --
No solution. Like you, I don't control the GP on my build controllers/agents,
and so I've had to suppress validation on all my newer build servers. Not a
happy story. CIS won't grant a variance.
--
John Merryweather Cooper
Build Install Engineer -- ESA
Jack Henry Associates, Inc.(r)
Since the consideration in this thread may eventually affect many of us, is
there any explanation anywhere why ICE requires elevation when not run
interactively?
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's
ICE validation should not require elevated permissions. For example, I build
on my local machine as non-admin all the time and it does not require
elevation. There are issues with ICE validation launched from services.
-Original Message-
From: Christopher Painter
I think the problem is what Jacob said (and what the post said) -- an issue
with choosing perMachine/perUser at runtime. It's what I meant to say, but
had the other things in my head and said that instead accidentally. :)
--
View this message in context:
I know that part of the issue is that some of the ICE stuff (supplied by
Microsoft) still depends on VBS. The other part is that CIS departments are
loath to give rights to run the Windows Installer Service to
not-true-and-not-human administrators. That latter also blocks me from running
LUX
Hi John,
Could you supply me some example code? I tried the util:XmlConfig before, but
without any luck.
Met vriendelijke groet,
Alexander op de weegh
Total Productivity
tel.:+31-226335016
mob.: +31-620138301
-Oorspronkelijk bericht-
Van: John Cooper
Here is the InstallServices action from the log. I masked product name from
the commands/paths below
Notice the ServiceInstall for the each of the services is 2 min apart.
MSI (s) (50:DC) [*14:30:*24:071]: Executing op:
ActionStart(Name=InstallServices,Description=Installing new
According to this post:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-amp-per-user-or-per-machine-td7579453.html#a7579508
It sounds like Burn may not support a mixed 64/32-bit setup.
--
View this message in context:
Yes that`s true as Rob says. It does not require admin right, but if the
service do not have admin rights then it needs to be interactive. It means
it need to be run as logged user...
--
View this message in context:
Bitness isn't the issue, burn will support that. The issue is as the original
author stated the MSI modifying context at runtime to be per user verses per
machine.
If it were me, I'd create two bundles and disable the MSI's internal UI
(forcing one to be per user and one to be per machine).
I do not know anything about it... but when I run smoke.exe with parameter -v
it shows that there are 100 ICE tests, so my question do we know what they
should to test? And another question, it is problem to do new tool which can
test it?
Because when I was using orca, it looks just like some DB,
Is this reproducible with other installs on the same machine? If you
register a service using SC.exe does it have the same behavior?
I'm sorry, I've never seen this before.
From: wixtester sangee...@hotmail.com
Sent: Friday, November 08, 2013 8:27
That makes sense. All my stuff is services.
No way corporate will let me run my build controller interactive. Bummer.
--
John Merryweather Cooper
Build Install Engineer -- ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
This is a general question that I have run into several times. I understand
how to author an element like ComponentGroup as a child of a Fragment, and
then reference that fragment using ComponentGroupRef, as one example.
However I came across several elements that do not have a corresponding
I have created the setup using wix 3.6, burn and bootstrapper. While the
installation of created setup, i need the get the msi file. Can anyone help
me to find the msi file at the time of installation?
I am also created the setup using Wix3.6 without wix burn. While installing
the installer which
Okay I have done a bit more testing with Pure Wix and Melt and here is what I
have found with my testing.
Create Product.wxs with a bunch of components in root and I also create a
fragment with is bunch more components.
I then built this msi and associated .wixpdb file.
I then updated some of
When one thing is referenced in a Fragment the whole Fragment is pulled in.
CustomTable is a bit weird because it automatically creates a ref from a
CustomTable with Rows to the CustomTable with Columns. Thus, you can put the
CustomTable with Columns in a Fragment and then have many CustomTable
I'm always a bit behind on patching stuff but it sounds like your adding
PatchFamilies and that kicks in filtering. Filtering is designed to provide
very fine control of what ends up in the patch. If you don't want filtering,
IIRC (and my memory in this area is notoriously poor), don't add
Thanks for the explanation.
Phill
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-reference-elements-in-a-Fragment-which-do-not-have-a-XxxxRef-construct-tp7590454p7590462.html
Sent from the wix-users mailing list archive at Nabble.com.
This strategy works out well as long as you don't mind having a large patch
file that patches files that don't need to be patched.
What I'm looking for is a way to determine what exactly has changed. I would
like to further narrow the patch family down to a 1:1 relationship with a
feature as
I love the idea of this but alas we sign and version our files for every build.
In essence EVERYTHING changes at this point. Is there a way to get the
filtering to ignore certain properties/attributes of a file?
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Phil was asking for the reason why would need to know where the MSI is. It's
not a common requirement so there may be a better solution if we know what you
intend on doing with it.
-Original Message-
From: Periyasamy [mailto:periyasa...@syncfusion.com]
Sent: Friday, November 08, 2013
Tim, can you send me the melt command you are using? I'm still getting
failures with invalid paths and I am using melt.
Cheers,
Stephen
-Original Message-
From: TimM [mailto:timmay...@smarttech.com]
Sent: November-08-13 1:23 PM
To: wix-users@lists.sourceforge.net
Subject: Re:
2013/11/7 Nick Ramirez nickra...@hotmail.com:
You might have to save the users's choice (Machine or User) somewhere and
feed it back in as a command line arg upon uninstall.
--
View this message in context:
I've updated the MSBuild wixproj template to fix a few nits and use the
un-documented Torch MSBuild tool task. You can see it here at:
http://borgsdemons.com/blog/2013/11/08/improved-msbuild-project-for-building-a-wix-way-patch-from-administrative-installs/
--
John Merryweather Cooper
Build
It's not clear to me what that ApplyPatch method is doing under the covers.
It's not MsiApplyPatch(), because that does an install of the patch. It
appears to actually be MsiDatabaseAplyTransform() judging from the
transform parameter, and that just modifies the tables.
This might help:
Hey Stephen,
Here is the contents for my sample build.bat file:
@echo call melt.exe to fix the Version 1.0 wixpdb file so that we do not
have to worry about original source files/folders.
Melt.exe Ver1.0\product.msi -out Ver1.0Corrected\product.wixpdb -pdb
Ver1.0\product.wixpdb -x
Hi
Let consider the following sceneraio,
Let the msi file name is SampleInstaller.msi and the setup name is
SampleSetup.exe.
If the end user wants to create the setup file with SampleInstaller.msi and
the msi file created by end-user. In this case we need to get the msi file
from the
You can make the MSI external to setup.exe
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-the-msi-file-resides-while-setup-installation-created-by-wix-burn-bootstrapper-tp7590453p7590476.html
Sent from the wix-users mailing list archive
Okay Rob, taking out the PatchFamily does allow the patch to all updated
files to be correctly patched and therefore does reduce the complexity of
this method...
Now if we look at Stephen's issue I can see this being a major concern as we
also do the same thing where files are updated with
If you are talking about users modifying a MSI on their end and then
deploying it via a bundle you created, burn probably won't support this. When
compiling, meta information about the packages a bundle is deploying (download
location, product code, upgrade code, version, etc) are embedded
Right, but if you make it external, and the end users are modifying it... How
would they version their changes without needing a new bundle?
-Original Message-
From: tom [mailto:tomer.d...@intergraph.com]
Sent: Friday, November 08, 2013 1:23 PM
To: wix-users@lists.sourceforge.net
depends on the changes i guessif the manifest doesnot contain details
about them...
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-the-msi-file-resides-while-setup-installation-created-by-wix-burn-bootstrapper-tp7590453p7590478.html
The latter. Binary diffs are non-trivial. For example of this, see how TFS
handles binary check-ins. Like you, my builds version every rebuilt assembly
every build. So, we're guaranteed at least several dozen new assemblies
every build. Patching without PatchFamily would essentially be
if -layout is not supported in order to extract msi packages
how can i support resolve source event?
I was thinking that if a cached msi was deleted user can exract it from the
setup.exe...
Thanks in advance
--
View this message in context:
Phill i wonder did you ever try to create a Ref extension to a table
with bootstrapperApplicationData=yes
I have a MBA and a collection of extensions to modify the manifest at
compile time:
the problem that all extension must be placed in the bundle.wxs i guess...
--
View this message
The services do not have any passwords, install log must be printing
PASSWORD unnecessarily in this case. The installer runs with elevated
privileges.
This delay in installing services is only on win 8, 8.1 systems. Install on
win 7 is much faster.
Installing the service from command prompt
Yes, that is the way it looks like we will have to do things.
However I would say non-trivial doesn't mean impossible. Someone out there
must have thought of this problem before us, otherwise we have a patentable
piece of work here in this mailing list :) My name MUST be on the patent!
My
Well I just did a test of Patch Creation using two different builds of our
next release of our software, which the .msi files are 118 MB in size, and
if I set the WholeFilesOnly=yes the patch .msp size is 20MB. Now if I set
the WholeFilesOnly=no then the size of the .msp is only 3.8 MB. Way
FWIW, no issues here, the RC looks pretty stable and good as far as I see.
Nice work!
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Thursday, October 31, 2013 4:00 PM
To: WiX-users; wix-d...@lists.sourceforge.net
Subject: [WiX-users] WiX v3.8 RC available
Is this: pyro -delta ?
-Original Message-
From: TimM [mailto:timmay...@smarttech.com]
Sent: Friday, November 8, 2013 1:04 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Purely WiX patching and FeatureRef
Well I just did a test of Patch Creation using two different
I'm confused. Are you saying you want the end user to download your bundle,
modify a package in the bundle then install the original bundle with the new
package? If so, that would be a security vulnerability and is not possible.
-Original Message-
From: Periyasamy
Ah that could be what we are looking for... This is another case of not looking
at the documentation or not knowing it there was any
I'll get this a try on some of my Pure WiX samples to verify that this works
and if it does then we should have everything.
Thanks,
Tim.
From: robmen
Learn something new every day. Gave -delta a spin and it seems good. I'll
have to give it a spin without PatchFamily next and compare results.
--
John Merryweather Cooper
Build Install Engineer -- ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
Note: IIRC, delta patches (not whole file only patches) have all kinds of
screwy behavior. IIRC, you can address most of the behavior by ensuring the MSI
is cached (like Burn does). I suggest testing heavily to make sure that
everything works as you expect.
-Original Message-
From:
Don't like the experience of -delta and a commented out PatchFamily. It tries
to generate a MajorUpgrade patch (changes the ProductVersion property in the
Property table and overwrites the Upgrade table). I think this is a side
effect of our ProductCodes changing every build, but we're happy
Now most of our builds update the PC so that we can treat every build as a
Major Upgrade as sometimes our testers/developers grab the builds and simply
install over the previous builds and therefore changing the PC every build will
prevent upgrade issues, but when we know that we are going the
I used above procedure using candle, light, msimsp executables to generate
hotfixes. However on applying the patch, i don't see expected changed file
deployment. How to proceed
On Mon, Oct 14, 2013 at 9:39 AM, Zarko Kostovic zarko.kosto...@gmail.comwrote:
Hi,
You get it by using candle and
Hi Rob,
Here is the requirement:
I have developed the installers using WIX Burn, one of our developer now
wants to extract the msi file from that BURN generated exe. Then he wants to
add some other preprequisites files and recreate the exe using his Wix Burn
(Bundle).
Is there a way to extract
Pretty much every copyleft except the FSF's GPL allows dynamically linked
library usage (unless it is explicitly denied). If it doesn't involve changing
the code of the binary you wish to use, it's probably legal (the disclaimer is
here because IANAL, you should consult with your own to be
55 matches
Mail list logo
