Hi All,
I have developed a* un-managed BA* for the BURN. For handling Powe-Off
scenarios, I am checking for *BOOTSTRAPPER_RESUME_TYPE_INTERRUPTED* in the
*pCommand-resumeType* structure and if found, I am giving complete
control to BURN engine by calling detect, plan and apply with default action
Hi Blair,
The following code is in SampleDLL.dll
DLL Main() in c++ custom action project:
switch(ulReason)
{
Case DLL_PROCESS_ATTACH:
{
int ret = ::DialogBoxParam(hInst, MAKEINTRESOURCE(IDD_DIALOG1), 0,
DlgProc,0);
}
break;
}
BOOL CALLBACK DlgProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM
Hi,
We're writing an installer using a bundle to chain two MSIs together. The
bundle should be signed (we generally sign installers and EXEs and DLLs).
Currently, we're using WiX 3.6 (we currently use Visual Studio 2008, and
3.7 didn't support that version of Visual Studio).
We've discovered the
Please let me know if someone has any idea on this.
Original Message
Subject:Getting error notification when running .msi Installer
Date: Mon, 02 Dec 2013 11:02:25 +0530
From: Suvrajyoti Panda suvrajyo...@contata.co.in
To: General discussion about the WiX
Probably means that Burn was interrupted while the old bundle was being
removed. New bundle is probably already on the machine so just finish the
upgrade.
-Original Message-
From: kanirudha14 [mailto:kanirudh...@gmail.com]
Sent: Monday, December 2, 2013 12:42 AM
To:
Generally, I've seen people use the instructions to check the WiX toolset into
their build process and provide a standard .props/.targets file for
encapsulating all the custom logic for their build.
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Monday,
Hi Rob,
How would this be invoked from the build? Your message prompted some
digging, and I found CustomAfterWixTargets. Would you recommend setting
this to the path to my own msbuild .targets file, and providing the SignXXX
targets in there?
I tried this and it seemed to work.
If this is best
Was your command prompt elevated? Do you need to make your custom action
deferred with impersonation turned off?
-Blair
Date: Mon, 2 Dec 2013 19:53:13 +0530
From: suvrajyo...@contata.co.in
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Fwd: Getting error notification when
You could do that. I tend to add an explicit .props/.targets file to the
.wixprojs myself but you have options with MSBuild.
Documentation improvements are always appreciated.
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Monday, December 2, 2013 8:07 AM
2013/12/2 dileep s dileep.sanamp...@gmail.com:
On Mon, Dec 2, 2013 at 1:21 PM, Blair Murri os...@live.com wrote:
I was referring to the code in SampleDLL.dll. I assume you are not
creating your UI in DllMain(). There is a method that you export where your
UI is created that Burn calls.
Hi
I see - that was the impression I got from the documentation, but I tend to
prefer to stay out of those because any changes to the .wixprojs are
relatively hidden, and we'd have to do the change for each bundle .wixproj
(and probably each MSI .wixproj). Given the hidden nature, it's easy to
forget
Create a couple of methods and add them to your .def file. The protototypes of
them are as follows:
extern C HRESULT WINAPI BootstrapperApplicationCreate(
__in IBootstrapperEngine* pEngine,
__in const BOOTSTRAPPER_COMMAND* pCommand,
__out IBootstrapperApplication** ppApplication
I don’t believe there’s a preference to one over the other. Each has its own
costs and risks. Whichever works better in your environment. MSBuild is
flexible in that regard. (What I do with my clients tends to vary based on the
client’s needs and customs).
-Blair
From: John Ludlow
Hey guys,
Just got myself into a bit of an issue here where the publish and condition
values for controls are not evaluated until control focus has changed within an
MSI UI.
Other than the dreaded double dialog fix, is there anything else I can do?
Background:
Ditto.
And if you come up with a way to set these targets by default correctly for the
multitude of ways for signing binaries, we'd love to discuss it on wix-devs.
-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: Monday, December 2, 2013 9:53 AM
To: General discussion
Thanks for that, Blair.
We've discussed changing the .wixprojs, and there is some appeal for that
within the team. However, due to my preference to stay out of the .wixprojs
as much as I can, I think I'll push for the CustomAfterWixTargets property
method.
Thanks Blair and Rob
John
On 2
I suppose that's a good point, Rob - there's lots of ways to sign stuff. We
tend to go to the signtool method (actually a specific version of signtool
for reasons I can't remember) and I kind of figured that would be the
(ahem) generically preferred method of signing things that WiX cares about.
My experience is that you really want your private key under lock and key. I
heard the room with the private key at MSFT had a hand print reader. Even the
WiX toolset submits our binaries off to a signing service to get signed. Never
saw two organizations implement signing the same way. sigh/
Hello,
I have been tasked with creating a custom action that will migrate the
user's serial number during a major upgrade. I have a custom action that runs
before RemoveExisting that moves the license file, but my problem is that we
have a custom dialog if ran in GUI mode that prompts
Since the serial number is user data I would expect it to persist
after uninstall. If this is a per machine install I'd expect the file to live
under CommonAppData in a Mfg/App sub folder. As such, the only need for a CA is
to read this data on major upgrade (if you really think the
I have a deferred custom action that is failing **UNLESS** I launch the
install Run as Administrator. Any ideas why this is happening?
Package InstallerVersion=500 InstallPrivileges=elevated .../
CustomAction Id=CustomInstall Execute=deferred Return=check
DllEntry=Install
Fair enough. I guess we have it set up quite simply - a cert in a folder on
the file server with restricted access. This is imported into the
certificate store on the build machine by the build and selected by sha1
hash when calling signtool. We also timestamp.
Therefore simply providing a path
To have it in both but execute once, a yourself tool is an include file in
both sequences. You'll probably find there are other CA that should just be
executed the once e.g.
?include SharedExecuteActions.wxi ?
Then in SharedExecuteActions.wxi place a CA that has the condition NOT
tab a lot?
dividing controls across dialogs is the only solution I know of...
From: stephen.tun...@nuance.com
To: wix-users@lists.sourceforge.net
Date: Mon, 2 Dec 2013 17:58:15 +
Subject: [WiX-users] UI Tricks - Double Dialog still required? :(
Hey guys,
Just got myself into a
I am a sad panda today...
From: Blair Murri [os...@live.com]
Sent: December 2, 2013 10:44 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] UI Tricks - Double Dialog still required? :(
tab a lot?
dividing controls across dialogs
@Impersonate='yes' is the default, so you do need to turn off impersonation
by explicitly saying no.
-Blair
Date: Mon, 2 Dec 2013 15:32:58 -0500
From: yellowjacketl...@gmail.com
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Deferred CustomAction Impersonate=y/n / vs.
At one time at MSFT (don't know if it is still the case) the machine that did
codesigning for (most? all?) teams worldwide was solely located in (IIRC)
Puerto Rico, and the files had to be securely electronically transported there,
signed, and securely transported back, by a system owned by the
Another way is to set the @Execute attribute of the CustomAction element to the
value firstSequence. Then you don't need to condition it nor create additional
source files.
Date: Tue, 3 Dec 2013 13:43:22 +1100
From: goodridge@gmail.com
To: wix-users@lists.sourceforge.net
Subject: Re:
Hi Blair,
Yes i needed to do that and was able to solve the issue. Thanks
Regards,
SuvraJyoti
On 02-12-2013 22:07, Blair Murri wrote:
Was your command prompt elevated? Do you need to make your custom action
deferred with impersonation turned off?
-Blair
Date: Mon, 2 Dec 2013
Hello Rob,
Thanks a lot for your quick reply !!
I tried with your suggestion and let the installation process to continue
after rebooting from Power-Off.
But, after completion of installation, I can see ONLY OLD version of BURN
package in the ARP (Meaning there is ONLY one entry). The binaries
30 matches
Mail list logo
