[WiX-users] GUI log

2012-08-29 Thread Subbiah Ganesan
Hi,

I am using Wix3.6. Is there some way to log the happenings of an installer
by default(like setting some property) when it is started by double click
and not by msiexec.exe because most end-users will do this.
Also is there a way to show the current action running or the feature
getting installed in the gui?
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Installing Windows Features with Burn

2012-08-29 Thread Neil Sleightholm
This has come up a couple of times recently so here is my solution.

Create a stub application to run ocsetup e.g.:

namespace OcsRunner
{
using System;
using System.Diagnostics;

public class Program
{
public static int Main(string[] args)
{
var startInfo = new ProcessStartInfo();

startInfo.FileName = ocsetup.exe;
startInfo.Arguments = String.Join( , args) +  /norestart /quiet;
startInfo.WindowStyle = ProcessWindowStyle.Hidden;
startInfo.UseShellExecute = false;

var p = new Process();
p.StartInfo = startInfo;
p.Start();
p.WaitForExit();

return p.ExitCode;
}
}
}

Call this from your bundle like this:

?define Win2k8ServerR2 = (VersionNT = v6.1 AND NOT (NTProductType = 1)) ?

  Fragment
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net Framework 
Setup\NDP\v3.5 Value=Version Variable=Netfx35Version /
  !-- Use Ocsetup on Windows 8 or Windows Server 2008 R2 --
  ExePackage Id=NetFx35OcsSetup
DisplayName=.NET Framework 3.5
Cache=no
Compressed=yes
PerMachine=yes
Permanent=yes
Vital=yes
Name=Redist\OcsRunner.exe
SourceFile=Packages\OcsRunner.exe
InstallCommand=NetFx3
DetectCondition=Netfx35Version AND (Netfx35Version gt;= v3.5.30729.1)
InstallCondition=(VersionNT gt;= v6.2) OR $(var.Win2k8ServerR2)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
  /Fragment

This example installs .NET 3.5 on Windows Server 2008 R2 and Windows 8 but you 
can replace the InstallCommand and DetectCondition to install other features.

Neil

Neil Sleightholm
X2 Systems Limited
n...@x2systems.commailto:n...@x2systems.com

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Windows 8 NetFX3.5

2012-08-29 Thread Neil Hayes
Interesting

Windows 8 say's (ocsetup  /? ) OCSETUP has been deprecated. Please update your 
scripts to use DISM.exe to add or remove optional components from your system.

I see this being a serious problem in deploying software timeously, before I 
could just install the .NET Framework, now it looks like putting 30 machines 
through the IT dept to get the framework rolled out before I can deploy.

I'd hate for one of our techies to get to a remote location to find the IT dept 
missed 5 machines and they can't do anything about it.

Take a local university, just 30 odd users, no internet access, no Windows 8 
source available. Windows updates managed by group policy.

Open to suggestions.

Neil

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Managed Custom Action using CAS

2012-08-29 Thread Christoffel le Roux
Hi thanks for all the help, I resolved my issue by just reverting the custom 
action back to .net 2 and specifying the correct framework version in my custom 
action configuration file. 

This was the simplest way to support the older installer code. As stated by 
Jacob there wasn't any reason for the custom action to be on runtime 2 as well, 

as updating the plugin to use a newer CAS model for newer versions of office 
was not currently an option.


Kind regards,
Christoffel le Roux


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: Tuesday, August 28, 2012 7:30 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Managed Custom Action using CAS

I've never done one of those myself, but a bit of search engine foo shows a few 
potential links 
http://social.msdn.microsoft.com/Forums/eu/vsto/thread/f46b54a0-0fc3-4a76-a47c-aad05e31bb86
 , 
http://social.msdn.microsoft.com/Forums/en/vsto/thread/890cb60c-11f6-4fea-8a44-e520341f3331
 , and 
http://stackoverflow.com/questions/3089567/is-it-possible-to-create-an-office-2003-vsto-add-in-from-visual-studio-2010
 . From the second link I find:

Different Visual Studio Versions
 
1. Visual Studio 2010 supports creating VSTO 3.0 and VSTO 4.0 solutions.
 
2. Visual Studio 2008 supports creating VSTO 2.0 and VSTO 3.0 solutions.
 
-
 
Different VSTO Versions
 
1. VSTO 2.0 solutions work with Office 2003 and Office 2007
 
2. VSTO 3.0 solutions work with Office 2007 and Office 2010
 
-

Since you stated you needed an Office 2003 VSTO, I don't think it would be 
possible to have it using the 4.0 framework (for the addin). As such, what 
benefit are you getting by upgrading the CA DLL? If you need the old behavior 
and a new feature then you could have 2 CA DLL's; one targeting 4.0 for the new 
stuff and one targeting 2.0 for the old CAS calls.

If you want to continue to try to get 4.0 to work, then the actual framework 
call that is failing (the source to CustomAction.GetPolicyLevel ) would be 
helpful.


-Original Message-
From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com]
Sent: Tuesday, August 28, 2012 9:33 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Managed Custom Action using CAS

Hi Jacob, 

Thanks for the reply, I'm installing an office 2003 VSTO project and using the 
custom action which in turn needs the CAS policy methods to register the DLL as 
safe to be consumed by Office.

Kind regards,
Christoffel le Roux


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, August 28, 2012 4:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Managed Custom Action using CAS

I guess the real question would be do you even need this in .Net 4? 
http://blogs.msdn.com/b/shawnfa/archive/2010/02/24/so-is-cas-dead-in-net-4-or-what.aspx
 What is the custom action trying to accomplish with CAS?


-Original Message-
From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com]
Sent: Tuesday, August 28, 2012 9:12 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Managed Custom Action using CAS

Hi, I have upgraded an old installer to a wix 3.7 custom action project that 
uses the old CAS policy methods. I've upgraded the solution to runtime 4 and 
resulted receiving the exception

This method explicitly uses CAS policy, which has been obsoleted by the .NET 
Framework.

// Get the policy level.
PolicyLevel policyLevel = CustomAction.GetPolicyLevel(SomePolicyLabel);

In order to enable CAS policy for compatibility reasons,

please use the NetFx40_LegacySecurityPolicy configuration switch. Please see 
http://go.microsoft.com/fwlink/?LinkID=155570 for more information.

Following the link I ended up specifying in the CustomAction.config file to use 
the legacy CAS method overloads.

?xml version=1.0 encoding=utf-8 ?
configuration
startup useLegacyV2RuntimeActivationPolicy=true
supportedRuntime version=v4.0 sku=.NETFramework,Version=v4.0/
supportedRuntime version=v2.0.50727/
/startup
  runtime
NetFx40_LegacySecurityPolicy enabled=true/
  /runtime
/configuration

I've tried a bunch of things to resolve the issue but with no luck.

Any ideas anyone?

Thanks in advanced.

Kind regards,
Christoffel le Roux
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net

Re: [WiX-users] Windows 8 NetFX3.5

2012-08-29 Thread Neil Hayes
I think this probably sums it up, fail deployment until the .NET Framework 3.5 
is installed, or deploy without it and rely on the shim prompting for 
installation.

http://msdn.microsoft.com/en-us/library/windows/hardware/hh975396.aspx

Neil

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Windows 8 NetFX3.5

2012-08-29 Thread Neil Sleightholm
I hadn't noticed that in Windows 8. You could call dism in the same way - see 
my post Installing Windows Features with Burn. As far as I am aware you don't 
need internet access or the original media, .NET 3.5 is just a feature that 
needs enabling.

Neil

-Original Message-
From: Neil Hayes [mailto:neil.ha...@syspro.com] 
Sent: 29 August 2012 08:14
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows 8 NetFX3.5

Interesting

Windows 8 say's (ocsetup  /? ) OCSETUP has been deprecated. Please update your 
scripts to use DISM.exe to add or remove optional components from your system.

I see this being a serious problem in deploying software timeously, before I 
could just install the .NET Framework, now it looks like putting 30 machines 
through the IT dept to get the framework rolled out before I can deploy.

I'd hate for one of our techies to get to a remote location to find the IT dept 
missed 5 machines and they can't do anything about it.

Take a local university, just 30 odd users, no internet access, no Windows 8 
source available. Windows updates managed by group policy.

Open to suggestions.

Neil

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?

2012-08-29 Thread Christian Hausknecht
Ok, my idea was good, but there is a problem with it. Burn does not support 
searching *during* the installation process. So even if I have the correct 
sequence in my chain, the RegistrySearch is always done at the beginning before 
any packages are executed :-( Therefore my little helper program has not been 
called yet when the search happens and so the key is not found.

I found the answer here: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html

I did not recognize that, as I do not delete the key after uninstall. So my 
installer always found one as it was written in the previous installation 
process...

So back to brainstorming... I think only a custom action can help me now? (That 
I can place in my MsiPackage and call it before any other actions?)

Damn, I wished I could get around that... imho creating your own CA looks quite 
difficult...

Bet regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de] 
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Hm... no answer yet? Are my questions not understandable or too strange? ;-)

Ok, as perhaps some users might be interested in a solution, I present the way 
I have chosen for now:

Basic Idea is to simply write a small C# Program, that gets the Path from a wix 
burn bundle via CLI, shortens it by removing the ``setup.exe``-part and write 
the result (the plain source path) into a defined registry key. Other 
components of an installer bundle can retrieve this key and use the information 
for further setup process.

The Mini-Program look like this:

namespace RegisterPath
{
class Program
{
static void Main(string[] args)
{
Registry.SetValue(string.Format(@{0}\{1}, 
RegisterPath.Properties.Resources.root, RegisterPath.Properties.Resources.key),
RegisterPath.Properties.Resources.valuename, 
Path.GetDirectoryName(args[0]));
}
}
}

As you can see I use resource-strings for the definition of the registry key.

The fragment within the burn bundle to call the programm:

  Fragment
PackageGroup Id=RegisterPath
  ExePackage Name=RegisterPath.exe Id=RegisterPath_PK
  SourceFile=$(var.RegisterPathPath) 
InstallCommand='[WixBundleOriginalSource]'
  Cache=no Compressed=yes PerMachine=yes Vital=yes/
/PackageGroup
 /Fragment


As you can see I use the ``WixBundleOriginalSource``-variable provided from 
burn (Which is the heart of the problem ;-) ).

Further down in my bundle package I refer to this in order to provide the path 
to a Msi-Package:

  Fragment
  util:RegistrySearch Id=BasePathSearch
   Variable=BASEPATHPROP
   Root=HKCU
   Key=Software\$(var.Manufacturer)
   Result=value
   Value=BasePath /

PackageGroup Id=ClientMsi
  MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYBASEPATH Value=[BASEPATHPROP]\/
  /MsiPackage
/PackageGroup

  /Fragment

One must take care that the Properties of the C#-Program and the attributes of 
the RegistrySearch within the wix bundle are equal. Normally that does not 
change too often, so I can live with that workaround for the moment.

Of course I would appreciate a more elegant solution; the best would be a 
predefined variable by burn itself ;-)


Best regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Montag, 27. August 2012 13:00
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, I kept thinking about the problem and I have an idea, that probably could 
lead to the right direction.

I can define a msi-property within the bundle definition to that one must 
assign the current path and that can be used within the MSI package definition 
as reference. I tried the following approach:

!-- Define MsiProperty within the burn bundle file -- MsiPackage 
SourceFile=$(var.ClientMSIPath)
  MsiProperty Name=MYSOURCEDIR Value=[WixBundleOriginalSource]\/
/MsiPackage

!-- Reference the property within the MSI definition -- Shortcut 
Id=Foo_ShortCut
  Name=Foo
  Description=Foo
  Target=[MYSOURCEDIR]Foo.exe
  WorkingDirectory=ProgramFilesFolder/

That would work fine besides the wix variable `` WixBundleOriginalSource`` 
holds not only the path of the starting dir but the complete path *including* 
the exe-filename :-( Is there any way to trim the value or maybe another 
burn-variable, that holds only the path?


-Ursprüngliche Nachricht-
Von: Christian Hausknecht 

Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?

2012-08-29 Thread Neil Sleightholm
Just stepping back at bit but why do you need the source of the burn install 
passed into your MSI?

Neil

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de] 
Sent: 29 August 2012 10:39
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, my idea was good, but there is a problem with it. Burn does not support 
searching *during* the installation process. So even if I have the correct 
sequence in my chain, the RegistrySearch is always done at the beginning before 
any packages are executed :-( Therefore my little helper program has not been 
called yet when the search happens and so the key is not found.

I found the answer here: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html

I did not recognize that, as I do not delete the key after uninstall. So my 
installer always found one as it was written in the previous installation 
process...

So back to brainstorming... I think only a custom action can help me now? (That 
I can place in my MsiPackage and call it before any other actions?)

Damn, I wished I could get around that... imho creating your own CA looks quite 
difficult...

Bet regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Hm... no answer yet? Are my questions not understandable or too strange? ;-)

Ok, as perhaps some users might be interested in a solution, I present the way 
I have chosen for now:

Basic Idea is to simply write a small C# Program, that gets the Path from a wix 
burn bundle via CLI, shortens it by removing the ``setup.exe``-part and write 
the result (the plain source path) into a defined registry key. Other 
components of an installer bundle can retrieve this key and use the information 
for further setup process.

The Mini-Program look like this:

namespace RegisterPath
{
class Program
{
static void Main(string[] args)
{
Registry.SetValue(string.Format(@{0}\{1}, 
RegisterPath.Properties.Resources.root, RegisterPath.Properties.Resources.key),
RegisterPath.Properties.Resources.valuename, 
Path.GetDirectoryName(args[0]));
}
}
}

As you can see I use resource-strings for the definition of the registry key.

The fragment within the burn bundle to call the programm:

  Fragment
PackageGroup Id=RegisterPath
  ExePackage Name=RegisterPath.exe Id=RegisterPath_PK
  SourceFile=$(var.RegisterPathPath) 
InstallCommand='[WixBundleOriginalSource]'
  Cache=no Compressed=yes PerMachine=yes Vital=yes/
/PackageGroup
 /Fragment


As you can see I use the ``WixBundleOriginalSource``-variable provided from 
burn (Which is the heart of the problem ;-) ).

Further down in my bundle package I refer to this in order to provide the path 
to a Msi-Package:

  Fragment
  util:RegistrySearch Id=BasePathSearch
   Variable=BASEPATHPROP
   Root=HKCU
   Key=Software\$(var.Manufacturer)
   Result=value
   Value=BasePath /

PackageGroup Id=ClientMsi
  MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYBASEPATH Value=[BASEPATHPROP]\/
  /MsiPackage
/PackageGroup

  /Fragment

One must take care that the Properties of the C#-Program and the attributes of 
the RegistrySearch within the wix bundle are equal. Normally that does not 
change too often, so I can live with that workaround for the moment.

Of course I would appreciate a more elegant solution; the best would be a 
predefined variable by burn itself ;-)


Best regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Montag, 27. August 2012 13:00
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, I kept thinking about the problem and I have an idea, that probably could 
lead to the right direction.

I can define a msi-property within the bundle definition to that one must 
assign the current path and that can be used within the MSI package definition 
as reference. I tried the following approach:

!-- Define MsiProperty within the burn bundle file -- MsiPackage 
SourceFile=$(var.ClientMSIPath)
  MsiProperty Name=MYSOURCEDIR Value=[WixBundleOriginalSource]\/
/MsiPackage

!-- Reference the property within the MSI definition -- Shortcut 
Id=Foo_ShortCut
  Name=Foo
  Description=Foo
  Target=[MYSOURCEDIR]Foo.exe
  

Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?

2012-08-29 Thread Christian Hausknecht
Ok, I try to explain the background:

The installer will be located in a remote folder in which most executables of 
the client are located. The Clients are practically not really installed on the 
local machine, only Shortcuts with the path to the executables on the remote 
folder are generated (besides some other stuff).

Therefore I need the path, from which the installer was called. As I wrote at 
the beginning, burn only offers a *complete path* including the name of the 
installer (e.g. ``Z:\Foo\Bar\setup.exe``). I need the path without the 
installer name.

That's the problem I have to solve :-)

-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com] 
Gesendet: Mittwoch, 29. August 2012 11:41
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Just stepping back at bit but why do you need the source of the burn install 
passed into your MSI?

Neil

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 10:39
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, my idea was good, but there is a problem with it. Burn does not support 
searching *during* the installation process. So even if I have the correct 
sequence in my chain, the RegistrySearch is always done at the beginning before 
any packages are executed :-( Therefore my little helper program has not been 
called yet when the search happens and so the key is not found.

I found the answer here: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html

I did not recognize that, as I do not delete the key after uninstall. So my 
installer always found one as it was written in the previous installation 
process...

So back to brainstorming... I think only a custom action can help me now? (That 
I can place in my MsiPackage and call it before any other actions?)

Damn, I wished I could get around that... imho creating your own CA looks quite 
difficult...

Bet regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Hm... no answer yet? Are my questions not understandable or too strange? ;-)

Ok, as perhaps some users might be interested in a solution, I present the way 
I have chosen for now:

Basic Idea is to simply write a small C# Program, that gets the Path from a wix 
burn bundle via CLI, shortens it by removing the ``setup.exe``-part and write 
the result (the plain source path) into a defined registry key. Other 
components of an installer bundle can retrieve this key and use the information 
for further setup process.

The Mini-Program look like this:

namespace RegisterPath
{
class Program
{
static void Main(string[] args)
{
Registry.SetValue(string.Format(@{0}\{1}, 
RegisterPath.Properties.Resources.root, RegisterPath.Properties.Resources.key),
RegisterPath.Properties.Resources.valuename, 
Path.GetDirectoryName(args[0]));
}
}
}

As you can see I use resource-strings for the definition of the registry key.

The fragment within the burn bundle to call the programm:

  Fragment
PackageGroup Id=RegisterPath
  ExePackage Name=RegisterPath.exe Id=RegisterPath_PK
  SourceFile=$(var.RegisterPathPath) 
InstallCommand='[WixBundleOriginalSource]'
  Cache=no Compressed=yes PerMachine=yes Vital=yes/
/PackageGroup
 /Fragment


As you can see I use the ``WixBundleOriginalSource``-variable provided from 
burn (Which is the heart of the problem ;-) ).

Further down in my bundle package I refer to this in order to provide the path 
to a Msi-Package:

  Fragment
  util:RegistrySearch Id=BasePathSearch
   Variable=BASEPATHPROP
   Root=HKCU
   Key=Software\$(var.Manufacturer)
   Result=value
   Value=BasePath /

PackageGroup Id=ClientMsi
  MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYBASEPATH Value=[BASEPATHPROP]\/
  /MsiPackage
/PackageGroup

  /Fragment

One must take care that the Properties of the C#-Program and the attributes of 
the RegistrySearch within the wix bundle are equal. Normally that does not 
change too often, so I can live with that workaround for the moment.

Of course I would appreciate a more elegant solution; the best would be a 
predefined variable by burn itself ;-)


Best regards,


-Ursprüngliche Nachricht-
Von: Christian 

Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?

2012-08-29 Thread Neil Sleightholm
Sorry but I can't really help - that is quite an odd requirement and I am not 
sure how burn will work on upgrade and repair as the code won't be running from 
your folder.

Neil

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de] 
Sent: 29 August 2012 10:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, I try to explain the background:

The installer will be located in a remote folder in which most executables of 
the client are located. The Clients are practically not really installed on the 
local machine, only Shortcuts with the path to the executables on the remote 
folder are generated (besides some other stuff).

Therefore I need the path, from which the installer was called. As I wrote at 
the beginning, burn only offers a *complete path* including the name of the 
installer (e.g. ``Z:\Foo\Bar\setup.exe``). I need the path without the 
installer name.

That's the problem I have to solve :-)

-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Mittwoch, 29. August 2012 11:41
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Just stepping back at bit but why do you need the source of the burn install 
passed into your MSI?

Neil

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 10:39
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, my idea was good, but there is a problem with it. Burn does not support 
searching *during* the installation process. So even if I have the correct 
sequence in my chain, the RegistrySearch is always done at the beginning before 
any packages are executed :-( Therefore my little helper program has not been 
called yet when the search happens and so the key is not found.

I found the answer here: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html

I did not recognize that, as I do not delete the key after uninstall. So my 
installer always found one as it was written in the previous installation 
process...

So back to brainstorming... I think only a custom action can help me now? (That 
I can place in my MsiPackage and call it before any other actions?)

Damn, I wished I could get around that... imho creating your own CA looks quite 
difficult...

Bet regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Hm... no answer yet? Are my questions not understandable or too strange? ;-)

Ok, as perhaps some users might be interested in a solution, I present the way 
I have chosen for now:

Basic Idea is to simply write a small C# Program, that gets the Path from a wix 
burn bundle via CLI, shortens it by removing the ``setup.exe``-part and write 
the result (the plain source path) into a defined registry key. Other 
components of an installer bundle can retrieve this key and use the information 
for further setup process.

The Mini-Program look like this:

namespace RegisterPath
{
class Program
{
static void Main(string[] args)
{
Registry.SetValue(string.Format(@{0}\{1}, 
RegisterPath.Properties.Resources.root, RegisterPath.Properties.Resources.key),
RegisterPath.Properties.Resources.valuename, 
Path.GetDirectoryName(args[0]));
}
}
}

As you can see I use resource-strings for the definition of the registry key.

The fragment within the burn bundle to call the programm:

  Fragment
PackageGroup Id=RegisterPath
  ExePackage Name=RegisterPath.exe Id=RegisterPath_PK
  SourceFile=$(var.RegisterPathPath) 
InstallCommand='[WixBundleOriginalSource]'
  Cache=no Compressed=yes PerMachine=yes Vital=yes/
/PackageGroup
 /Fragment


As you can see I use the ``WixBundleOriginalSource``-variable provided from 
burn (Which is the heart of the problem ;-) ).

Further down in my bundle package I refer to this in order to provide the path 
to a Msi-Package:

  Fragment
  util:RegistrySearch Id=BasePathSearch
   Variable=BASEPATHPROP
   Root=HKCU
   Key=Software\$(var.Manufacturer)
   Result=value
   Value=BasePath /

PackageGroup Id=ClientMsi
  MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYBASEPATH Value=[BASEPATHPROP]\/
  /MsiPackage

[WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Natalie Carr
Hi, Hope someone can help me. I'm trying to install the Visual C++
redistributables file vcredist_x86.exe

 

I can't use merge modules as I've been asked to use this one EXE file. I
added it to a bootstrapper using this code:

ItemGroup

BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

  ProductNameMicrosoft Visual C++ Redistributables/ProductName

/BootstrapperFile

/ItemGroup

 

Target Name=AfterBuild

GenerateBootstrapper ApplicationFile=$(TargetFileName)
ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
ComponentsLocation=Relative CopyComponents=True
OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\ /

/Target

 

 

But this installs the prerequisites at the beginning and I have been asked
to show our welcome dialog and then do a registry search to see if the
appropriate files are installed. If they are not to call the
vcredist_x86.exe file. 

 

Can this be done?

I'm trying this but cannot get it to work.

 

   CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
Property=QtExecDeferredExampleWithProperty
Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA
DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/

 

   

InstallExecuteSequence

  Custom Action=QtExecDeferredExampleWithProperty_Cmd
After=CostFinalize/

  Custom Action=QtExecDeferredExampleWithProperty
After=InstallInitialize/

/InstallExecuteSequence

 

 

Kind Regards,

 

Natalie Carr

 

 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Neil Sleightholm
I'd suggest using burn to do this; this is the code I am using to install 
vcredist.

?xml version=1.0 encoding=utf-8?
?define vcredist_x86 =  
http://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-795376989c03/vcredist_x86.exe
 ?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; 
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
  Fragment
util:RegistrySearch Root=HKLM 
Key=SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0\RED\1033 Value=SP 
Variable=vcredist /
PackageGroup Id=vcredist
  ExePackage Id=vcredist_x86
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
Name=Redist\vcredist_x86.exe
SourceFile=Redist\vcredist_x86.exe
DownloadUrl=$(var.vcredist_x86)
InstallCommand=/q
DetectCondition=vcredist AND (vcredist gt;= 1)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
/PackageGroup
  /Fragment
/Wix

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com] 
Sent: 29 August 2012 11:26
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

Hi, Hope someone can help me. I'm trying to install the Visual C++ 
redistributables file vcredist_x86.exe

 

I can't use merge modules as I've been asked to use this one EXE file. I added 
it to a bootstrapper using this code:

ItemGroup

BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

  ProductNameMicrosoft Visual C++ Redistributables/ProductName

/BootstrapperFile

/ItemGroup

 

Target Name=AfterBuild

GenerateBootstrapper ApplicationFile=$(TargetFileName)
ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
ComponentsLocation=Relative CopyComponents=True
OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft 
SDKs\Windows\v7.0A\Bootstrapper\ /

/Target

 

 

But this installs the prerequisites at the beginning and I have been asked to 
show our welcome dialog and then do a registry search to see if the appropriate 
files are installed. If they are not to call the vcredist_x86.exe file. 

 

Can this be done?

I'm trying this but cannot get it to work.

 

   CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
Property=QtExecDeferredExampleWithProperty
Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA
DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/

 

   

InstallExecuteSequence

  Custom Action=QtExecDeferredExampleWithProperty_Cmd
After=CostFinalize/

  Custom Action=QtExecDeferredExampleWithProperty
After=InstallInitialize/

/InstallExecuteSequence

 

 

Kind Regards,

 

Natalie Carr

 

 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Verify if registry key exist with no default value.

2012-08-29 Thread Christoffel le Roux
Hi guys, isn't doing installers FUN?  LOL

I know from the previous versions of WIX that you could not verify if a 
registry key exist using a RegistrySearch you had to create a custom action to 
do so.

But I found this is the schema documentation v3.? of RegistrySearch:

Result   Enumeration  Rather than saving the matching registry value into 
the variable, a RegistrySearch can save an attribute of the matching entry 
instead. This attribute's value must be one of the following:
exists
Saves true if a matching registry entry is found; false otherwise.
value
Saves the value of the registry key in the variable. This is the default.

But this does not exist any more :(

It there a new way of doing this?

Thanks

Kind regards,
Christoffel le Roux
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Natalie Carr
Thank you very much, I'm using WIX 3.5 at the minute, Would u recommend
moving to 3.6? 

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: 29 August 2012 11:54
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install the Visual C++ redistributables file
vcredist_x86.exe

I'd suggest using burn to do this; this is the code I am using to install
vcredist.

?xml version=1.0 encoding=utf-8?
?define vcredist_x86 =
http://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-7953769
89c03/vcredist_x86.exe ? Wix
xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
  Fragment
util:RegistrySearch Root=HKLM
Key=SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0\RED\1033 Value=SP
Variable=vcredist /
PackageGroup Id=vcredist
  ExePackage Id=vcredist_x86
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
Name=Redist\vcredist_x86.exe
SourceFile=Redist\vcredist_x86.exe
DownloadUrl=$(var.vcredist_x86)
InstallCommand=/q
DetectCondition=vcredist AND (vcredist gt;= 1)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
/PackageGroup
  /Fragment
/Wix

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: 29 August 2012 11:26
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Install the Visual C++ redistributables file
vcredist_x86.exe

Hi, Hope someone can help me. I'm trying to install the Visual C++
redistributables file vcredist_x86.exe

 

I can't use merge modules as I've been asked to use this one EXE file. I
added it to a bootstrapper using this code:

ItemGroup

BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

  ProductNameMicrosoft Visual C++ Redistributables/ProductName

/BootstrapperFile

/ItemGroup

 

Target Name=AfterBuild

GenerateBootstrapper ApplicationFile=$(TargetFileName)
ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
ComponentsLocation=Relative CopyComponents=True
OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\ /

/Target

 

 

But this installs the prerequisites at the beginning and I have been asked
to show our welcome dialog and then do a registry search to see if the
appropriate files are installed. If they are not to call the
vcredist_x86.exe file. 

 

Can this be done?

I'm trying this but cannot get it to work.

 

   CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
Property=QtExecDeferredExampleWithProperty
Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA
DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/

 

   

InstallExecuteSequence

  Custom Action=QtExecDeferredExampleWithProperty_Cmd
After=CostFinalize/

  Custom Action=QtExecDeferredExampleWithProperty
After=InstallInitialize/

/InstallExecuteSequence

 

 

Kind Regards,

 

Natalie Carr

 

 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Neil Sleightholm
I would if you need to install prereqs. (I think the release is only a few days 
away.)

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com] 
Sent: 29 August 2012 12:11
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

Thank you very much, I'm using WIX 3.5 at the minute, Would u recommend moving 
to 3.6? 

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: 29 August 2012 11:54
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

I'd suggest using burn to do this; this is the code I am using to install 
vcredist.

?xml version=1.0 encoding=utf-8?
?define vcredist_x86 =
http://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-7953769
89c03/vcredist_x86.exe ? Wix
xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
  Fragment
util:RegistrySearch Root=HKLM
Key=SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0\RED\1033 Value=SP
Variable=vcredist /
PackageGroup Id=vcredist
  ExePackage Id=vcredist_x86
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
Name=Redist\vcredist_x86.exe
SourceFile=Redist\vcredist_x86.exe
DownloadUrl=$(var.vcredist_x86)
InstallCommand=/q
DetectCondition=vcredist AND (vcredist gt;= 1)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
/PackageGroup
  /Fragment
/Wix

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: 29 August 2012 11:26
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

Hi, Hope someone can help me. I'm trying to install the Visual C++ 
redistributables file vcredist_x86.exe

 

I can't use merge modules as I've been asked to use this one EXE file. I added 
it to a bootstrapper using this code:

ItemGroup

BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

  ProductNameMicrosoft Visual C++ Redistributables/ProductName

/BootstrapperFile

/ItemGroup

 

Target Name=AfterBuild

GenerateBootstrapper ApplicationFile=$(TargetFileName)
ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
ComponentsLocation=Relative CopyComponents=True
OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft 
SDKs\Windows\v7.0A\Bootstrapper\ /

/Target

 

 

But this installs the prerequisites at the beginning and I have been asked to 
show our welcome dialog and then do a registry search to see if the appropriate 
files are installed. If they are not to call the vcredist_x86.exe file. 

 

Can this be done?

I'm trying this but cannot get it to work.

 

   CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
Property=QtExecDeferredExampleWithProperty
Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA
DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/

 

   

InstallExecuteSequence

  Custom Action=QtExecDeferredExampleWithProperty_Cmd
After=CostFinalize/

  Custom Action=QtExecDeferredExampleWithProperty
After=InstallInitialize/

/InstallExecuteSequence

 

 

Kind Regards,

 

Natalie Carr

 

 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Sanjay Rao
I think you should use merge module of VCResdist.

On 8/29/2012 3:56 PM, Natalie Carr wrote:
 Hi, Hope someone can help me. I'm trying to install the Visual C++
 redistributables file vcredist_x86.exe

   

 I can't use merge modules as I've been asked to use this one EXE file. I
 added it to a bootstrapper using this code:

 ItemGroup

 BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

ProductNameMicrosoft Visual C++ Redistributables/ProductName

 /BootstrapperFile

 /ItemGroup

   

 Target Name=AfterBuild

 GenerateBootstrapper ApplicationFile=$(TargetFileName)
 ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
 ComponentsLocation=Relative CopyComponents=True
 OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft
 SDKs\Windows\v7.0A\Bootstrapper\ /

 /Target

   

   

 But this installs the prerequisites at the beginning and I have been asked
 to show our welcome dialog and then do a registry search to see if the
 appropriate files are installed. If they are not to call the
 vcredist_x86.exe file.

   

 Can this be done?

 I'm trying this but cannot get it to work.

   

 CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
 Property=QtExecDeferredExampleWithProperty
 Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

  CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA
 DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/

   

 

  InstallExecuteSequence

Custom Action=QtExecDeferredExampleWithProperty_Cmd
 After=CostFinalize/

Custom Action=QtExecDeferredExampleWithProperty
 After=InstallInitialize/

  /InstallExecuteSequence

   

   

 Kind Regards,

   

 Natalie Carr

   

   

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
Sanjay Rao
Digital Media Group, Interra Systems
s...@interrasystems.com
http://www.interrasystems.com




--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Verify if registry key exist with no default value.

2012-08-29 Thread jhennessey
Those are the search element for use with burn in 3.6+. I have found that the
burn searches are capable of detecting if a key exists or not. However,
these won't be useful to you if you aren't using burn (they won't execute in
an MSI).



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Verify-if-registry-key-exist-with-no-default-value-tp7580171p7580175.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Burn copying packages

2012-08-29 Thread Neil Sleightholm
What causes burn to copy a package from the source folder to the location 
pointed to be the Name attribute when you build a bundle?

I find that sometimes this happens but can't figure out the logic. It makes 
sense that it does this for non-compressed packages but I am also seeing it 
happen for compressed ones and would like to stop this.

Neil

Neil Sleightholm
X2 Systems Limited
n...@x2systems.commailto:n...@x2systems.com

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Chain multiple prerequisites using burn.

2012-08-29 Thread Christoffel le Roux
Hi guys, Is it possible to install multiple prerequisites using burn?

You can only specify one WixMbaPrereqPackageId element according to the schema 
and I also tried

PackageGroup Id=Netfx35
  ExePackage Id=Netfx35
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
SourceFile=Redist\DotNetFX35SP1\dotnetfx35.exe
InstallCommand=/q /norestart /lang:ENU
RepairCommand=/q /norestart /lang:ENU
UninstallCommand=/q /norestart /lang:ENU
 DetectCondition=Netfx35Version AND (NOT VersionNT64 OR 
Netfx35x64Version)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
  ExePackage Id=VSTOSERuntime
   Cache=no
   Compressed=no
   PerMachine=yes
   Permanent=yes
   Vital=yes
   SourceFile=Redist\VSTOSERuntime\vstor.exe
   InstallCommand=/q /norestart /lang:ENU
   RepairCommand=/q /norestart /lang:ENU
   UninstallCommand=/q /norestart /lang:ENU
 DetectCondition=VSTORTVERSION
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
/PackageGroup


And

PackageGroup Id=Netfx35
  ExePackage Id=Netfx35
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
SourceFile=Redist\DotNetFX35SP1\dotnetfx35.exe
InstallCommand=/q /norestart /lang:ENU
RepairCommand=/q /norestart /lang:ENU
UninstallCommand=/q /norestart /lang:ENU
 DetectCondition=Netfx35Version AND (NOT VersionNT64 OR 
Netfx35x64Version)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage

/PackageGroup

PackageGroup Id=VSTOSERuntime
  ExePackage Id=VSTOSERuntime
 Cache=no
 Compressed=no
 PerMachine=yes
 Permanent=yes
 Vital=yes
 SourceFile=Redist\VSTOSERuntime\vstor.exe
 InstallCommand=/q /norestart /lang:ENU
 RepairCommand=/q /norestart /lang:ENU
 UninstallCommand=/q /norestart /lang:ENU
   DetectCondition=VSTORTVERSION
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage

/PackageGroup


But with no luck, I cannot get the IsPrerequisite flag to be set on both the 
prerequisite packages.

Can someone please explain to me how to do this.

Thanks allot


Kind regards,
Christoffel le Roux
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Problems with UninstallCertificates custom action

2012-08-29 Thread Andy Clugston
Dario, did you ever find a resolution to this issue?

On Wed, Sep 22, 2010 at 8:52 PM, Bob Arnson b...@joyofsetup.com wrote:

   On 22-Sep-10 20:15, Dario Amiri wrote:
  So it looks like no one has any advice for this issue. Is there any way
  I can submit this as a bug?

 The WiX home page has links to the bug database: https://wix.codeplex.com/

 --
 sig://boB
 http://joyofsetup.com/



 --
 Start uncovering the many advantages of virtual appliances
 and start using them to simplify application deployment and
 accelerate your shift to cloud computing.
 http://p.sf.net/sfu/novell-sfdev2dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Assistance with Burn

2012-08-29 Thread Jeanne Dixon
I have attempted to rename the dll I built in the wixstdba directory to be 
WixBalExtension.dll and copied it into my Wix3.6 Toolset directory. When I try 
to build my bootstrapper it gives me an error that the dll could not be loaded.

What do I need to do to properly build a new WixBalExtension.dll?

-Original Message-
From: Jeanne Dixon [mailto:jdi...@cots.com] 
Sent: Tuesday, August 28, 2012 10:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Assistance with Burn

I really could use some assistance with this. I have changed 
WixStandardBootstrapperApplication.cpp as I mentioned, but I can't figure out 
what to build (do I build at the ext source level or where), how to build it (I 
get lots of errors and warnings that files are missing when I try to open 
ext.sln).  Can someone explain where, what, and how I need to build?

I have made a dll in the wixstdba directory, but I don't know how to use the 
dll within the burn bundle. I attempted to make the BootsrapperApplication in 
my wxs file, but of course that did not work.

Any ideas on what I need to do?

-Original Message-
From: Jeanne Dixon [mailto:jdi...@cots.com] 
Sent: Friday, August 24, 2012 2:12 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Assistance with Burn

I have been attempting to make simple changes to the theme of my burn 
application. Most of this has been easy, but I am now running into a few things 
that I can't seem to find simple answers to.

First, if the user cancels the install from my bootstrap, it shows that the 
install failed and gives the error code and description (as provided in the 
examples). Without creating my own BA, is there a way to have conditional text 
for User canceled vs a real error? Also, how do I turn on the error logs for 
Burn (and where does it put them by default - I am new to all this and I don't 
really know where %temp% is).

Second, if I have to create my own BA to handle this, how do I go about 
integrating it into my bootstrap? I have made changes to 
WixStandardBootstrapperApplication.cpp, but I don't know what to do with the 
dll generated or how and where to put the config file (I have seen examples of 
some of this but there is no concise information on what to do and where to put 
it).
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Natalie Carr
Neil, I only have the one prereq. Burn has their own UI and I know you can
add yours from the MSI but it still shows the burn one. Is there any other
way than using burn?

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: 29 August 2012 12:27
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install the Visual C++ redistributables file
vcredist_x86.exe

I would if you need to install prereqs. (I think the release is only a few
days away.)

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: 29 August 2012 12:11
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Install the Visual C++ redistributables file
vcredist_x86.exe

Thank you very much, I'm using WIX 3.5 at the minute, Would u recommend
moving to 3.6? 

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: 29 August 2012 11:54
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install the Visual C++ redistributables file
vcredist_x86.exe

I'd suggest using burn to do this; this is the code I am using to install
vcredist.

?xml version=1.0 encoding=utf-8?
?define vcredist_x86 =
http://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-7953769
89c03/vcredist_x86.exe ? Wix
xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
  Fragment
util:RegistrySearch Root=HKLM
Key=SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0\RED\1033 Value=SP
Variable=vcredist /
PackageGroup Id=vcredist
  ExePackage Id=vcredist_x86
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
Name=Redist\vcredist_x86.exe
SourceFile=Redist\vcredist_x86.exe
DownloadUrl=$(var.vcredist_x86)
InstallCommand=/q
DetectCondition=vcredist AND (vcredist gt;= 1)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
/PackageGroup
  /Fragment
/Wix

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: 29 August 2012 11:26
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Install the Visual C++ redistributables file
vcredist_x86.exe

Hi, Hope someone can help me. I'm trying to install the Visual C++
redistributables file vcredist_x86.exe

 

I can't use merge modules as I've been asked to use this one EXE file. I
added it to a bootstrapper using this code:

ItemGroup

BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

  ProductNameMicrosoft Visual C++ Redistributables/ProductName

/BootstrapperFile

/ItemGroup

 

Target Name=AfterBuild

GenerateBootstrapper ApplicationFile=$(TargetFileName)
ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
ComponentsLocation=Relative CopyComponents=True
OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\ /

/Target

 

 

But this installs the prerequisites at the beginning and I have been asked
to show our welcome dialog and then do a registry search to see if the
appropriate files are installed. If they are not to call the
vcredist_x86.exe file. 

 

Can this be done?

I'm trying this but cannot get it to work.

 

   CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
Property=QtExecDeferredExampleWithProperty
Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA
DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/

 

   

InstallExecuteSequence

  Custom Action=QtExecDeferredExampleWithProperty_Cmd
After=CostFinalize/

  Custom Action=QtExecDeferredExampleWithProperty
After=InstallInitialize/

/InstallExecuteSequence

 

 

Kind Regards,

 

Natalie Carr

 

 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



Re: [WiX-users] Chain multiple prerequisites using burn.

2012-08-29 Thread Christoffel le Roux
Do you guys think it will be feasible to start on my own bootstapper 
application implementation rather than using burn for installing multiple 
prerequisites?

Kind regards,
Christoffel le Roux



-Original Message-
From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] 
Sent: Wednesday, August 29, 2012 3:00 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Chain multiple prerequisites using burn.

Hi guys, Is it possible to install multiple prerequisites using burn?

You can only specify one WixMbaPrereqPackageId element according to the schema 
and I also tried

PackageGroup Id=Netfx35
  ExePackage Id=Netfx35
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
SourceFile=Redist\DotNetFX35SP1\dotnetfx35.exe
InstallCommand=/q /norestart /lang:ENU
RepairCommand=/q /norestart /lang:ENU
UninstallCommand=/q /norestart /lang:ENU
 DetectCondition=Netfx35Version AND (NOT VersionNT64 OR 
Netfx35x64Version)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
  ExePackage Id=VSTOSERuntime
   Cache=no
   Compressed=no
   PerMachine=yes
   Permanent=yes
   Vital=yes
   SourceFile=Redist\VSTOSERuntime\vstor.exe
   InstallCommand=/q /norestart /lang:ENU
   RepairCommand=/q /norestart /lang:ENU
   UninstallCommand=/q /norestart /lang:ENU
 DetectCondition=VSTORTVERSION
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
/PackageGroup


And

PackageGroup Id=Netfx35
  ExePackage Id=Netfx35
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
SourceFile=Redist\DotNetFX35SP1\dotnetfx35.exe
InstallCommand=/q /norestart /lang:ENU
RepairCommand=/q /norestart /lang:ENU
UninstallCommand=/q /norestart /lang:ENU
 DetectCondition=Netfx35Version AND (NOT VersionNT64 OR 
Netfx35x64Version)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage

/PackageGroup

PackageGroup Id=VSTOSERuntime
  ExePackage Id=VSTOSERuntime
 Cache=no
 Compressed=no
 PerMachine=yes
 Permanent=yes
 Vital=yes
 SourceFile=Redist\VSTOSERuntime\vstor.exe
 InstallCommand=/q /norestart /lang:ENU
 RepairCommand=/q /norestart /lang:ENU
 UninstallCommand=/q /norestart /lang:ENU
   DetectCondition=VSTORTVERSION
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage

/PackageGroup


But with no luck, I cannot get the IsPrerequisite flag to be set on both the 
prerequisite packages.

Can someone please explain to me how to do this.

Thanks allot


Kind regards,
Christoffel le Roux
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Sanjay Rao
including merge module of vcredist_x86 in your installer is the another way.

On 8/29/2012 7:03 PM, Natalie Carr wrote:
 Neil, I only have the one prereq. Burn has their own UI and I know you can
 add yours from the MSI but it still shows the burn one. Is there any other
 way than using burn?

 -Original Message-
 From: Neil Sleightholm [mailto:n...@x2systems.com]
 Sent: 29 August 2012 12:27
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Install the Visual C++ redistributables file
 vcredist_x86.exe

 I would if you need to install prereqs. (I think the release is only a few
 days away.)

 Neil

 -Original Message-
 From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
 Sent: 29 August 2012 12:11
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] Install the Visual C++ redistributables file
 vcredist_x86.exe

 Thank you very much, I'm using WIX 3.5 at the minute, Would u recommend
 moving to 3.6?

 -Original Message-
 From: Neil Sleightholm [mailto:n...@x2systems.com]
 Sent: 29 August 2012 11:54
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Install the Visual C++ redistributables file
 vcredist_x86.exe

 I'd suggest using burn to do this; this is the code I am using to install
 vcredist.

 ?xml version=1.0 encoding=utf-8?
 ?define vcredist_x86 =
 http://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-7953769
 89c03/vcredist_x86.exe ? Wix
 xmlns=http://schemas.microsoft.com/wix/2006/wi;
 xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
Fragment
  util:RegistrySearch Root=HKLM
 Key=SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0\RED\1033 Value=SP
 Variable=vcredist /
  PackageGroup Id=vcredist
ExePackage Id=vcredist_x86
  Cache=no
  Compressed=no
  PerMachine=yes
  Permanent=yes
  Vital=yes
  Name=Redist\vcredist_x86.exe
  SourceFile=Redist\vcredist_x86.exe
  DownloadUrl=$(var.vcredist_x86)
  InstallCommand=/q
  DetectCondition=vcredist AND (vcredist gt;= 1)
  ExitCode Value =3010 Behavior=forceReboot /
/ExePackage
  /PackageGroup
/Fragment
 /Wix

 Neil

 -Original Message-
 From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
 Sent: 29 August 2012 11:26
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Install the Visual C++ redistributables file
 vcredist_x86.exe

 Hi, Hope someone can help me. I'm trying to install the Visual C++
 redistributables file vcredist_x86.exe

   

 I can't use merge modules as I've been asked to use this one EXE file. I
 added it to a bootstrapper using this code:

 ItemGroup

 BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

ProductNameMicrosoft Visual C++ Redistributables/ProductName

 /BootstrapperFile

 /ItemGroup

   

 Target Name=AfterBuild

 GenerateBootstrapper ApplicationFile=$(TargetFileName)
 ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
 ComponentsLocation=Relative CopyComponents=True
 OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft
 SDKs\Windows\v7.0A\Bootstrapper\ /

 /Target

   

   

 But this installs the prerequisites at the beginning and I have been asked
 to show our welcome dialog and then do a registry search to see if the
 appropriate files are installed. If they are not to call the
 vcredist_x86.exe file.

   

 Can this be done?

 I'm trying this but cannot get it to work.

   

 CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
 Property=QtExecDeferredExampleWithProperty
 Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

  CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA
 DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/

   

 

  InstallExecuteSequence

Custom Action=QtExecDeferredExampleWithProperty_Cmd
 After=CostFinalize/

Custom Action=QtExecDeferredExampleWithProperty
 After=InstallInitialize/

  /InstallExecuteSequence

   

   

 Kind Regards,

   

 Natalie Carr

   

   

 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and threat
 landscape has changed and how IT managers can respond. Discussions will
 include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and threat
 landscape has changed and how IT managers can respond. Discussions will
 include endpoint security, 

Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?

2012-08-29 Thread Hoover, Jacob
Are you saying you need the path to the MSI in order to be able to deduce a 
path to the EXE files outside of the installer that you want to create 
shortcuts to? If so, have you looked at this from the MSI side as far as 
SourceDir and/or MsiGetProductInfo ( 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370130(v=vs.85).aspx 
) and look for  INSTALLPROPERTY_INSTALLSOURCE?

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: Wednesday, August 29, 2012 5:04 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Sorry but I can't really help - that is quite an odd requirement and I am not 
sure how burn will work on upgrade and repair as the code won't be running from 
your folder.

Neil

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 10:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, I try to explain the background:

The installer will be located in a remote folder in which most executables of 
the client are located. The Clients are practically not really installed on the 
local machine, only Shortcuts with the path to the executables on the remote 
folder are generated (besides some other stuff).

Therefore I need the path, from which the installer was called. As I wrote at 
the beginning, burn only offers a *complete path* including the name of the 
installer (e.g. ``Z:\Foo\Bar\setup.exe``). I need the path without the 
installer name.

That's the problem I have to solve :-)

-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Mittwoch, 29. August 2012 11:41
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Just stepping back at bit but why do you need the source of the burn install 
passed into your MSI?

Neil

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 10:39
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, my idea was good, but there is a problem with it. Burn does not support 
searching *during* the installation process. So even if I have the correct 
sequence in my chain, the RegistrySearch is always done at the beginning before 
any packages are executed :-( Therefore my little helper program has not been 
called yet when the search happens and so the key is not found.

I found the answer here: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html

I did not recognize that, as I do not delete the key after uninstall. So my 
installer always found one as it was written in the previous installation 
process...

So back to brainstorming... I think only a custom action can help me now? (That 
I can place in my MsiPackage and call it before any other actions?)

Damn, I wished I could get around that... imho creating your own CA looks quite 
difficult...

Bet regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Hm... no answer yet? Are my questions not understandable or too strange? ;-)

Ok, as perhaps some users might be interested in a solution, I present the way 
I have chosen for now:

Basic Idea is to simply write a small C# Program, that gets the Path from a wix 
burn bundle via CLI, shortens it by removing the ``setup.exe``-part and write 
the result (the plain source path) into a defined registry key. Other 
components of an installer bundle can retrieve this key and use the information 
for further setup process.

The Mini-Program look like this:

namespace RegisterPath
{
class Program
{
static void Main(string[] args)
{
Registry.SetValue(string.Format(@{0}\{1}, 
RegisterPath.Properties.Resources.root, RegisterPath.Properties.Resources.key),
RegisterPath.Properties.Resources.valuename, 
Path.GetDirectoryName(args[0]));
}
}
}

As you can see I use resource-strings for the definition of the registry key.

The fragment within the burn bundle to call the programm:

  Fragment
PackageGroup Id=RegisterPath
  ExePackage Name=RegisterPath.exe Id=RegisterPath_PK
  SourceFile=$(var.RegisterPathPath) 
InstallCommand='[WixBundleOriginalSource]'
  Cache=no Compressed=yes PerMachine=yes Vital=yes/
/PackageGroup
 /Fragment


As 

Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Natalie Carr
Hi,

As I said in my original question I can't use merge modules as I've been
asked to use this one EXE file. Trying to figure out a way to use it.
Thanks

-Original Message-
From: Sanjay Rao [mailto:s...@noida.interrasystems.com] 
Sent: 29 August 2012 15:43
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Install the Visual C++ redistributables file
vcredist_x86.exe

including merge module of vcredist_x86 in your installer is the another way.

On 8/29/2012 7:03 PM, Natalie Carr wrote:
 Neil, I only have the one prereq. Burn has their own UI and I know you 
 can add yours from the MSI but it still shows the burn one. Is there 
 any other way than using burn?

 -Original Message-
 From: Neil Sleightholm [mailto:n...@x2systems.com]
 Sent: 29 August 2012 12:27
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
 vcredist_x86.exe

 I would if you need to install prereqs. (I think the release is only a 
 few days away.)

 Neil

 -Original Message-
 From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
 Sent: 29 August 2012 12:11
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
 vcredist_x86.exe

 Thank you very much, I'm using WIX 3.5 at the minute, Would u 
 recommend moving to 3.6?

 -Original Message-
 From: Neil Sleightholm [mailto:n...@x2systems.com]
 Sent: 29 August 2012 11:54
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
 vcredist_x86.exe

 I'd suggest using burn to do this; this is the code I am using to 
 install vcredist.

 ?xml version=1.0 encoding=utf-8? ?define vcredist_x86 =
 http://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-7
 953769
 89c03/vcredist_x86.exe ? Wix
 xmlns=http://schemas.microsoft.com/wix/2006/wi;
 xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
Fragment
  util:RegistrySearch Root=HKLM
 Key=SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0\RED\1033 Value=SP
 Variable=vcredist /
  PackageGroup Id=vcredist
ExePackage Id=vcredist_x86
  Cache=no
  Compressed=no
  PerMachine=yes
  Permanent=yes
  Vital=yes
  Name=Redist\vcredist_x86.exe
  SourceFile=Redist\vcredist_x86.exe
  DownloadUrl=$(var.vcredist_x86)
  InstallCommand=/q
  DetectCondition=vcredist AND (vcredist gt;= 1)
  ExitCode Value =3010 Behavior=forceReboot /
/ExePackage
  /PackageGroup
/Fragment
 /Wix

 Neil

 -Original Message-
 From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
 Sent: 29 August 2012 11:26
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Install the Visual C++ redistributables file 
 vcredist_x86.exe

 Hi, Hope someone can help me. I'm trying to install the Visual C++ 
 redistributables file vcredist_x86.exe

   

 I can't use merge modules as I've been asked to use this one EXE file. 
 I added it to a bootstrapper using this code:

 ItemGroup

 BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

ProductNameMicrosoft Visual C++ Redistributables/ProductName

 /BootstrapperFile

 /ItemGroup

   

 Target Name=AfterBuild

 GenerateBootstrapper ApplicationFile=$(TargetFileName)
 ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
 ComponentsLocation=Relative CopyComponents=True
 OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft 
 SDKs\Windows\v7.0A\Bootstrapper\ /

 /Target

   

   

 But this installs the prerequisites at the beginning and I have been 
 asked to show our welcome dialog and then do a registry search to see 
 if the appropriate files are installed. If they are not to call the 
 vcredist_x86.exe file.

   

 Can this be done?

 I'm trying this but cannot get it to work.

   

 CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
 Property=QtExecDeferredExampleWithProperty
 Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

  CustomAction Id=QtExecDeferredExampleWithProperty
BinaryKey=WixCA
 DllEntry=CAQuietExec Execute=deferred Return=check 
 Impersonate=no/

   

 

  InstallExecuteSequence

Custom Action=QtExecDeferredExampleWithProperty_Cmd
 After=CostFinalize/

Custom Action=QtExecDeferredExampleWithProperty
 After=InstallInitialize/

  /InstallExecuteSequence

   

   

 Kind Regards,

   

 Natalie Carr

   

   

 --
 --
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. 
 Discussions will include endpoint security, mobile security and the 
 latest in malware threats. 
 http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 

Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Bruce Cran
On 29/08/2012 16:08, Natalie Carr wrote:
 As I said in my original question I can't use merge modules as I've been
 asked to use this one EXE file. Trying to figure out a way to use it.

I think this is one of those cases where you have to ask why. Why are 
they requiring you to use the .exe instead of the .msm?

-- 
Bruce Cran

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Install the Visual C++ redistributables file vcredist_x86.exe

2012-08-29 Thread Neil Sleightholm
No I don't think so, looks like using the merge module is your best option.

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com] 
Sent: 29 August 2012 14:34
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

Neil, I only have the one prereq. Burn has their own UI and I know you can add 
yours from the MSI but it still shows the burn one. Is there any other way than 
using burn?

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: 29 August 2012 12:27
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

I would if you need to install prereqs. (I think the release is only a few days 
away.)

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: 29 August 2012 12:11
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

Thank you very much, I'm using WIX 3.5 at the minute, Would u recommend moving 
to 3.6? 

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: 29 August 2012 11:54
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

I'd suggest using burn to do this; this is the code I am using to install 
vcredist.

?xml version=1.0 encoding=utf-8?
?define vcredist_x86 =
http://download.microsoft.com/download/d/d/9/dd9a82d0-52ef-40db-8dab-7953769
89c03/vcredist_x86.exe ? Wix
xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
  Fragment
util:RegistrySearch Root=HKLM
Key=SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0\RED\1033 Value=SP
Variable=vcredist /
PackageGroup Id=vcredist
  ExePackage Id=vcredist_x86
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
Name=Redist\vcredist_x86.exe
SourceFile=Redist\vcredist_x86.exe
DownloadUrl=$(var.vcredist_x86)
InstallCommand=/q
DetectCondition=vcredist AND (vcredist gt;= 1)
ExitCode Value =3010 Behavior=forceReboot /
  /ExePackage
/PackageGroup
  /Fragment
/Wix

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: 29 August 2012 11:26
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Install the Visual C++ redistributables file 
vcredist_x86.exe

Hi, Hope someone can help me. I'm trying to install the Visual C++ 
redistributables file vcredist_x86.exe

 

I can't use merge modules as I've been asked to use this one EXE file. I added 
it to a bootstrapper using this code:

ItemGroup

BootstrapperFile Include=Microsoft.Visual.C++.10.0.x86

  ProductNameMicrosoft Visual C++ Redistributables/ProductName

/BootstrapperFile

/ItemGroup

 

Target Name=AfterBuild

GenerateBootstrapper ApplicationFile=$(TargetFileName)
ApplicationName=Server Setup BootstrapperItems=@(BootstrapperFile)
ComponentsLocation=Relative CopyComponents=True
OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft 
SDKs\Windows\v7.0A\Bootstrapper\ /

/Target

 

 

But this installs the prerequisites at the beginning and I have been asked to 
show our welcome dialog and then do a registry search to see if the appropriate 
files are installed. If they are not to call the vcredist_x86.exe file. 

 

Can this be done?

I'm trying this but cannot get it to work.

 

   CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
Property=QtExecDeferredExampleWithProperty
Value=quot;[#vcredist_x86.exe]quot; Execute=immediate/

CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA
DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/

 

   

InstallExecuteSequence

  Custom Action=QtExecDeferredExampleWithProperty_Cmd
After=CostFinalize/

  Custom Action=QtExecDeferredExampleWithProperty
After=InstallInitialize/

/InstallExecuteSequence

 

 

Kind Regards,

 

Natalie Carr

 

 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how 

Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?

2012-08-29 Thread Christian Hausknecht
Ok, finally I just implemented a custom action, that performs the string 
manipulation and sets a new property to the session. This property value I can 
grab easily from within my product.wxs:

Binary Id=MyCustomAction.dll SourceFile=$(var.global.MyCAPath)/
CustomAction Id=AdjustPath BinaryKey=MyCustomAction.dll 
DllEntry=AdjustPath Execute=immediate/


!-- Execute Sequenz--
InstallExecuteSequence
  Custom Action=AdjustPath Before=CostFinalize/
/InstallExecuteSequence

After that I can refer to the propery named ``FOOBASEPATH`` where the trimmed 
path resides.


And here is the C# Code for the Custom Action:

namespace MyCustomActions
{
public class CustomActions
{
[CustomAction]
public static ActionResult AdjustPath(Session session)
{
session.Log(Begin AdjustPath);

session[FOOBASEPATH] = 
Path.GetDirectoryName(session[BURNSOURCEDIR]) + @\;

session.Log(End AdjustPath);

return ActionResult.Success;
}
}
}

As CAs are only callable from within Msi-Packages I must provide a temporary 
Property containing the value of the Built-in burn property `` 
WixBundleOriginalSource``. I named it ``BURNSOURCEDIR``. So I can set this 
Property as a MsiProperty in my (burn) bundle definition:


  MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=BURNSOURCEDIR Value=[WixBundleOriginalSource]/
  /MsiPackage


So the calling sequence is like this:

1.) call the Msi-Package and provide a Property named ``BURNSOURCEDIR`` with 
the value of ``WixBundleOriginalSource``
2.) In the Msi-Package execute the custom action
3.) The CA sets the new Property ``FOOBASEPATH``
4.) Use ``FOOBASEPATH`` everywhere in the Msi-Package where one need it
5.) be happy :-D

Puh... much work for some little thing. But gained more knowledge about WiX, 
burn and Windows Installer technologies. And in the end it works :-)


Best regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de] 
Gesendet: Mittwoch, 29. August 2012 11:58
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, I try to explain the background:

The installer will be located in a remote folder in which most executables of 
the client are located. The Clients are practically not really installed on the 
local machine, only Shortcuts with the path to the executables on the remote 
folder are generated (besides some other stuff).

Therefore I need the path, from which the installer was called. As I wrote at 
the beginning, burn only offers a *complete path* including the name of the 
installer (e.g. ``Z:\Foo\Bar\setup.exe``). I need the path without the 
installer name.

That's the problem I have to solve :-)

-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Mittwoch, 29. August 2012 11:41
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Just stepping back at bit but why do you need the source of the burn install 
passed into your MSI?

Neil

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 10:39
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Ok, my idea was good, but there is a problem with it. Burn does not support 
searching *during* the installation process. So even if I have the correct 
sequence in my chain, the RegistrySearch is always done at the beginning before 
any packages are executed :-( Therefore my little helper program has not been 
called yet when the search happens and so the key is not found.

I found the answer here: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html

I did not recognize that, as I do not delete the key after uninstall. So my 
installer always found one as it was written in the previous installation 
process...

So back to brainstorming... I think only a custom action can help me now? (That 
I can place in my MsiPackage and call it before any other actions?)

Damn, I wished I could get around that... imho creating your own CA looks quite 
difficult...

Bet regards,


-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is 
bundled within burn?

Hm... no answer yet? Are my questions not understandable or too strange? ;-)

Ok, as perhaps some users might be interested in a solution, I present the way 
I have chosen for now:

Basic Idea is 

[WiX-users] To regasm or to not regasm...

2012-08-29 Thread Christian Hausknecht
Hello folks,

me again :-D

The next problem I must solve requires some experience that I do not have, so I 
hope I can get good advice as usual from here :)

Base problem is quite easy: I need to register some DLLs during installation 
process.

But my initial situation is like this:
I do not install the DLLs on the local system! They are already located in a 
mounted net drive (is it called like this in the Windows-World?). The proper 
location can be different on every system, so one might have access to it like 
this X:\foo\bar\bin\MyDLL.dll some other might have a different drive name.  
So the path to the dll differs.

My question is now: Is it possible to use ``heat`` to harvest the information 
*once* from the build-server and integrate them into my wix-project as usual?  
That is the way Rob mentioned here: http://stackoverflow.com/a/1397481

But is that an option for my situation? Is the path something that affects the 
registration? And is it possible just to keep some parts (e.g. TypeLib-Part?!?) 
from the heat-output, as I do not want to install the dll locally? So can I 
just register the dlls with wix or is there always an installation process on 
top? And if so, what parts do I need?

If all else fails I think I just have to call ``regasm`` from a CustomAction - 
that should not be the problem to implement. But as Rob mentioned, it is 
perhaps not a good solution. So if it is possible to solve this with plain 
wix, I would definitely appreciate that.

I hope it is understandable for you, sorry my English is not so good :(

If something is still confusing or not sufficiently explained, please let me 
know. If not, please help me :)


Best regards,


Mit freundlichen Grüßen

Christian Hausknecht
Entwicklung

BeraCom
Beratung und Software-Entwicklung GmbH  Co. KG
Weidestr. 134, 22083 Hamburg
T: +49 (0)40 547 241 - DW
F: +49 (0)40 547 241 - 60
M: chauskne...@beracom.demailto:chauskne...@beracom.de
http://www.beracom.de

=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932
Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung 
GmbH
Sitz Hamburg, RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss
Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. 
Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher 
schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist 
sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der 
Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung 
überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre 
Richtigkeit.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn copying packages

2012-08-29 Thread Neil Sleightholm
To answer my own question it does seem to copy file from the SourceFile to Name 
attributes only if Compresses=no (I had the same package reference twice and 
one was set to no).

Neil

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: 29 August 2012 13:29
To: General toolset. (wix-users@lists.sourceforge.net)
Subject: [WiX-users] Burn copying packages

What causes burn to copy a package from the source folder to the location 
pointed to be the Name attribute when you build a bundle?

I find that sometimes this happens but can't figure out the logic. It makes 
sense that it does this for non-compressed packages but I am also seeing it 
happen for compressed ones and would like to stop this.

Neil

Neil Sleightholm
X2 Systems Limited
n...@x2systems.commailto:n...@x2systems.com

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] To regasm or to not regasm...

2012-08-29 Thread Hoover, Jacob
If you are only wanting to register these DLL's for your own private usage 
within a single application, I'd strongly suggest using registration free COM 
and deploy them with the application. This allows the OS to load the info into 
the activation context at application start, and would allow you to have 
multiple folders with multiple versions without the need to invoke a 
setup/repair operation when switching between them.

Regardless of if you register the DLL or use it in isolation, I seem to 
remember issues with .Net assemblies running on a network share being in a 
sandboxed zone where the CAS (prior to 4.0) would not allow the evil network 
binary to be able to do privileged operations without messing with the machine 
policy (granting full trust to our strong name).

Jacob

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de] 
Sent: Wednesday, August 29, 2012 10:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] To regasm or to not regasm...

Hello folks,

me again :-D

The next problem I must solve requires some experience that I do not have, so I 
hope I can get good advice as usual from here :)

Base problem is quite easy: I need to register some DLLs during installation 
process.

But my initial situation is like this:
I do not install the DLLs on the local system! They are already located in a 
mounted net drive (is it called like this in the Windows-World?). The proper 
location can be different on every system, so one might have access to it like 
this X:\foo\bar\bin\MyDLL.dll some other might have a different drive name.  
So the path to the dll differs.

My question is now: Is it possible to use ``heat`` to harvest the information 
*once* from the build-server and integrate them into my wix-project as usual?  
That is the way Rob mentioned here: http://stackoverflow.com/a/1397481

But is that an option for my situation? Is the path something that affects the 
registration? And is it possible just to keep some parts (e.g. TypeLib-Part?!?) 
from the heat-output, as I do not want to install the dll locally? So can I 
just register the dlls with wix or is there always an installation process on 
top? And if so, what parts do I need?

If all else fails I think I just have to call ``regasm`` from a CustomAction - 
that should not be the problem to implement. But as Rob mentioned, it is 
perhaps not a good solution. So if it is possible to solve this with plain 
wix, I would definitely appreciate that.

I hope it is understandable for you, sorry my English is not so good :(

If something is still confusing or not sufficiently explained, please let me 
know. If not, please help me :)


Best regards,


Mit freundlichen Grüßen

Christian Hausknecht
Entwicklung

BeraCom
Beratung und Software-Entwicklung GmbH  Co. KG Weidestr. 134, 22083 Hamburg
T: +49 (0)40 547 241 - DW
F: +49 (0)40 547 241 - 60
M: chauskne...@beracom.demailto:chauskne...@beracom.de
http://www.beracom.de

=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende 
Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, 
RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich 
und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch 
auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des 
Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei 
inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser 
Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen 
übernimmt jedoch keine Haftung für ihre Richtigkeit.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] To regasm or to not regasm...

2012-08-29 Thread Peter Shirtcliffe
When I last regasmed anything, I was using Wix2 and the tallow tool but the
process should apply to heat too. 

Regasm /regfile doesn't create type lib, so use tlbexp to create a type lib. 
Use typelib elements to register the type lib.
Use regasm /regfile to create a registration file.
Use heat to convert the registration file to registryvalues in wix source
code.
In the wix source code, replace any codebase (or other) paths with the
[SOMEPROPERTY] syntax. (Normally, you'd set the paths to [#DLL File ID].)

Ideally you should harvest from a machine that's as clean as possible. You
can set SOMEPROPERTY at install time to the full dll path.

-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de] 
Sent: 29 August 2012 16:44
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] To regasm or to not regasm...

Hello folks,

me again :-D

The next problem I must solve requires some experience that I do not have, so
I hope I can get good advice as usual from here :)

Base problem is quite easy: I need to register some DLLs during installation
process.

But my initial situation is like this:
I do not install the DLLs on the local system! They are already located in a
mounted net drive (is it called like this in the Windows-World?). The proper
location can be different on every system, so one might have access to it
like this X:\foo\bar\bin\MyDLL.dll some other might have a different drive
name.  So the path to the dll differs.

My question is now: Is it possible to use ``heat`` to harvest the information
*once* from the build-server and integrate them into my wix-project as usual?
That is the way Rob mentioned here: http://stackoverflow.com/a/1397481

But is that an option for my situation? Is the path something that affects
the registration? And is it possible just to keep some parts (e.g.
TypeLib-Part?!?) from the heat-output, as I do not want to install the dll
locally? So can I just register the dlls with wix or is there always an
installation process on top? And if so, what parts do I need?

If all else fails I think I just have to call ``regasm`` from a CustomAction
- that should not be the problem to implement. But as Rob mentioned, it is
perhaps not a good solution. So if it is possible to solve this with plain
wix, I would definitely appreciate that.

I hope it is understandable for you, sorry my English is not so good :(

If something is still confusing or not sufficiently explained, please let me
know. If not, please help me :)


Best regards,


Mit freundlichen Grüßen

Christian Hausknecht
Entwicklung

BeraCom
Beratung und Software-Entwicklung GmbH  Co. KG Weidestr. 134, 22083 Hamburg
T: +49 (0)40 547 241 - DW
F: +49 (0)40 547 241 - 60
M: chauskne...@beracom.demailto:chauskne...@beracom.de
http://www.beracom.de

=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich
haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH
Sitz Hamburg, RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich
und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren,
auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des
Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei
inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit
dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein
Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit.

-
-
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing 

Re: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs

2012-08-29 Thread Andy Clugston
I'm not having a whole lot of luck with anything I am trying. No matter
what the certificate uninstall action keeps running (and breaking).

One thing that I don't understand is that I created an MSI built with 3.5
and then did a /fv to replace the cached MSI . This allows the uninstall to
occur, but leaves all of the files/changes/etc. on the system. Then after
this, I am still having issues installing a new package. Having more
certificate issues during the install. Not sure if it is more issues with
the IIS cert extension or what. I am losing comfort with this
extension/feature.

We are to the point of looking into drastic measures, like replacing the
cached msi on the system, adjusting the registry, etc. to make Windows
think the replaced msi is the original. I am not looking forward to this as
I have a feeling it is going to be very messy.

Any other suggestions are welcome.

On Tue, Aug 28, 2012 at 10:24 PM, Andy Clugston clug...@gmail.com wrote:

 So I created a new version (major upgrade) of the product. I adjusted
 RemoveExistingProducts to run after InstallFinalize. This didn't seem to
 help at all. It still attempts to remove the cert, and I have the same
 errors.

 Thanks.


 On Tue, Aug 28, 2012 at 3:26 PM, Andy Clugston clug...@gmail.com wrote:

 I assume when you say take the original installer you mean bump one of
 the three version digits and generate a new product version installer, i.e.
 1.1.0 to 1.1.1, generate new product GUID, etc.

  Where this all started was trying to get a newer version of the product
 on the system. If I can make the RemoveExistingProducts changes to it and
 that actually works, then we should not need to figure out how to uninstall
 it first.


 On Tue, Aug 28, 2012 at 12:42 PM, Peter Shirtcliffe pshirtcli...@sdl.com
  wrote:

 Correct.
 Having thought about it a bit more, this might be a better idea:

 Take the original installer (or whatever is the current release).
 Make a major upgrade out of it in the normal way.
 Schedule RemoveExistingProducts in one of the latter two places
 mentioned in

 http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29
 .aspx
 Build it with WiX 3.5

 That'll create a major upgrade that shouldn't touch the certificate
 component. Being built with WiX 3.5, removal might then succeed. I'm not
 sure
 what the WiX team would say about mixing toolset versions like that but
 I'd
 guess there are risks, so you'd have to test thoroughly.

 You'd have to do the same thing with the second product too since you
 don't
 know which one will be removed last and will perform the actual
 certificate
 uninstallation.

 -Original Message-
 From: Andy Clugston [mailto:clug...@gmail.com]
 Sent: 28 August 2012 17:20
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Conditional Uninstall - Need to workaround WiX
 Certificate custom action bugs

 Okay, so what you are saying is that I cannot skip individual components
 during uninstall, correct?

 I am not sure if these would work or not. We don't have minor
 installs, we
 use the third digit, but it is a full install.

 This product installs the certificate, and another product re-installs
 the
 identical certificate. For some reason WiX 3.0 does not like this. I
 would
 have to dig up the bug report, but I did run across it. During our tests
 with
 WiX 3.5 this issue seems to be resolved. Now, we could get into a
 conversation about cross product dependencies, etc. but I was not
 involved
 with any of those decisions so I am just trying to dig us out of the
 hole we
 are in.

 I am not sure the extra installer is going to help. It appears that
 anything
 touching the original certificate on the system causes the original WiX
 3.0
 MSI to fail. Yes, the install would ensure the cert is on the system,
 but the
 uninstall for the original WiX 3.0 MSI package would still fail.

 Thanks for the help.

 On Tue, Aug 28, 2012 at 11:46 AM, Peter Shirtcliffe
 pshirtcli...@sdl.comwrote:

  As far as I can think, you can only selectively uninstall entire
  features without using permanent components.
  If the conditions are broken, would patching/minor updating them solve
  your problem ? I'm not sure what the WiX bug is that you're referring
 to.
  Otherwise, you could write an extra installer that only includes the
  component you want to keep, install that, then remove the original
  one. The extra reference would retain the component on the machine
  until you took both installers off.
 
  -Original Message-
  From: Andy Clugston [mailto:clug...@gmail.com]
  Sent: 28 August 2012 16:15
  To: General discussion for Windows Installer XML toolset.
  Subject: [WiX-users] Conditional Uninstall - Need to workaround WiX
  Certificate custom action bugs
 
  We have a product that installs a few certificates on the system using
  the IIS extension using WiX 3.0. Evidently, there is an issue with the
  certificate action(s) in this version of the