Hello Rob,
here is a minimal mergemodule showing the error:
?xml version=1.0 encoding=UTF-8 ?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Module Id=MergeModule Language=1033 Version=1.0.0.0
Package Id={SomeGUID} Manufacturer=ACME InstallerVersion=200
/
Directory
Hi all,
I am having trouble installing a native assembly in WinSxS. Here's what I
did:
I created a simple native code dll (just let VC2010 create one for me,
really)
I have self-signed a certificate, pktextract gives me this on it:
Microsoft (R) Side-By-Side Public Key Token Extractor
Hi Kajal
Thank you for your email.
Unfortunately the mst has already been released to our customers. We are now
trying to release the msp patch and it is not patching the file. So we are
trying to see how we can now fix the problem (so that the msp updates the file
correctly) caused by the
Hi.
We are trying to keep some state alongside our bundle about which packages have
been chosen for installation. The solution we envisioned was to put some
registry entries within HKLM, but this fails on Windows 7 (and probably Vista)
due to HKLM requiring admin privileges. We could work
Use the version lying technique: Change the version of this FileId to
10.1.1 in your patch upgrade image by editing the msi in orca. Then
re-build the patch pointing to your edited MSI.
When the patch installs on top of the localised version it won't matter
that the transform has removed this
How are you setting the values? Burn automatically prompts to elevate if
it detects an MSI that is set to all users but you can also set this with
MsiPackage/@ForcePerMachine.
Neil
Hi.
We are trying to keep some state alongside our bundle about which
packages have been chosen for installation.
Don’t know why but after I ran this start /wait devenv.exe /setup /log
%TEMP%vssetup.log devenv.exe /log %TEMP%vsrun.log to try and capture a
log file I was able to open wixproj again in Visual studio but I cannot add my
custom BA anymore :(
It states it's not a valid wix extension but it
You could try making it a companion file in your patch.
So, the installation state of a companion file depends not on its own file
version, but on the version of its companion parent.
Hence the mst removing the version no. will become ineffective.
-Original Message-
From: Uma Harano
Thanks! I will try this.
On Oct 15, 2012, at 5:46 AM, Kajal Kumar Biswas kbis...@adobe.com wrote:
You could try making it a companion file in your patch.
So, the installation state of a companion file depends not on its own file
version, but on the version of its companion parent.
Hence
Hi Matt
The edited msi that the msp targets does the correct 10.1.1 version.
But the msp is still not patching it.
I will try the companion file idea that Kajal explained.
Thanks!
On Oct 15, 2012, at 5:32 AM, Matt O'Connell techsupport...@gmail.com wrote:
Use the version lying technique:
The values are set by our custom Managed Bootstrapper Application via the
standard .NET Registry API, and not by any of the included packages. Since the
information to be stored is on the bundle-level (which packages are selected
for installation), it can't be moved into an MSI.
I have
I looked at doing something similar and decided it was easier to write the
values in an MSI. My logic was that I didn't want to write until the
install had actually started and by that time the installer was already
running elevated. I am not familiar with the managed BA to know if you can
write
Ah - sorry I didn't realize the Sourceforge bug database covered the web
site, too. Ticket filed.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Sunday, October 14, 2012 03:27
To: General discussion for Windows Installer XML toolset.
Subject: Re:
This is true up until you patch the bundle. I know externally applying the MSP
causes the size to be incorrect. I would have to test it again to see if
putting a bundle with a MSP on top of a bundle also caused the issue.
-Original Message-
From: Rob Mensching
What do you mean patch the bundle? Burn uses the sizes of the packages
contained inside it to calculate the sizes in ARP.
On Mon, Oct 15, 2012 at 7:16 AM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:
This is true up until you patch the bundle. I know externally applying
the MSP causes the
Awesome, can you create a bug with that information in it? We tend to lose
issues only reported via email.
On Sun, Oct 14, 2012 at 11:09 PM, Dirk Ziegelmeier d...@ziegelmeier.netwrote:
Hello Rob,
here is a minimal mergemodule showing the error:
?xml version=1.0 encoding=UTF-8 ?
Wix
Neil is correct. The BA is not elevated because it does not rollback but
the package installs do.
If you just want to store settings for your BA, you can set Variables and
mark them Persist='yes' and Burn will remember them for you. That sounds
like it might be more applicable for you anyway.
On
The Burn log file has timestamps for just about every action. Can you share
the log file?
On Mon, Oct 15, 2012 at 7:00 AM, Jansson mattias.jans...@lyen.se wrote:
Hi all,
We are developing a burn bootstrapper application and have encountered
performance issues on some machines. On those
you can set Variables and mark them Persist='yes' and Burn will remember
them for you.
Am I correct that it remembers them for Uninstall/Repair but there is no way to
recall them if you do an upgrade?
Neil
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent:
Sounds like the registration didn't finish correctly for VS2008. I'll try
to put together a repro machine and see if it is a one off or if WiX's
setup is missing something.
For the second issue, are you trying to add a Reference to your Custom BA
from a .wixproj? If so, it is possible that the
It remembers them for a specific Bundle. There is not currently a mechanism
to get to the state of another Bundle (I think there is a feature request
open to enable that).
On Mon, Oct 15, 2012 at 10:10 AM, Neil Sleightholm n...@x2systems.comwrote:
you can set Variables and mark them
If one either applies a bundle and then in an external process releases a MSP
to patch the component. I thought I saw this happen on XP if I installed the
RTM bundle, and then released an updated bundle with the original content and a
MSP. Applying a MSP without the bundle I can see causing
What does your BootstrapperCore.config file look like? Does it correctly
indicate the v2 NETFX should be used?
On Mon, Oct 15, 2012 at 2:18 AM, Igor Brejc igor.br...@gmail.com wrote:
Hi,
I have a simple problem: I've written a managed bootstrapper (WiX v3.6)
written in .NET 2.0. On my
Hello,
Thanks Rob, does the wix reference need to be in the Wix toolset directory?
I tried adding it there and I was able to reference it.
Thank you,
Michael Ogilvie
Application Support Specialist | PixeLINK
1900 City Park Drive, Suite 410.
Ottawa, Ontario K1J 1A3
tel: 613.247.1211 Ext. 242
Having the update URL come from outside the Bundle would be a very large
security gap. Essentially, any Bundle could be used to launch any other
random Bundle. That's not right. There is certainly work that could be
done in the wixstdba to support bundle self-update but I don't think
passing the
Does v3.6 have the bundle self-update feature or only v3.7?
Thank you,
Michael Ogilvie
Application Support Specialist | PixeLINK
1900 City Park Drive, Suite 410.
Ottawa, Ontario K1J 1A3
tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype:
pixelink.mogilvie
New feature in v3.7:
http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset
On Mon, Oct 15, 2012 at 10:29 AM, Michael Ogilvie
michael.ogil...@pixelink.com wrote:
Does v3.6 have the bundle self-update feature or only v3.7?
Thank you,
Michael Ogilvie
Application Support
Thanks,
I will try updating again and hopefully I don't have more issues
Thank you,
Michael Ogilvie
Application Support Specialist | PixeLINK
1900 City Park Drive, Suite 410.
Ottawa, Ontario K1J 1A3
tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype:
3.7 is in a development/potentially unstable state, so I wouldn't upgrade to
3.7 for a production deployment as of yet.
-Original Message-
From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com]
Sent: Monday, October 15, 2012 12:45 PM
To: General discussion for Windows Installer XML
Very True. I was thinking that there would not be a security issue if you
check the UpgradeCode on the downloaded bundle before installing but anybody
could make a bundle with my upgrade code. :) Maybe you could support it only
in cases were the bundle is signed? You could check that the
Yes, all true. None implemented yet. smile/
On Mon, Oct 15, 2012 at 11:05 AM, Wesley Manning wmann...@dynagen.cawrote:
Very True. I was thinking that there would not be a security issue if you
check the UpgradeCode on the downloaded bundle before installing but
anybody could make a bundle
Hey all,
Just upgraded and tried to rebuild my VS2010 wix project. Cleaned up a few
warnings and now it compiles clean... _except_ for the following error:
candle.exe(0,0): error CNDL0001: Cannot set column 'SecureObject' with a
null value because this is a required field.
The error
Runing the candle command from a command line window yields additional
exception output. As a side note, any ideas why wouldn't the exception
details be captured as part of the build output when invoked from VS2010
(sure would have saved me a ton of time)?
Here's the output:
Exception Type:
Hey all,
More details...
The problem seems to be restricted to RegistryKey .. elements with a child
util:PermisionEx ...
Here's some pre 3.6 code that was fine:
Component Id=RegistryValues Guid={.. hah ...}
RegistryKey Action=create Root=HKLM Key=SOFTWARE\blah\blah
util:PermissionEx
Obviously. Please file a bug so the next person benefits.
On Mon, Oct 15, 2012 at 8:09 PM, Robert MacFadyen rmacfad...@rmtrack.comwrote:
Hey all,
More details...
The problem seems to be restricted to RegistryKey .. elements with a
child
util:PermisionEx ...
Here's some pre 3.6 code that
35 matches
Mail list logo
