Re: [WiX-users] Burn does not show close application warning during uninstall

2014-03-11 Thread Georg von Kries 
I too thought I saw a feature request for "files in use" in WixStdBa but I
cannot find it anymore. Maybe it was on the mailing list only. 

I am willing to contribute this feature for the WixStdBa. I've implemented
this for our own projects, but it needs some cleanup and adjustments for the
latest Wix version. I'm little busy lately, but let me know if you guys are
interested.

Regards,
Georg 

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@firegiant.com] 
Gesendet: Samstag, 8. März 2014 08:33
An: Tobias Erichsen; General discussion about the WiX toolset.
Cc: b...@joyofsetup.com
Betreff: Re: [WiX-users] Burn does not show close application warning during
uninstall

I'd be a bit surprised if there isn't already a feature request tracking the
issue.

-Original Message-
From: Tobias Erichsen [mailto:i...@tobias-erichsen.de]
Sent: Friday, March 7, 2014 7:49 PM
To: General discussion about the WiX toolset.
Cc: Rob Mensching; b...@joyofsetup.com
Subject: AW: [WiX-users] Burn does not show close application warning during
uninstall

Hi Jacob,

> Are you using WixStdBA or your own BA?  I think it was in 3.8 where 
> those messages were now being seen and interpreted by the engine, but 
> I cannot remember if there were any callbacks to the UI.  Even if 
> there were, I don't remember WixStdBA having a dialog available to prompt
the user.
> ...
> I don't see any WixStdBA implementation so the default would be 
> IDNOACTION (equivalent to ignoring the running applications. A restart 
> will be required.)

I'm using the WixStdBA as this is (mostly) sufficient for my needs.
Unfortunately this seems to be a rather large drawback.  

I would suppose that many people that do not have the need for special stuff
in the GUI will be using the WixStdBA, so they would run into this issue...

To Rob & Bob:  any objections on creating a bug-request for this?  If not, I
would be doing so...

Tobias


-Original Message-
From: Tobias Erichsen [mailto:i...@tobias-erichsen.de]
Sent: Friday, March 07, 2014 1:41 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Burn does not show close application warning during
uninstall

Hi everyone,

I got a small problem during uninstall of my application.

If I install/uninstall just with an MSI on W7 for example, I get the dialog
that some applications must be closed before continuing install.

When I use that MSI within my burn-bootstrapper, this dialog does not
appear.

Do I need to specify "DisplayInternalUI" to be able to see this dialog?  My
MSI does not have any UI otherwise...

Best regards,
Tobias

PS.: All done with Wix 3.8

--
Subversion Kills Productivity. Get off Subversion & Make the Move to
Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and
the freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Subversion Kills Productivity. Get off Subversion & Make the Move to
Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and
the freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Subversion Kills Productivity. Get off Subversion & Make the Move to
Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and
the freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-user

Re: [WiX-users] EventManifest - broken or wrong usage?

2014-02-04 Thread Georg von Kries 
You are already providing your message file here:

  


If you open your manifest XML file after the installation, the
resourceFileName and messageFileName in the  tag should point to
the full path of the installed dll.

Kind regards,
Georg 

-Ursprüngliche Nachricht-
Von: Thomas Tomiczek [mailto:t.tomic...@nettecture.com] 
Gesendet: Dienstag, 4. Februar 2014 11:07
An: General discussion about the WiX toolset.
Betreff: Re: [WiX-users] EventManifest - broken or wrong usage?

Ok, so how do I do that? As in - the lines from the log (that show wevtutil
calls) all show only the IM and one path - not any other parameters. So, I
am totally at a loss now how to verify that.

Regards

Thomas

-Original Message-
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: 04 February 2014 10:49
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] EventManifest - broken or wrong usage?

If I remember correctly, the /rf and /mf parameters are replacing the
resourceFileName and messageFileName attributes in your manifest with the
provided paths. This is already done by the WIX custom action and the
parameters are therefore not required. You should verify that the file paths
are adjusted after the installation.

The error must be something else. 

Kind regards,
Georg



-Ursprüngliche Nachricht-
Von: Thomas Tomiczek [mailto:t.tomic...@nettecture.com]
Gesendet: Dienstag, 4. Februar 2014 06:53
An: General discussion about the WiX toolset.
Betreff: Re: [WiX-users] EventManifest - broken or wrong usage?

Sorry to say, but I have validated it to work from the command line. The
WEVT should have 3 parameters  - im, /RF and /MF and the command line I do
see in the logs only has one. Care to explain that?

When I register all three manually it works.

When I rely on the WIX generated call, it does not. And, as I said, the
command line in the logs does not show /rf and /mf.

Regards

Thomas

-Original Message-----
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: 03 February 2014 22:29
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] EventManifest - broken or wrong usage?

Hi,

your components are correct, I use it the same way and it is working
properly. IMHO the call to wevtutil in your log looks correct too, as the
custom action will adjust the resource and message file paths in the
manifest XML. No need to pass those to wevtutil.

If I remember correctly, the hard part for using ETW was not the
installation but to get the manifest and native resources right in .NET.
Also don't forget to close the event viewer when testing your
installation... 

Kind regards,
Georg von Kries


-Ursprüngliche Nachricht-
Von: Thomas Tomiczek [mailto:t.tomic...@nettecture.com]
Gesendet: Montag, 3. Februar 2014 10:46
An: General discussion for Windows Installer XML toolset.
(wix-users@lists.sourceforge.net)
Betreff: [WiX-users] EventManifest - broken or wrong usage?

After some more research the question again.

Is the EventManifest (in the utility namespace) broken or do I just use it
wrong?

EventManifest is the WIX version of wevtutil.

In order to properly register one needs three parameters - the manifest and
2x the compiled manifest.

Regardless how I am setting things up I am seemingly only able to get the
first one called, the other two parameters always are not used, as a result
the registration does not work. I checked the logs and I never see the 2nd
and 3rd parameter being called.

In the particular example, I am declaring the files as:

  

  
  

  


The proper call that should be generated is:

wevtutil im "C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.man" /rf:"C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.dll" /mf:"C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.dll"

Sadly the log only shows:

MSI (s) (8C:40) [10:33:52:580]: Executing op:
CustomActionSchedule(Action=RegisterEventManifest,ActionType=3073,Source=Bin
aryData,Target=CAQuietExec,CustomActionData="wevtutil.exe" im "C:\Program
Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.man")

I am not ruling out that there is an error in my EventManifest declaration -
the alternative would be a bug.

Now, before I am retiring towards just calling wevtutil manually in a custom
action. do I have something wrong in the WIX code?

Regards

Thomas

--
Managing the Performance of Cloud-Based Applications Take advantage of what
the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&

Re: [WiX-users] EventManifest - broken or wrong usage?

2014-02-04 Thread Georg von Kries 
If I remember correctly, the /rf and /mf parameters are replacing the
resourceFileName and messageFileName attributes in your manifest with the
provided paths. This is already done by the WIX custom action and the
parameters are therefore not required. You should verify that the file paths
are adjusted after the installation.

The error must be something else. 

Kind regards,
Georg



-Ursprüngliche Nachricht-
Von: Thomas Tomiczek [mailto:t.tomic...@nettecture.com] 
Gesendet: Dienstag, 4. Februar 2014 06:53
An: General discussion about the WiX toolset.
Betreff: Re: [WiX-users] EventManifest - broken or wrong usage?

Sorry to say, but I have validated it to work from the command line. The
WEVT should have 3 parameters  - im, /RF and /MF and the command line I do
see in the logs only has one. Care to explain that?

When I register all three manually it works.

When I rely on the WIX generated call, it does not. And, as I said, the
command line in the logs does not show /rf and /mf.

Regards

Thomas

-Original Message-
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: 03 February 2014 22:29
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] EventManifest - broken or wrong usage?

Hi,

your components are correct, I use it the same way and it is working
properly. IMHO the call to wevtutil in your log looks correct too, as the
custom action will adjust the resource and message file paths in the
manifest XML. No need to pass those to wevtutil.

If I remember correctly, the hard part for using ETW was not the
installation but to get the manifest and native resources right in .NET.
Also don't forget to close the event viewer when testing your
installation... 

Kind regards,
Georg von Kries


-Ursprüngliche Nachricht-
Von: Thomas Tomiczek [mailto:t.tomic...@nettecture.com]
Gesendet: Montag, 3. Februar 2014 10:46
An: General discussion for Windows Installer XML toolset.
(wix-users@lists.sourceforge.net)
Betreff: [WiX-users] EventManifest - broken or wrong usage?

After some more research the question again.

Is the EventManifest (in the utility namespace) broken or do I just use it
wrong?

EventManifest is the WIX version of wevtutil.

In order to properly register one needs three parameters - the manifest and
2x the compiled manifest.

Regardless how I am setting things up I am seemingly only able to get the
first one called, the other two parameters always are not used, as a result
the registration does not work. I checked the logs and I never see the 2nd
and 3rd parameter being called.

In the particular example, I am declaring the files as:

  

  
  

  


The proper call that should be generated is:

wevtutil im "C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.man" /rf:"C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.dll" /mf:"C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.dll"

Sadly the log only shows:

MSI (s) (8C:40) [10:33:52:580]: Executing op:
CustomActionSchedule(Action=RegisterEventManifest,ActionType=3073,Source=Bin
aryData,Target=CAQuietExec,CustomActionData="wevtutil.exe" im "C:\Program
Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.man")

I am not ruling out that there is an error in my EventManifest declaration -
the alternative would be a bug.

Now, before I am retiring towards just calling wevtutil manually in a custom
action. do I have something wrong in the WIX code?

Regards

Thomas

--
Managing the Performance of Cloud-Based Applications Take advantage of what
the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
Managing the Performance of Cloud-Based Applications Take advantage of what
the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Managing the Performance of Cloud-Based Applications Take advantage of what
the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/

Re: [WiX-users] EventManifest - broken or wrong usage?

2014-02-03 Thread Georg von Kries 
Hi,

your components are correct, I use it the same way and it is working
properly. IMHO the call to wevtutil in your log looks correct too, as the
custom action will adjust the resource and message file paths in the
manifest XML. No need to pass those to wevtutil.

If I remember correctly, the hard part for using ETW was not the
installation but to get the manifest and native resources right in .NET.
Also don't forget to close the event viewer when testing your
installation... 

Kind regards,
Georg von Kries


-Ursprüngliche Nachricht-
Von: Thomas Tomiczek [mailto:t.tomic...@nettecture.com] 
Gesendet: Montag, 3. Februar 2014 10:46
An: General discussion for Windows Installer XML toolset.
(wix-users@lists.sourceforge.net)
Betreff: [WiX-users] EventManifest - broken or wrong usage?

After some more research the question again.

Is the EventManifest (in the utility namespace) broken or do I just use it
wrong?

EventManifest is the WIX version of wevtutil.

In order to properly register one needs three parameters - the manifest and
2x the compiled manifest.

Regardless how I am setting things up I am seemingly only able to get the
first one called, the other two parameters always are not used, as a result
the registration does not work. I checked the logs and I never see the 2nd
and 3rd parameter being called.

In the particular example, I am declaring the files as:

  

  
  

  


The proper call that should be generated is:

wevtutil im "C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.man" /rf:"C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.dll" /mf:"C:\Program Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.dll"

Sadly the log only shows:

MSI (s) (8C:40) [10:33:52:580]: Executing op:
CustomActionSchedule(Action=RegisterEventManifest,ActionType=3073,Source=Bin
aryData,Target=CAQuietExec,CustomActionData="wevtutil.exe" im "C:\Program
Files
(x86)\Reflexo.GridAgent\Reflexo.GridAgent.EventSource.Reflexo-GridAgent-Even
tLog.etwManifest.man")

I am not ruling out that there is an error in my EventManifest declaration -
the alternative would be a bug.

Now, before I am retiring towards just calling wevtutil manually in a custom
action. do I have something wrong in the WIX code?

Regards

Thomas

--
Managing the Performance of Cloud-Based Applications Take advantage of what
the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] PatchCertificates element and Insignia.exe

2013-07-08 Thread Georg von Kries 
#3340 and #3341

Regards,
Georg

-Ursprüngliche Nachricht-
Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Gesendet: Montag, 8. Juli 2013 18:41
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe

Bug number / Link?

-Original Message-
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: Monday, July 08, 2013 11:39 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] PatchCertificates element and Insignia.exe

Done, I have just filed two bugs to keep both problems separated.

Kind regards,
Georg von Kries

-Ursprüngliche Nachricht-
Von: Blair Murri [mailto:os...@live.com]
Gesendet: Montag, 8. Juli 2013 17:22
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe

Sounds like a bug to me. Please file one.
 
> From: g...@creativbox.net
> To: wix-users@lists.sourceforge.net
> Date: Mon, 8 Jul 2013 16:54:00 +0200
> Subject: Re: [WiX-users] PatchCertificates element and Insignia.exe
> 
> Hi Jacob,
> 
> signing is indeed working without any problem. But if you have a 
>  element in your MSI, signing the MSI with insignia 
> (actually it is done by an MSbuild target) will change the included 
> certificates in the MsiDigitalCertificate table.
> 
> The following snipped (e.g. in product.wxs) will create entries in the 
> MSI tables MsiDigitalCertificate and MsiPatchCertificate:
> 
> 
>   
> 
> 
> The certificate will get the identifier "MyCertificate" which is 
> referenced in MsiPatchCertificate.
> 
> If you are now using external cabs and sign the MSI, the 
> "MyCertificate" is removed from the MsiDigitalCertificate table and a 
> new one is added for any external cab. They will get the certificates 
> thumbprint as the identifier but MsiPatchCertificate is still 
> referencing "MyCertificate" which will break the MSI IMHO.
> 
> It is currently not an issue for me, as I have no plans to use patches 
> in the near future. But I was asking myself if this is an bug or if I 
> did something wrong.
> 
> Thanks for your help,
> Georg
> 
> 
> -Ursprüngliche Nachricht-
> Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
> Gesendet: Montag, 8. Juli 2013 16:38
> An: General discussion for Windows Installer XML toolset.
> Cc: wix-users@lists.sourceforge.net
> Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe
> 
> I've been signing a msi and its external cabs without issue.
> 
> Can you provide the steps you are using to see if I can spot anything?
> 
> On Jul 8, 2013, at 9:30 AM, "Georg von Kries"  wrote:
> 
> > Hi all,
> > 
> > 
> > 
> > I've been using a  element in our installers for 
> > several years now, just in case we want to provide a patch and allow 
> > UAC
> patching.
> > After switching to use external cab files, I have mentioned that 
> > this is broken.
> > 
> > 
> > 
> > When using external cabs, singing them and inscribing the digital 
> > certificate via Insignia.exe, it will remove the certificates 
> > provided in the PatchCertificates element from the 
> > MsiDigitalCertificate table and add a new entry with the certificate 
> > used for singing the cab files. This is actually the same 
> > certificate (in our case), but the identifier in the
MsiDigitalCertificate table is being replaced.
> > Insignia (or actually the
> > Inscriber) will use the certificates thumbprint as the identifier. 
> > This invalidates the foreign key in the MsiPatchCertificate table.
> > 
> > Additionally I cannot just use the certificate thumbprint as the 
> > identifier in  the  element, because it might 
> > start with a number which makes it invalid as an identifier.
> > 
> > 
> > 
> > Therefore I think there are two bugs in the Inscriber. 
> > InscribeDatabase()
> > method:
> > 
> > 1.   It should not remove existing certificates from the
> > MsiDigitalCertificate table
> > 
> > 2.   The used identifier can be invalid, if the certificate
thumbprint
> > starts with a number. E.g. an underscore should be added at the 
> > beginning
> > 
> > 
> > 
> > Am I missing something or is this a known limitation/bug? 
> > 
> > 
> > 
> > Kind regards,
> > 
> > Georg von Kries
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> >  This SF.net email is sponsored by Windows:

Re: [WiX-users] PatchCertificates element and Insignia.exe

2013-07-08 Thread Georg von Kries 
Done, I have just filed two bugs to keep both problems separated.

Kind regards,
Georg von Kries

-Ursprüngliche Nachricht-
Von: Blair Murri [mailto:os...@live.com] 
Gesendet: Montag, 8. Juli 2013 17:22
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe

Sounds like a bug to me. Please file one.
 
> From: g...@creativbox.net
> To: wix-users@lists.sourceforge.net
> Date: Mon, 8 Jul 2013 16:54:00 +0200
> Subject: Re: [WiX-users] PatchCertificates element and Insignia.exe
> 
> Hi Jacob,
> 
> signing is indeed working without any problem. But if you have a 
>  element in your MSI, signing the MSI with insignia 
> (actually it is done by an MSbuild target) will change the included 
> certificates in the MsiDigitalCertificate table.
> 
> The following snipped (e.g. in product.wxs) will create entries in the 
> MSI tables MsiDigitalCertificate and MsiPatchCertificate:
> 
> 
>   
> 
> 
> The certificate will get the identifier "MyCertificate" which is 
> referenced in MsiPatchCertificate.
> 
> If you are now using external cabs and sign the MSI, the 
> "MyCertificate" is removed from the MsiDigitalCertificate table and a 
> new one is added for any external cab. They will get the certificates 
> thumbprint as the identifier but MsiPatchCertificate is still 
> referencing "MyCertificate" which will break the MSI IMHO.
> 
> It is currently not an issue for me, as I have no plans to use patches 
> in the near future. But I was asking myself if this is an bug or if I 
> did something wrong.
> 
> Thanks for your help,
> Georg
> 
> 
> -Ursprüngliche Nachricht-
> Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
> Gesendet: Montag, 8. Juli 2013 16:38
> An: General discussion for Windows Installer XML toolset.
> Cc: wix-users@lists.sourceforge.net
> Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe
> 
> I've been signing a msi and its external cabs without issue.
> 
> Can you provide the steps you are using to see if I can spot anything?
> 
> On Jul 8, 2013, at 9:30 AM, "Georg von Kries"  wrote:
> 
> > Hi all,
> > 
> > 
> > 
> > I've been using a  element in our installers for 
> > several years now, just in case we want to provide a patch and allow 
> > UAC
> patching.
> > After switching to use external cab files, I have mentioned that 
> > this is broken.
> > 
> > 
> > 
> > When using external cabs, singing them and inscribing the digital 
> > certificate via Insignia.exe, it will remove the certificates 
> > provided in the PatchCertificates element from the 
> > MsiDigitalCertificate table and add a new entry with the certificate 
> > used for singing the cab files. This is actually the same 
> > certificate (in our case), but the identifier in the
MsiDigitalCertificate table is being replaced.
> > Insignia (or actually the
> > Inscriber) will use the certificates thumbprint as the identifier. 
> > This invalidates the foreign key in the MsiPatchCertificate table.
> > 
> > Additionally I cannot just use the certificate thumbprint as the 
> > identifier in  the  element, because it might 
> > start with a number which makes it invalid as an identifier.
> > 
> > 
> > 
> > Therefore I think there are two bugs in the Inscriber. 
> > InscribeDatabase()
> > method:
> > 
> > 1.   It should not remove existing certificates from the
> > MsiDigitalCertificate table
> > 
> > 2.   The used identifier can be invalid, if the certificate
thumbprint
> > starts with a number. E.g. an underscore should be added at the 
> > beginning
> > 
> > 
> > 
> > Am I missing something or is this a known limitation/bug? 
> > 
> > 
> > 
> > Kind regards,
> > 
> > Georg von Kries
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> >  This SF.net email is sponsored by Windows:
> > 
> > Build for Windows Store.
> > 
> > http://p.sf.net/sfu/windows-dev2dev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> --
> --
> This SF.net email is sponsored by Windows:
> 
>

Re: [WiX-users] PatchCertificates element and Insignia.exe

2013-07-08 Thread Georg von Kries 
Hi David,

Looking at the Inscribe.cs source code, there is no entry added to the
MsiPatchCertificate table. So no, it's not doing everything for me.

Kind regards,
Georg von Kries



-Ursprüngliche Nachricht-
Von: David Watson [mailto:dwat...@sdl.com] 
Gesendet: Montag, 8. Juli 2013 17:24
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe

Does it work if you remove the PatchCertificates elements?

I.e. is insignia hand holding you and doing everything so you do not need
to?



-Original Message-
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: 08 July 2013 15:54
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] PatchCertificates element and Insignia.exe

Hi Jacob,

signing is indeed working without any problem. But if you have a
 element in your MSI, signing the MSI with insignia
(actually it is done by an MSbuild target) will change the included
certificates in the MsiDigitalCertificate table.

The following snipped (e.g. in product.wxs) will create entries in the MSI
tables MsiDigitalCertificate and MsiPatchCertificate:


  


The certificate will get the identifier "MyCertificate" which is referenced
in MsiPatchCertificate. 

If you are now using external cabs and sign the MSI, the "MyCertificate" is
removed from the MsiDigitalCertificate table and a new one is added for any
external cab. They will get the certificates thumbprint as the identifier
but MsiPatchCertificate is still referencing "MyCertificate" which will
break the MSI IMHO.

It is currently not an issue for me, as I have no plans to use patches in
the near future. But I was asking myself if this is an bug or if I did
something wrong.

Thanks for your help,
Georg


-Ursprüngliche Nachricht-
Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Gesendet: Montag, 8. Juli 2013 16:38
An: General discussion for Windows Installer XML toolset.
Cc: wix-users@lists.sourceforge.net
Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe

I've been signing a msi and its external cabs without issue.

Can you provide the steps you are using to see if I can spot anything?

On Jul 8, 2013, at 9:30 AM, "Georg von Kries"  wrote:

> Hi all,
> 
> 
> 
> I've been using a  element in our installers for 
> several years now, just in case we want to provide a patch and allow 
> UAC
patching.
> After switching to use external cab files, I have mentioned that this 
> is broken.
> 
> 
> 
> When using external cabs, singing them and inscribing the digital 
> certificate via Insignia.exe, it will remove the certificates provided 
> in the PatchCertificates element from the MsiDigitalCertificate table 
> and add a new entry with the certificate used for singing the cab 
> files. This is actually the same certificate (in our case), but the 
> identifier in the MsiDigitalCertificate table is being replaced.
> Insignia (or actually the
> Inscriber) will use the certificates thumbprint as the identifier. 
> This invalidates the foreign key in the MsiPatchCertificate table.
> 
> Additionally I cannot just use the certificate thumbprint as the 
> identifier in  the  element, because it might 
> start with a number which makes it invalid as an identifier.
> 
> 
> 
> Therefore I think there are two bugs in the Inscriber. 
> InscribeDatabase()
> method:
> 
> 1.   It should not remove existing certificates from the
> MsiDigitalCertificate table
> 
> 2.   The used identifier can be invalid, if the certificate thumbprint
> starts with a number. E.g. an underscore should be added at the 
> beginning
> 
> 
> 
> Am I missing something or is this a known limitation/bug? 
> 
> 
> 
> Kind regards,
> 
> Georg von Kries
> 
> 
> 
> 
> 
> --
>  This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




-
-
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
__

Re: [WiX-users] PatchCertificates element and Insignia.exe

2013-07-08 Thread Georg von Kries 
Hi Jacob,

signing is indeed working without any problem. But if you have a
 element in your MSI, signing the MSI with insignia
(actually it is done by an MSbuild target) will change the included
certificates in the MsiDigitalCertificate table.

The following snipped (e.g. in product.wxs) will create entries in the MSI
tables MsiDigitalCertificate and MsiPatchCertificate:


  


The certificate will get the identifier "MyCertificate" which is referenced
in MsiPatchCertificate. 

If you are now using external cabs and sign the MSI, the "MyCertificate" is
removed from the MsiDigitalCertificate table and a new one is added for any
external cab. They will get the certificates thumbprint as the identifier
but MsiPatchCertificate is still referencing "MyCertificate" which will
break the MSI IMHO.

It is currently not an issue for me, as I have no plans to use patches in
the near future. But I was asking myself if this is an bug or if I did
something wrong.

Thanks for your help,
Georg


-Ursprüngliche Nachricht-
Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Gesendet: Montag, 8. Juli 2013 16:38
An: General discussion for Windows Installer XML toolset.
Cc: wix-users@lists.sourceforge.net
Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe

I've been signing a msi and its external cabs without issue.

Can you provide the steps you are using to see if I can spot anything?

On Jul 8, 2013, at 9:30 AM, "Georg von Kries"  wrote:

> Hi all,
> 
> 
> 
> I've been using a  element in our installers for 
> several years now, just in case we want to provide a patch and allow UAC
patching.
> After switching to use external cab files, I have mentioned that this 
> is broken.
> 
> 
> 
> When using external cabs, singing them and inscribing the digital 
> certificate via Insignia.exe, it will remove the certificates provided 
> in the PatchCertificates element from the MsiDigitalCertificate table 
> and add a new entry with the certificate used for singing the cab 
> files. This is actually the same certificate (in our case), but the 
> identifier in the MsiDigitalCertificate table is being replaced. 
> Insignia (or actually the
> Inscriber) will use the certificates thumbprint as the identifier. 
> This invalidates the foreign key in the MsiPatchCertificate table.
> 
> Additionally I cannot just use the certificate thumbprint as the 
> identifier in  the  element, because it might 
> start with a number which makes it invalid as an identifier.
> 
> 
> 
> Therefore I think there are two bugs in the Inscriber. 
> InscribeDatabase()
> method:
> 
> 1.   It should not remove existing certificates from the
> MsiDigitalCertificate table
> 
> 2.   The used identifier can be invalid, if the certificate thumbprint
> starts with a number. E.g. an underscore should be added at the 
> beginning
> 
> 
> 
> Am I missing something or is this a known limitation/bug? 
> 
> 
> 
> Kind regards,
> 
> Georg von Kries
> 
> 
> 
> 
> 
> --
>  This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] PatchCertificates element and Insignia.exe

2013-07-08 Thread Georg von Kries 
Hi all,

 

I've been using a  element in our installers for several
years now, just in case we want to provide a patch and allow UAC patching.
After switching to use external cab files, I have mentioned that this is
broken. 

 

When using external cabs, singing them and inscribing the digital
certificate via Insignia.exe, it will remove the certificates provided in
the PatchCertificates element from the MsiDigitalCertificate table and add a
new entry with the certificate used for singing the cab files. This is
actually the same certificate (in our case), but the identifier in the
MsiDigitalCertificate table is being replaced. Insignia (or actually the
Inscriber) will use the certificates thumbprint as the identifier. This
invalidates the foreign key in the MsiPatchCertificate table.

Additionally I cannot just use the certificate thumbprint as the identifier
in  the  element, because it might start with a number
which makes it invalid as an identifier. 

 

Therefore I think there are two bugs in the Inscriber. InscribeDatabase()
method:

1.   It should not remove existing certificates from the
MsiDigitalCertificate table

2.   The used identifier can be invalid, if the certificate thumbprint
starts with a number. E.g. an underscore should be added at the beginning

 

Am I missing something or is this a known limitation/bug? 

 

Kind regards,

Georg von Kries

 

 

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] util:RegistrySearch

2012-10-26 Thread Georg von Kries 
Hi Neil!

There is no need for the Util extension in an MSI for a registry search.
Just use the normal RegistrySearch element (from the Wix schema) which
populates MSIs RegLocator table. Because of this I think it is burn
specific.

Regards,
Georg von Kries


-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com] 
Gesendet: Freitag, 26. Oktober 2012 18:18
An: General toolset. (wix-users@lists.sourceforge.net)
Betreff: [WiX-users] util:RegistrySearch

Can the util:RegistrySearch be used in an MSI or is it burn specific?

Neil

Neil Sleightholm
X2 Systems Limited
n...@x2systems.com<mailto:n...@x2systems.com>


--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn and Files in Use / Restart Manager

2012-10-23 Thread Georg von Kries 
Hello Neil,

thanks again for your help. If I have some time I will implement this
feature. Maybe someone else will find it useful too. 

Regards,
Georg

-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com] 
Gesendet: Dienstag, 23. Oktober 2012 12:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Burn and Files in Use / Restart Manager

I see the problem, what you would probably need is a close application
function within the bootstrapper - not something that is available today
(may be add it as a feature request). 

Not pretty but you could block the install if Outlook is running (not
entirely sure how to detect that) and get the user to shut it down before
the install will run.

Neil

-Original Message-
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: 23 October 2012 10:19
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Burn and Files in Use / Restart Manager

Hi Neil,

thanks for your suggestion. In my case there is an Outlook add-in installed
together with our application. We cannot just close Outlook without asking
the user and I don't see a possibility to show just a single internal MSI
dialog for prompting the user to close Outlook. Am I missing something here?

Regards,
Georg   

-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Dienstag, 23. Oktober 2012 08:09
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Burn and Files in Use / Restart Manager

What I do in this scenario is scan the logs to find out what files are in
use and causing the reboot - look for a return code of 3010 from one of your
MSIs - burn will only do a reboot if one of the packages (MSI or EXE)
requests it. Once you know that you can decide how to handle it more
effectively. For example, if a service is running you can stop it, if it is
an application you can use the WiX CloseApplication element.

Hope this helps.

Neil

-Original Message-----
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: 22 October 2012 21:15
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Burn and Files in Use / Restart Manager

Hi all,

I've been successfully using WiX for a long time now and I'm very happy with
it. Many thanks for all the effort you are putting into this project.

Currently I'm using WiX together with a standard Visual Studio bootstrapper
for .NET and other prerequisites. I want to replace this with Burn which
seems to be a very nice solution. All is working very good and using Burn is
mostly straightforward. 

But one thing bothers me: There seems to be no standard way for dealing with
files in use and especially together with the restart manager. Burn will by
default always trigger a restart/ask for restarting if something is in use.
For normal applications this is very annoying for users. Additionally if I
remember correctly there was a Windows logo requirement which disallows this
practice. Therefore I'm currently trying to extend the standard bootstrapper
application (unmanaged) with "files in use" and restart manager
capabilities. 

My current understanding is that this is not possible for an bootstrapper
application without changing the engine. E.g. it seems OnExecuteFilesInUse()
is never called for MSI packages; not even thinking about the Windows
installer message INSTALLMESSAGE_RMFILESINUSE for using restart manager. I'm
no windows installer or WiX guru, but when looking at the Burn source there
is no message filter added for either INSTALLLOG_FILESINUSE or (if supported
by the installer version) INSTALLLOGMODE_RMFILESINUSE when the external UI
is initialized. But I might be missing something here.

I've started playing around with the Burn 3.7 source (because it's using
MSBuild only) and got the messages working, but there are other side
effects. E.g. the engine will always suppress results from the UI trying to
pass only expected values back to the installer; but in case of the restart
manager there are more possibilities which are not included into the
message.

I just wanted to ask what the plans are for supporting this functionality or
if I'm totally going into the wrong direction and there is an obvious
solution I'm not aware of. 

Thanks for reading!

Yours sincerely,
Georg von Kries




--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for
free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Everyone hates slow websites. So do we.
Make your web apps faster with App

Re: [WiX-users] Burn and Files in Use / Restart Manager

2012-10-23 Thread Georg von Kries 
Hi Neil,

thanks for your suggestion. In my case there is an Outlook add-in installed
together with our application. We cannot just close Outlook without asking
the user and I don't see a possibility to show just a single internal MSI
dialog for prompting the user to close Outlook. Am I missing something here?

Regards,
Georg   

-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com] 
Gesendet: Dienstag, 23. Oktober 2012 08:09
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Burn and Files in Use / Restart Manager

What I do in this scenario is scan the logs to find out what files are in
use and causing the reboot - look for a return code of 3010 from one of your
MSIs - burn will only do a reboot if one of the packages (MSI or EXE)
requests it. Once you know that you can decide how to handle it more
effectively. For example, if a service is running you can stop it, if it is
an application you can use the WiX CloseApplication element.

Hope this helps.

Neil

-Original Message-
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: 22 October 2012 21:15
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Burn and Files in Use / Restart Manager

Hi all,

I've been successfully using WiX for a long time now and I'm very happy with
it. Many thanks for all the effort you are putting into this project.

Currently I'm using WiX together with a standard Visual Studio bootstrapper
for .NET and other prerequisites. I want to replace this with Burn which
seems to be a very nice solution. All is working very good and using Burn is
mostly straightforward. 

But one thing bothers me: There seems to be no standard way for dealing with
files in use and especially together with the restart manager. Burn will by
default always trigger a restart/ask for restarting if something is in use.
For normal applications this is very annoying for users. Additionally if I
remember correctly there was a Windows logo requirement which disallows this
practice. Therefore I'm currently trying to extend the standard bootstrapper
application (unmanaged) with "files in use" and restart manager
capabilities. 

My current understanding is that this is not possible for an bootstrapper
application without changing the engine. E.g. it seems OnExecuteFilesInUse()
is never called for MSI packages; not even thinking about the Windows
installer message INSTALLMESSAGE_RMFILESINUSE for using restart manager. I'm
no windows installer or WiX guru, but when looking at the Burn source there
is no message filter added for either INSTALLLOG_FILESINUSE or (if supported
by the installer version) INSTALLLOGMODE_RMFILESINUSE when the external UI
is initialized. But I might be missing something here.

I've started playing around with the Burn 3.7 source (because it's using
MSBuild only) and got the messages working, but there are other side
effects. E.g. the engine will always suppress results from the UI trying to
pass only expected values back to the installer; but in case of the restart
manager there are more possibilities which are not included into the
message.

I just wanted to ask what the plans are for supporting this functionality or
if I'm totally going into the wrong direction and there is an obvious
solution I'm not aware of. 

Thanks for reading!

Yours sincerely,
Georg von Kries




--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for
free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for
free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Burn and Files in Use / Restart Manager

2012-10-22 Thread Georg von Kries 
Hi all,

I've been successfully using WiX for a long time now and I'm very happy with
it. Many thanks for all the effort you are putting into this project.

Currently I'm using WiX together with a standard Visual Studio bootstrapper
for .NET and other prerequisites. I want to replace this with Burn which
seems to be a very nice solution. All is working very good and using Burn is
mostly straightforward. 

But one thing bothers me: There seems to be no standard way for dealing with
files in use and especially together with the restart manager. Burn will by
default always trigger a restart/ask for restarting if something is in use.
For normal applications this is very annoying for users. Additionally if I
remember correctly there was a Windows logo requirement which disallows this
practice. Therefore I'm currently trying to extend the standard bootstrapper
application (unmanaged) with "files in use" and restart manager
capabilities. 

My current understanding is that this is not possible for an bootstrapper
application without changing the engine. E.g. it seems OnExecuteFilesInUse()
is never called for MSI packages; not even thinking about the Windows
installer message INSTALLMESSAGE_RMFILESINUSE for using restart manager. I'm
no windows installer or WiX guru, but when looking at the Burn source there
is no message filter added for either INSTALLLOG_FILESINUSE or (if supported
by the installer version) INSTALLLOGMODE_RMFILESINUSE when the external UI
is initialized. But I might be missing something here.

I've started playing around with the Burn 3.7 source (because it's using
MSBuild only) and got the messages working, but there are other side
effects. E.g. the engine will always suppress results from the UI trying to
pass only expected values back to the installer; but in case of the restart
manager there are more possibilities which are not included into the
message.

I just wanted to ask what the plans are for supporting this functionality or
if I'm totally going into the wrong direction and there is an obvious
solution I'm not aware of. 

Thanks for reading!

Yours sincerely,
Georg von Kries



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users