Obviously. Please file a bug so the next person benefits.
On Mon, Oct 15, 2012 at 8:09 PM, Robert MacFadyen wrote:
> Hey all,
>
> More details...
>
> The problem seems to be restricted to elements with a
> child
> .
>
> Here's some pre 3.6 code that was fine:
>
>
>
> GenericAll="yes
Hey all,
More details...
The problem seems to be restricted to elements with a child
.
Here's some pre 3.6 code that was fine:
This generates the following warning:
The RegistryKey/@Action attribute has been deprecated. In most cases, you
can simply omit @Action. If
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: System
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 out
Yes, all true. None implemented yet.
On Mon, Oct 15, 2012 at 11:05 AM, Wesley Manning wrote:
> 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. :)
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 sig
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
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:
pixelink.mogilvi
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
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
www.pixelink
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
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
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 wrote:
> Hi,
>
> I have a simple problem: I've written a managed bootstrapper (WiX v3.6)
> written in .NET 2.0. On my developer machine (I hav
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 some
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 wrote:
> >> you can set Variables and mark them Persist='yes' and Burn wil
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 re
>> 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]
Sen
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 wrote:
> Hi all,
>
> We are developing a burn bootstrapper application and have encountered
> performance issues on some machines. On those machines, the setup takes
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
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 wrote:
> Hello Rob,
>
> here is a minimal mergemodule showing the error:
>
>
> http://schemas.microsoft.com/wix/2006/wi";>
>
>
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
wrote:
> This is true up until you patch the bundle. I know externally applying
> the MSP causes the size to be incorrect. I
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 [mailto:r...@robmensching.
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: [Wi
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 yo
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 attempte
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" wrote:
> Use the version lying technique: Change the version of t
Thanks! I will try this.
On Oct 15, 2012, at 5:46 AM, "Kajal Kumar Biswas" 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 the mst remov
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 [mai
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
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 installati
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 a
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 aroun
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 relea
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 1.1.3.0
34 matches
Mail list logo
