[WiX-users] Re-evaluate NETFRAMEWORK20 Property

2010-07-21 Thread Thode, Katelyn
I was wondering if it is possible to re-evaluate the NETFRAMEWORK20 property 
after it was previously evaluated.

My setup is that, when the next button is pressed on the welcome dialog, if 
the .NET Framework 2.0 is not installed, a dialog appears with a link to the 
website to install the .NET framework.  When ok is clicked, it takes the user 
back to the welcome dialog.  I would then like for the user to be able to 
continue the installation after they have installed the .net framework by 
clicking the next button.  But, when the next button is clicked, the dialog box 
with the link still comes up.  If I cancel the current installation session and 
run a new one, the application is installed successfully.

So, is it possible to re-evaluate the NETFRAMEWORK20 property each time the 
next button is pressed?  What is the recommended way to do so?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

2010-07-21 Thread Thode, Katelyn
Is there a bootstrapper that I can use that will detect if the OS is 32-bit or 
64-bit and then install the correct .NET Framework?

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer


-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 15:15
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I was wondering if it is possible to re-evaluate the NETFRAMEWORK20
property after it was previously evaluated.

My setup is that, when the next button is pressed on the welcome
dialog, if the .NET Framework 2.0 is not installed, a dialog appears
with a link to the website to install the .NET framework.  When ok is
clicked, it takes the user back to the welcome dialog.  I would then
like for the user to be able to continue the installation after they
have installed the .net framework by clicking the next button.  But,
when the next button is clicked, the dialog box with the link still
comes up.  If I cancel the current installation session and run a new
one, the application is installed successfully.

So, is it possible to re-evaluate the NETFRAMEWORK20 property each time
the next button is pressed?  What is the recommended way to do so?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint What will you do first with
EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

2010-07-21 Thread Thode, Katelyn
Thanks.  I have been looking on google for several days and I've also looked 
into dotNetInstaller.  I had a bootstrapper working on a 32-bit system but 
there was an error on a 64-bit system.  Based on my research on google, it 
sounded as though the dotNetInstaller didn't work on a 64-bit system and I was 
unable to find another bootstrapper that would.  I was looking for a work 
around, but since you thought that the work around wouldn't work, I was 
wondering if you knew of any bootstrappers that would work on both 32-bit and 
64-bit OS because I could not find any information about one during my 
research.  If you are not aware of one, that's fine.  I am just trying to 
figure out a solution.

Another option I have is using something like:

Condition Message=[Message]PROPERTY/Condition

Is there any way that I can add a push button to the message box that shows up 
that links to the website to install the .NET framework.  I have been searching 
for an answer to this question, but am unable to find one.

I also looked into doing something like this:

Condition Message=Setup requires .NET 2.0.  Please visit 
http://msdn.microsoft.com/en-us/netframework/aa731542.aspx and 
install.PROPERTY/Condition

Then, the user could click on the link and be taken to the website.  The 
information I found stated this was not supported, but it was from a long time 
ago, so I was just wondering if support has been added for this.

Thanks for your help.  I have been struggling to find a solution for this issue 
for several days now and your help is much appreciated.

Katelyn

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Wednesday, July 21, 2010 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I don't know. Perhaps looking at the URL I pasted in my earlier reply or
maybe even looking for yourself on one of those newly invented search
engine things such as www.google.com might find you an answer?

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 16:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Is there a bootstrapper that I can use that will detect if the OS is
32-bit or 64-bit and then install the correct .NET Framework?

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP Email Disclaimer


-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: 21 July 2010 15:15
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I was wondering if it is possible to re-evaluate the NETFRAMEWORK20
property after it was previously evaluated.

My setup is that, when the next button is pressed on the welcome
dialog, if the .NET Framework 2.0 is not installed, a dialog appears
with a link to the website to install the .NET framework.  When ok is
clicked, it takes the user back to the welcome dialog.  I would then
like for the user to be able to continue the installation after they
have installed the .net framework by clicking the next button.  But,
when the next button is clicked, the dialog box with the link still
comes up.  If I cancel the current installation session and run a new
one, the application is installed successfully.

So, is it possible to re-evaluate the NETFRAMEWORK20 property each time
the next button is pressed?  What is the recommended way to do so?

Thanks,
Katelyn

Note: The information contained in this message may be privileged

Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

2010-07-21 Thread Thode, Katelyn
Thanks for all of your responses.  If I can't get the bootstrapper up and 
running, then I am just going to go with a descriptive message.

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Wednesday, July 21, 2010 11:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

dotnetinstaller works perfectly fine on x64 platforms. I use it to do
exactly what you're trying to achieve which is why I suggested looking
at it yourself.

You can't use hyperlinks in Windows Installer dialogs unless you
specifically target Windows Installer v5 which is only available on
Windows 7/Server 2008 R2, in which case you'd need to use a bootstrapper
to sequence it before your package anyway if there was a redistributable
available for it (there isn't currently  it's unlikely there ever will
be at this point).

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 17:02
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Thanks.  I have been looking on google for several days and I've also
looked into dotNetInstaller.  I had a bootstrapper working on a 32-bit
system but there was an error on a 64-bit system.  Based on my research
on google, it sounded as though the dotNetInstaller didn't work on a
64-bit system and I was unable to find another bootstrapper that would.
I was looking for a work around, but since you thought that the work
around wouldn't work, I was wondering if you knew of any bootstrappers
that would work on both 32-bit and 64-bit OS because I could not find
any information about one during my research.  If you are not aware of
one, that's fine.  I am just trying to figure out a solution.

Another option I have is using something like:

Condition Message=[Message]PROPERTY/Condition

Is there any way that I can add a push button to the message box that
shows up that links to the website to install the .NET framework.  I
have been searching for an answer to this question, but am unable to
find one.

I also looked into doing something like this:

Condition Message=Setup requires .NET 2.0.  Please visit
http://msdn.microsoft.com/en-us/netframework/aa731542.aspx and
install.PROPERTY/Condition

Then, the user could click on the link and be taken to the website.  The
information I found stated this was not supported, but it was from a
long time ago, so I was just wondering if support has been added for
this.

Thanks for your help.  I have been struggling to find a solution for
this issue for several days now and your help is much appreciated.

Katelyn

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I don't know. Perhaps looking at the URL I pasted in my earlier reply or
maybe even looking for yourself on one of those newly invented search
engine things such as www.google.com might find you an answer?

Palbinder Sandher
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: 21 July 2010 16:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Is there a bootstrapper that I can use that will detect if the OS is
32-bit or 64-bit and then install the correct .NET Framework?

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher
Software

Re: [WiX-users] Custom Action not running

2010-07-20 Thread Thode, Katelyn
Thank you so much for all of your help.  This took care of the problem and the 
custom action is now correctly running on both xp and vista.

-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: Monday, July 19, 2010 6:35 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Custom Action not running


Deferred custom actions can only access the following properties: 
CustomActionData, ProductCode, and UserSID, except for commit actions that 
cannot access ProductCode either.



You could add this:



SetProperty Id=LaunchFile Value=[INSTALLDIR] Sequence=execute 
Before=LaunchFile/



and then change your MsiGetProperty calls to retrieve CustomActionData 
instead of INSTALLDIR.



.

 From: katelyn.th...@guidancesoftware.com
 To: wix-users@lists.sourceforge.net
 Date: Mon, 19 Jul 2010 16:35:02 -0400
 Subject: Re: [WiX-users] Custom Action not running

 The only access I make into the actual installation session in my custom 
 action is:

 UINT uiStat = MsiGetProperty(hInstall, _T(INSTALLDIR), _T(), valueBuff);

 And

 uiStat = MsiGetProperty(hInstall, _T(INSTALLDIR), szValueBuf, valueBuff);

 Is a deferred action not allowed to access this?



 -Original Message-
 From: Blair [mailto:os...@live.com]
 Sent: Monday, July 19, 2010 3:26 PM
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] Custom Action not running

 Then your custom action is likely attempting to access things in the
 session/database that deferred actions are not allowed to access (tables,
 most session properties, etc.).

 If the custom action's inputs are simple session property reads you can try
 creating a property called LaunchFile (named after your custom action)
 that contains all the data your custom action needs before your custom
 action is scheduled, and change your custom action to parse the data out of
 just the CustomActionData property (which will be the name you must use to
 access the property named after your custom action). Otherwise, you will
 need an initial custom action that is immediate that performs all of the
 database accesses and creates the property for the deferred action to use.

 -Original Message-
 From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
 Sent: Monday, July 19, 2010 11:35 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Custom Action not running

 Thanks for the responses. I have set the custom action to the following:

 Binary Id=loadDriver SourceFile=MyCustomAction.dll /
 CustomAction Id=LaunchFile
 BinaryKey=loadDriver
 DllEntry=wixTab1394
 Impersonate=no
 Execute=deferred/

 InstallExecuteSequence
 Custom Action=LaunchFile Before=InstallFinalizeNOT
 Installed/Custom
 /InstallExecuteSequence


 In Orca, in the CustomAction table, the type is 3073, which indicates that
 the custom action runs with no user impersonation at a scheduled point
 within the script. When I test the installer on vista, once the
 installation process reaches the custom action, it rollsback and the error
 dialog appears. Also, when I run the installer in xp, the custom action
 doesn't execute as it did with the previous custom action settings.


 -Original Message-
 From: Wilson, Phil [mailto:phil.wil...@invensys.com]
 Sent: Friday, July 16, 2010 3:48 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Custom Action not running

 The underlying issue is likely to be that UAC systems run impersonated
 custom actions without elevation, even if you are an administrator. ON XP
 your custom action would be running elevated with admin privs, but not on
 UAC, and that's why Blair is telling you how to make it elevated.

 Phil Wilson

 -Original Message-
 From: Blair [mailto:os...@live.com]
 Sent: Friday, July 16, 2010 10:28 AM
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] Custom Action not running

 For starters, the action must be scheduled between InstallInitialize and
 InstallFinalize, and must be marked as Execute=deferred with Impersonate
 set to no. Of course, at that point, the custom action does not have
 direct access to the database or most session properties.

 This smells like self-registration. The recommendation is to look more
 deeply into ways to make your driver registration more transparent in
 order to use code that has been more deeply tested for upgrades, repairs,
 rollbacks, removals, patching, etc.

 -Original Message-
 From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
 Sent: Friday, July 16, 2010 8:50 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Custom Action not running

 I did look at DifxApp, but for this particular application, I feel it would
 be best to use the application launched from the custom action being called
 for reasons that I won't go into as they are specific to the particular
 application

[WiX-users] .NET Framework 2.0 Bootstrapper

2010-07-20 Thread Thode, Katelyn
I am trying to use Microsoft Visual Studio 2005's bootstrapper to install the 
.NET Framework 2.0 if necessary.  Based on documentation I have found, I have 
the following in my .wixproj file:

  ItemGroup
BootstrapperFile Include=Microsoft.Net.Framework.2.0
  ProductName.NET Framework 2.0/ProductName
/BootstrapperFile
  /ItemGroup
  !--Target Name=BeforeBuild
  /Target--
  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=$(TargetFileName)
  ApplicationName=Tableau Disk Manager
  BootstrapperItems=@(BootstrapperFile)
  ComponentsLocation=Relative
  CopyComponents=True
  OutputPath=$(OutputPath)
  Path=C:\Program Files\Microsoft 
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx/

When I try to build the project, I get the following error messages:
warning MSB3155: Item 'Microsoft.Net.Framework.2.0' could not be located in 
'C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx'.
error MSB3147: Could not find required file 'setup.bin' in 'C:\Program 
Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx\Engine'.

I copied the dotnetfx folder into the Packages folder per documentation I found 
online.  I am struggling to find any information as to what I am doing wrong 
and any help would be appreciated.

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] .NET Framework 2.0 Bootstrapper

2010-07-20 Thread Thode, Katelyn
Thanks for the response.  I am on a 32-bit OS, so I changed the path to 
C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\.  When I built the project, MSB3155 went 
away, but I am still getting error MSB3147 about not being able to find 
setup.bin.

-Original Message-
From: Daniel Moody [mailto:dani...@gibbscam.com] 
Sent: Tuesday, July 20, 2010 1:53 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] .NET Framework 2.0 Bootstrapper

Katelyn,

I had the same issue myself.  In my case (on a 64-bit OS), the .bin files
were installed in the Program Files (x86) folder rather than Program
Files.  I didn't copy any files around that I can recall.  I used the
following Path statement:
Path=C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\ /

Everything else is identical to what you have.

Hopefully this might be helpful.

Daniel Moody | QA Engineer | Gibbs and Associates

Phone: 805-523-0004
Email: dani...@gibbscam.com

www.GibbsCAM.com

-Original Message-
Message: 6
Date: Tue, 20 Jul 2010 13:48:56 -0400
From: Thode, Katelyn katelyn.th...@guidancesoftware.com
Subject: [WiX-users] .NET Framework 2.0 Bootstrapper
To: wix-users@lists.sourceforge.net
wix-users@lists.sourceforge.net
Message-ID:

0fb074876ea3344bacf850c6c47681df0bd18...@postva.guidancesoftware.com
Content-Type: text/plain; charset=us-ascii

I am trying to use Microsoft Visual Studio 2005's bootstrapper to install
the .NET Framework 2.0 if necessary.  Based on documentation I have found, I
have the following in my .wixproj file:

  ItemGroup
BootstrapperFile Include=Microsoft.Net.Framework.2.0
  ProductName.NET Framework 2.0/ProductName
/BootstrapperFile
  /ItemGroup
  !--Target Name=BeforeBuild
  /Target--
  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=$(TargetFileName)
  ApplicationName=Tableau Disk Manager
  BootstrapperItems=@(BootstrapperFile)
  ComponentsLocation=Relative
  CopyComponents=True
  OutputPath=$(OutputPath)
  Path=C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx/

When I try to build the project, I get the following error messages:
warning MSB3155: Item 'Microsoft.Net.Framework.2.0' could not be located in
'C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx'.
error MSB3147: Could not find required file 'setup.bin' in 'C:\Program
Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx\Engine'.

I copied the dotnetfx folder into the Packages folder per documentation I
found online.  I am struggling to find any information as to what I am doing
wrong and any help would be appreciated.

Thanks,
Katelyn



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] .NET Framework 2.0 Bootstrapper

2010-07-20 Thread Thode, Katelyn
I was able to resolve the issue by adjusting the path.  Thanks for your help.

-Original Message-
From: Daniel Moody [mailto:dani...@gibbscam.com] 
Sent: Tuesday, July 20, 2010 1:53 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] .NET Framework 2.0 Bootstrapper

Katelyn,

I had the same issue myself.  In my case (on a 64-bit OS), the .bin files
were installed in the Program Files (x86) folder rather than Program
Files.  I didn't copy any files around that I can recall.  I used the
following Path statement:
Path=C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\ /

Everything else is identical to what you have.

Hopefully this might be helpful.

Daniel Moody | QA Engineer | Gibbs and Associates

Phone: 805-523-0004
Email: dani...@gibbscam.com

www.GibbsCAM.com

-Original Message-
Message: 6
Date: Tue, 20 Jul 2010 13:48:56 -0400
From: Thode, Katelyn katelyn.th...@guidancesoftware.com
Subject: [WiX-users] .NET Framework 2.0 Bootstrapper
To: wix-users@lists.sourceforge.net
wix-users@lists.sourceforge.net
Message-ID:

0fb074876ea3344bacf850c6c47681df0bd18...@postva.guidancesoftware.com
Content-Type: text/plain; charset=us-ascii

I am trying to use Microsoft Visual Studio 2005's bootstrapper to install
the .NET Framework 2.0 if necessary.  Based on documentation I have found, I
have the following in my .wixproj file:

  ItemGroup
BootstrapperFile Include=Microsoft.Net.Framework.2.0
  ProductName.NET Framework 2.0/ProductName
/BootstrapperFile
  /ItemGroup
  !--Target Name=BeforeBuild
  /Target--
  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=$(TargetFileName)
  ApplicationName=Tableau Disk Manager
  BootstrapperItems=@(BootstrapperFile)
  ComponentsLocation=Relative
  CopyComponents=True
  OutputPath=$(OutputPath)
  Path=C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx/

When I try to build the project, I get the following error messages:
warning MSB3155: Item 'Microsoft.Net.Framework.2.0' could not be located in
'C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx'.
error MSB3147: Could not find required file 'setup.bin' in 'C:\Program
Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx\Engine'.

I copied the dotnetfx folder into the Packages folder per documentation I
found online.  I am struggling to find any information as to what I am doing
wrong and any help would be appreciated.

Thanks,
Katelyn



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] .NET Framework 2.0 Bootstrapper

2010-07-20 Thread Thode, Katelyn
A quick follow up question - 
Dotnetfx is for 32-bit os.  What is for 64-bit os and where can I download it?

Thanks,
Katelyn

-Original Message-
From: Daniel Moody [mailto:dani...@gibbscam.com] 
Sent: Tuesday, July 20, 2010 1:53 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] .NET Framework 2.0 Bootstrapper

Katelyn,

I had the same issue myself.  In my case (on a 64-bit OS), the .bin files
were installed in the Program Files (x86) folder rather than Program
Files.  I didn't copy any files around that I can recall.  I used the
following Path statement:
Path=C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\ /

Everything else is identical to what you have.

Hopefully this might be helpful.

Daniel Moody | QA Engineer | Gibbs and Associates

Phone: 805-523-0004
Email: dani...@gibbscam.com

www.GibbsCAM.com

-Original Message-
Message: 6
Date: Tue, 20 Jul 2010 13:48:56 -0400
From: Thode, Katelyn katelyn.th...@guidancesoftware.com
Subject: [WiX-users] .NET Framework 2.0 Bootstrapper
To: wix-users@lists.sourceforge.net
wix-users@lists.sourceforge.net
Message-ID:

0fb074876ea3344bacf850c6c47681df0bd18...@postva.guidancesoftware.com
Content-Type: text/plain; charset=us-ascii

I am trying to use Microsoft Visual Studio 2005's bootstrapper to install
the .NET Framework 2.0 if necessary.  Based on documentation I have found, I
have the following in my .wixproj file:

  ItemGroup
BootstrapperFile Include=Microsoft.Net.Framework.2.0
  ProductName.NET Framework 2.0/ProductName
/BootstrapperFile
  /ItemGroup
  !--Target Name=BeforeBuild
  /Target--
  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=$(TargetFileName)
  ApplicationName=Tableau Disk Manager
  BootstrapperItems=@(BootstrapperFile)
  ComponentsLocation=Relative
  CopyComponents=True
  OutputPath=$(OutputPath)
  Path=C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx/

When I try to build the project, I get the following error messages:
warning MSB3155: Item 'Microsoft.Net.Framework.2.0' could not be located in
'C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx'.
error MSB3147: Could not find required file 'setup.bin' in 'C:\Program
Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx\Engine'.

I copied the dotnetfx folder into the Packages folder per documentation I
found online.  I am struggling to find any information as to what I am doing
wrong and any help would be appreciated.

Thanks,
Katelyn



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Custom Action not running

2010-07-19 Thread Thode, Katelyn
Thanks for the responses.  I have set the custom action to the following:

Binary Id=loadDriver SourceFile=MyCustomAction.dll /
CustomAction Id=LaunchFile 
  BinaryKey=loadDriver
  DllEntry=wixTab1394
  Impersonate=no 
  Execute=deferred/

InstallExecuteSequence
  Custom Action=LaunchFile Before=InstallFinalizeNOT 
Installed/Custom
/InstallExecuteSequence


In Orca, in the CustomAction table, the type is 3073, which indicates that the 
custom action runs with no user impersonation at a scheduled point within the 
script.  When I test the installer on vista, once the installation process 
reaches the custom action, it rollsback and the error dialog appears.  Also, 
when I run the installer in xp, the custom action doesn't execute as it did 
with the previous custom action settings.


-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com] 
Sent: Friday, July 16, 2010 3:48 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custom Action not running

The underlying issue is likely to be that UAC systems run impersonated custom 
actions without elevation, even if you are an administrator. ON XP your custom 
action would be running elevated with admin privs, but not on UAC, and that's 
why Blair is telling you how to make it elevated. 

Phil Wilson 

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Friday, July 16, 2010 10:28 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Custom Action not running

For starters, the action must be scheduled between InstallInitialize and
InstallFinalize, and must be marked as Execute=deferred with Impersonate
set to no. Of course, at that point, the custom action does not have
direct access to the database or most session properties.

This smells like self-registration. The recommendation is to look more
deeply into ways to make your driver registration more transparent in
order to use code that has been more deeply tested for upgrades, repairs,
rollbacks, removals, patching, etc.

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Friday, July 16, 2010 8:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custom Action not running

I did look at DifxApp, but for this particular application, I feel it would
be best to use the application launched from the custom action being called
for reasons that I won't go into as they are specific to the particular
application.  Is there a way to give the custom action the necessary
privilege to install drivers?

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Friday, July 16, 2010 10:40 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Custom Action not running

Not sure what your logging problem would be, but I suspect that your custom
action does not have the necessary privilege to install drivers.

Have you looked at DifxApp?

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Friday, July 16, 2010 8:17 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom Action not running

I am in the process of testing my installer on different operating systems.
The installer was created using 32-bit XP.  Everything works as expected and
the Custom Action is run.  The exit dialog states that the application has
been installed.  When I try running the installer on 32-bit Vista, all the
components get installed, but the custom action is not run.  In this case,
the exit dialog states that the installation ended prematurely due to an
error.  I tried to enable logging, but no log files were created.  Any tips
as to how to correctly enable logging or as to what might be causing this
issue?

The following is my custom action code:
!-- Install Driver Using Custom Action --
Binary Id=loadDriver SourceFile=MyCustomAction.dll /
CustomAction Id=LaunchFile
  BinaryKey=loadDriver
  DllEntry=wixTab1394 /

InstallExecuteSequence
  Custom Action=LaunchFile After=InstallFinalizeNOT
Installed/Custom
/InstallExecuteSequence

This DLL launches a program that installs device drivers.  As expected, on
32-bit XP, the device driver is installed, whereas on Vista the installation
exits before the custom action is run.

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying

[WiX-users] Logging Error

2010-07-19 Thread Thode, Katelyn
I am attempting to log the installation of a package I created.  When I run the 
following command line:

msiexec.exe /I C:/comp/code/libdbg/tfuInstaller.msi /l*v C:/Documents and 
Settings/name/My Documents/tfuInstaller.txt

I get an error message that states:
This installation package could not be opened.  Verify that the package exists 
and that you can access it, or contact the application vendor to verify that 
this is a valid Windows Installer Package.

If I go to the directory and run the .msi from there, the installer runs.  Am I 
doing something wrong?



Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Custom Action not running

2010-07-19 Thread Thode, Katelyn
The only access I make into the actual installation session in my custom action 
is:

 UINT uiStat = MsiGetProperty(hInstall, _T(INSTALLDIR), _T(), valueBuff);

And 

uiStat = MsiGetProperty(hInstall, _T(INSTALLDIR), szValueBuf, valueBuff);

Is a deferred action not allowed to access this?  



-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, July 19, 2010 3:26 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Custom Action not running

Then your custom action is likely attempting to access things in the
session/database that deferred actions are not allowed to access (tables,
most session properties, etc.).

If the custom action's inputs are simple session property reads you can try
creating a property called LaunchFile (named after your custom action)
that contains all the data your custom action needs before your custom
action is scheduled, and change your custom action to parse the data out of
just the CustomActionData property (which will be the name you must use to
access the property named after your custom action). Otherwise, you will
need an initial custom action that is immediate that performs all of the
database accesses and creates the property for the deferred action to use.

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Monday, July 19, 2010 11:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custom Action not running

Thanks for the responses.  I have set the custom action to the following:

Binary Id=loadDriver SourceFile=MyCustomAction.dll /
CustomAction Id=LaunchFile 
  BinaryKey=loadDriver
  DllEntry=wixTab1394
  Impersonate=no 
  Execute=deferred/

InstallExecuteSequence
  Custom Action=LaunchFile Before=InstallFinalizeNOT
Installed/Custom
/InstallExecuteSequence


In Orca, in the CustomAction table, the type is 3073, which indicates that
the custom action runs with no user impersonation at a scheduled point
within the script.  When I test the installer on vista, once the
installation process reaches the custom action, it rollsback and the error
dialog appears.  Also, when I run the installer in xp, the custom action
doesn't execute as it did with the previous custom action settings.


-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com] 
Sent: Friday, July 16, 2010 3:48 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custom Action not running

The underlying issue is likely to be that UAC systems run impersonated
custom actions without elevation, even if you are an administrator. ON XP
your custom action would be running elevated with admin privs, but not on
UAC, and that's why Blair is telling you how to make it elevated. 

Phil Wilson 

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Friday, July 16, 2010 10:28 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Custom Action not running

For starters, the action must be scheduled between InstallInitialize and
InstallFinalize, and must be marked as Execute=deferred with Impersonate
set to no. Of course, at that point, the custom action does not have
direct access to the database or most session properties.

This smells like self-registration. The recommendation is to look more
deeply into ways to make your driver registration more transparent in
order to use code that has been more deeply tested for upgrades, repairs,
rollbacks, removals, patching, etc.

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Friday, July 16, 2010 8:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custom Action not running

I did look at DifxApp, but for this particular application, I feel it would
be best to use the application launched from the custom action being called
for reasons that I won't go into as they are specific to the particular
application.  Is there a way to give the custom action the necessary
privilege to install drivers?

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Friday, July 16, 2010 10:40 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Custom Action not running

Not sure what your logging problem would be, but I suspect that your custom
action does not have the necessary privilege to install drivers.

Have you looked at DifxApp?

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Friday, July 16, 2010 8:17 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom Action not running

I am in the process of testing my installer on different operating systems.
The installer was created using 32-bit XP.  Everything works as expected and
the Custom Action is run

Re: [WiX-users] Logging Error

2010-07-19 Thread Thode, Katelyn
Thanks for the response.  That appears to have been the issue.

-Original Message-
From: Jeremy Farrell [mailto:jfarr...@pillardata.com] 
Sent: Monday, July 19, 2010 5:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Logging Error

Perhaps Windows path separators (\) in the paths?

 From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
 
 I am attempting to log the installation of a package I 
 created.  When I run the following command line:
 
 msiexec.exe /I C:/comp/code/libdbg/tfuInstaller.msi /l*v 
 C:/Documents and Settings/name/My Documents/tfuInstaller.txt
 
 I get an error message that states:
 This installation package could not be opened.  Verify that 
 the package exists and that you can access it, or contact the 
 application vendor to verify that this is a valid Windows 
 Installer Package.
 
 If I go to the directory and run the .msi from there, the 
 installer runs.  Am I doing something wrong?
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Porting installer to WiX

2010-07-16 Thread Thode, Katelyn
Thanks - I do have it all ported over without looking at the previous source 
code.  I am just interested in getting the upgrade GUID and the previous 
product GUIDs.

I was able to locate the extracted .msi files on my hard drive.  Thank you all 
for your help.

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Friday, July 16, 2010 8:20 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Porting installer to WiX

They won't be able to say where it extracted because while different versions 
have had default locations, it's always been a setting the developer can 
override.  Short of searching the whole hard drive, the easist thing to do is 
enable MSI logging in the registry and start the install.   Once you see the 
logfile get created, look for the value of the OriginalDatabase property.

I have extensive experience in converting InstallShield projects to WiX and 
personally I reccomend treating it as a major upgrade and  take the liberty of 
not just porting it over but also taking the opportunity to refactor the whole 
design.  Not a ding against InstallShield just a realization that the former 
developer probably made some really poor choices.

 
- Original Message 
From: Bob Arnson b...@joyofsetup.com
To: wix-users@lists.sourceforge.net
Sent: Fri, July 16, 2010 7:52:38 AM
Subject: Re: [WiX-users] Porting installer to WiX

On 7/15/2010 8:02 PM, Wilson, Phil wrote:
 If you have WinZip and you open that exe with it, you may see the embedded 
files. Or the internals might be proprietary. Otherwise as I said. If you run 
the exe the MSI file will be extracted somewhere, just hunt for it and 
copy/save 
it.
    

Or ask InstallShield how to do it...

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


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Custom Action not running

2010-07-16 Thread Thode, Katelyn
I am in the process of testing my installer on different operating systems.  
The installer was created using 32-bit XP.  Everything works as expected and 
the Custom Action is run.  The exit dialog states that the application has been 
installed.  When I try running the installer on 32-bit Vista, all the 
components get installed, but the custom action is not run.  In this case, the 
exit dialog states that the installation ended prematurely due to an error.  I 
tried to enable logging, but no log files were created.  Any tips as to how to 
correctly enable logging or as to what might be causing this issue?

The following is my custom action code:
!-- Install Driver Using Custom Action --
Binary Id=loadDriver SourceFile=MyCustomAction.dll /
CustomAction Id=LaunchFile
  BinaryKey=loadDriver
  DllEntry=wixTab1394 /

InstallExecuteSequence
  Custom Action=LaunchFile After=InstallFinalizeNOT Installed/Custom
/InstallExecuteSequence

This DLL launches a program that installs device drivers.  As expected, on 
32-bit XP, the device driver is installed, whereas on Vista the installation 
exits before the custom action is run.

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Porting installer to WiX

2010-07-16 Thread Thode, Katelyn
Thanks - that worked perfectly!

-Original Message-
From: Michael Urman [mailto:mur...@gmail.com] 
Sent: Friday, July 16, 2010 10:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Porting installer to WiX

While extracting it from the temp folder, or the cached location
mentioned in a log file will work, why not just perform an
administrative install? This way you can drop the .msi file wherever
you'd like.

http://helpnet.flexerasoftware.com/robo/projects/installshield12helplib/IHelpSetup_EXECmdLine.htm#wp1021718

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Custom Action not running

2010-07-16 Thread Thode, Katelyn
I did look at DifxApp, but for this particular application, I feel it would be 
best to use the application launched from the custom action being called for 
reasons that I won't go into as they are specific to the particular 
application.  Is there a way to give the custom action the necessary privilege 
to install drivers?

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Friday, July 16, 2010 10:40 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Custom Action not running

Not sure what your logging problem would be, but I suspect that your custom
action does not have the necessary privilege to install drivers.

Have you looked at DifxApp?

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Friday, July 16, 2010 8:17 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom Action not running

I am in the process of testing my installer on different operating systems.
The installer was created using 32-bit XP.  Everything works as expected and
the Custom Action is run.  The exit dialog states that the application has
been installed.  When I try running the installer on 32-bit Vista, all the
components get installed, but the custom action is not run.  In this case,
the exit dialog states that the installation ended prematurely due to an
error.  I tried to enable logging, but no log files were created.  Any tips
as to how to correctly enable logging or as to what might be causing this
issue?

The following is my custom action code:
!-- Install Driver Using Custom Action --
Binary Id=loadDriver SourceFile=MyCustomAction.dll /
CustomAction Id=LaunchFile
  BinaryKey=loadDriver
  DllEntry=wixTab1394 /

InstallExecuteSequence
  Custom Action=LaunchFile After=InstallFinalizeNOT
Installed/Custom
/InstallExecuteSequence

This DLL launches a program that installs device drivers.  As expected, on
32-bit XP, the device driver is installed, whereas on Vista the installation
exits before the custom action is run.

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Porting installer to WiX

2010-07-15 Thread Thode, Katelyn
I am working on porting an InstallShield installer over to wix.  I don't have 
the source code for the installer and the installer itself is an executable 
file.  Is there a way to get the GUIDs for the product Id and upgrade code from 
the executable file?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Porting installer to WiX

2010-07-15 Thread Thode, Katelyn
Thanks for the quick response.  It seems like SuperOrca is an MSI editor.  I 
have a .exe file that I need to get the upgrade GUID from.

-Original Message-
From: Alec Taylor [mailto:alec.tayl...@gmail.com] 
Sent: Thursday, July 15, 2010 11:51 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Porting installer to WiX

Yes, a million info programs around

Try SuperORCA

On Fri, Jul 16, 2010 at 2:39 AM, Thode, Katelyn
katelyn.th...@guidancesoftware.com wrote:
 I am working on porting an InstallShield installer over to wix.  I don't have 
 the source code for the installer and the installer itself is an executable 
 file.  Is there a way to get the GUIDs for the product Id and upgrade code 
 from the executable file?

 Thanks,
 Katelyn

 Note: The information contained in this message may be privileged and
 confidential and thus protected from disclosure. If the reader of this
 message is not the intended recipient, or an employee or agent responsible
 for delivering this message to the intended recipient, you are hereby
 notified that any dissemination, distribution or copying of this
 communication is strictly prohibited.  If you have received this
 communication in error, please notify us immediately by replying to the
 message and deleting it from your computer.  Thank you.

 --
 This SF.net email is sponsored by Sprint
 What will you do first with EVO, the first 4G phone?
 Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Porting installer to WiX

2010-07-15 Thread Thode, Katelyn
The executable wraps an msi that was created with InstallShield 12.  Is there a 
way for me to extract the msi?

-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com] 
Sent: Thursday, July 15, 2010 12:40 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Porting installer to WiX

It can't be MSI-based with guids everywhere *and* be simply an executable, so 
I'd verify that it's not an older non-MSI setup of the type that InstallShield 
used to do. If it is MSI-based and an exe, then maybe the MSI file is embedded 
in the resources of the exe (something like Winzip might show you that), or if 
you run it then there'll be an MSI file pop out somewhere to be installed, then 
you can use Orca to look at it, and Dark to decompile it to WiX source. 

Phil Wilson 

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Thursday, July 15, 2010 9:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Porting installer to WiX

I am working on porting an InstallShield installer over to wix.  I don't have 
the source code for the installer and the installer itself is an executable 
file.  Is there a way to get the GUIDs for the product Id and upgrade code from 
the executable file?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at Portland House, Bressenden Place, London, 
SW1E 5BF (Registered number 166023). For a list of European legal entities 
within the Invensys Group, please go to 
http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. 
You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail 
inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be 
subject to the terms of any agreements between Invensys (and/or its 
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and 
affiliates).



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Upgrade Help

2010-07-14 Thread Thode, Katelyn
Hello,

I am working on creating a wix installer to upgrade an existing application.  
If I try to install an older version of the application, the installer 
indicates that a newer version is installed and exits the setup as expected.

 The issue I am having occurs when a newer version is detected and an upgrade 
occurs.  In the older versions of the installer, the application is under the 
start menu as [Application Name] - application, uninstall, user's guide.  In 
the newer version, the setup for the start menu is [company name] - 
[application name] - application, uninstall, user's guide.

When I try to upgrade, the newer version is added and, in the Program Files 
directory, the files are changed.  But, the desktop icon and the start menu 
shortcuts remain.  Is there a way for me to remove the old shortcuts using a 
standard action?

Below is the upgrade code I currently have:

!-- Upgrade Information --
Upgrade Id=$(var.UpgradeCode)
  UpgradeVersion Minimum=0.0.0
  Maximum=$(var.ProductVersion)
  IncludeMinimum=yes
  Language=1033
  Property=OLDUPGRADE /
  UpgradeVersion Minimum=$(var.ProductVersion)
  OnlyDetect=yes
  Language=1033
  Property=DETECTNEW /
/Upgrade

InstallExecuteSequence
  RemoveExistingProducts After=InstallInitialize /
/InstallExecuteSequence

Condition Message=A later version of [ProductName] is already installed.  
Setup will now exit.
  NOT DETECTNEW OR Installed
/Condition

!-- On upgrade find out the install directory --
CustomAction Id=SaveTargetDir Property=ARPINSTALLLOCATION 
Value=[INSTALLDIR] /

InstallExecuteSequence
  Custom Action=SaveTargetDir After=InstallValidate
NOT
Installed
  /Custom
/InstallExecuteSequence

InstallUISequence
  !-- App search is what does FindInstallLocation, and it is dependent on 
FindRelatedProducts --
  AppSearch After=FindRelatedProducts /
/InstallUISequence

!-- Find previous installation location --
Property Id=INSTALLDIR
  RegistrySearch Id=FindInstallation
  Root=HKLM
  Key=$(var.RegistryKey)
  Name=InstallDir
  Type=raw /
/Property

Thanks for your help,
Katelyn


Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Upgrade Help

2010-07-14 Thread Thode, Katelyn
Yes, the shortcuts do remain if I remove the older version without installing 
the newer version.

Code for shortcuts in new version:
!-- Declare Start Menu Shortcuts --
DirectoryRef Id=ProgramMenuFolder
  Directory Id=TFirmwareUtilFolder Name=$(var.ProductName)
Component Id=ShortcutComponent 
Guid={B4BD1198-1A40-4138-9E8D-3B3AD383D9D6}
  Shortcut Id=startmenuTfirmwareutil
Name=$(var.ProductName)
WorkingDirectory=INSTALLDIR
Target=[INSTALLDIR]$(var.ExeName)
Icon=AppIcon
IconIndex=0 /
  Shortcut Id=TFUUsersGuide
Name=$(var.ProductName) Users Guide.pdf
Target=[INSTALLDIR] Firmware Update Users Guide.pdf /
  Shortcut Id=UninstallProduct
Name=Uninstall $(var.ProductName)
Target=[System64Folder]msiexec.exe
Arguments=/x [ProductCode]
Description=Uninstalls $(var.ProductName) /
  RegistryValue Root=HKMU Key=$(var.RegistryKey) Name=installed 
Type=integer Value=1 KeyPath=yes /
  RemoveFolder Id=TFirmwareUtilFolder On=uninstall /
  RemoveFolder Id=ProgramMenuFolder Directory=ProgramMenuFolder 
On=uninstall /
/Component
  /Directory
/DirectoryRef


!-- Declare Desktop Shortcut --
DirectoryRef Id=DesktopFolder
  Component Id=DesktopComponent 
Guid={536F3500-D603-4D59-B4B7-DC7CAFEB7B01}
CreateFolder /
RegistryKey Root=HKMU
 Key=$(var.RegistryKey)
 Action=createAndRemoveOnUninstall
  RegistryValue Name=DTSC Value=1 Type=integer KeyPath=yes/
/RegistryKey
Shortcut Id=desktopShortcut
  Directory=DesktopFolder
  Name=$(var.ProductName)
  WorkingDirectory='INSTALLDIR'
  Target=[INSTALLDIR]$(var.ExeName)
  Icon=AppIcon /
  /Component
/DirectoryRef

For the old version, I only have the .msi and not the associated code.  
According to the table in Orca:
ShortcutDirectory Name   
ComponentTarget
New_Shortcut_S3740  newfolder1TABLEA~1|Firmware Update   
tabup.exe2   AlwaysInstall
NewShortcut2newfolder1TABLEA~1|Firmware Update User's Guide  
ISX_DEFAULTCOMPONENT_2   [INSTALLDIR]Firmware_Update_Users_Guide.pdf
NewShortcut3newfolder1UNINST~1|Uninstall Firmware Update 
ISX_DEFAULTCOMPONENT_2   [SystemFolder]Msi.Exec.exe
New_Shortcut_S3815  DesktopFolder TABLEA~1|Firmware Update   
tabup.exe2   AlwaysInstall

For comparison purposes, here is the table in Orca for the new code:
ShortcutDirectory Name  
 Component   Target
desktopShortcut DesktopFolder xxwpvyht|Firmware Update  
 DesktopComponent[INSTALLDIR]tabup.exe
startmenuTfirmwareutil  TFirmwareUtilFolder   ziyqatsf|Firmware Update  
 ShortcutComponent   [INSTALLDIR]tabup.exe
TFUUsersGuide   TFirmwareUtilFolder   zwacagjn.pdf|Firmware Update 
Users Guide.pdf   ShortcutComponent   [INSTALLDIR]Firmware Update Users 
Guide.pdf
UninstallProductTFirmwareUtilFolder   z2qb0bcp|Uninstall Firmware 
Update ShortcutComponent   [System64Folder]msiexec.exe

Again, thanks for your help.
Katelyn

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, July 14, 2010 10:41 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrade Help

If you simply remove the older version (without installing the newer
version), do the shortcuts remain?

What is your associated code for the shortcuts in both old and new versions?

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Wednesday, July 14, 2010 7:45 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrade Help

Hello,

I am working on creating a wix installer to upgrade an existing application.
If I try to install an older version of the application, the installer
indicates that a newer version is installed and exits the setup as expected.

 The issue I am having occurs when a newer version is detected and an
upgrade occurs.  In the older versions of the installer, the application is
under the start menu as [Application Name] - application, uninstall, user's
guide.  In the newer version, the setup for the start menu is [company name]
- [application name] - application, uninstall, user's guide.

When I try to upgrade, the newer version is added and, in the Program Files
directory, the files are changed.  But, the desktop icon and the start menu
shortcuts remain.  Is there a way for me to remove the old shortcuts using a
standard action?

Below

Re: [WiX-users] Upgrade Help

2010-07-14 Thread Thode, Katelyn
Thank you!

The new version does remove its shortcuts.

If I use the RemoveFile element on an update, if the file doesn't exist when it 
tries to remove it, will an error occur?

If so, how do I check to verify that the files do exist?

Thanks,
Katelyn

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, July 14, 2010 1:53 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrade Help

Then you have done nothing wrong in your new version (assuming it does
remove its shortcuts). You could use the RemoveFile element in WiX to remove
the previous shortcuts on installation.

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Wednesday, July 14, 2010 9:09 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade Help

Yes, the shortcuts do remain if I remove the older version without
installing the newer version.

Code for shortcuts in new version:
!-- Declare Start Menu Shortcuts --
DirectoryRef Id=ProgramMenuFolder
  Directory Id=TFirmwareUtilFolder Name=$(var.ProductName)
Component Id=ShortcutComponent
Guid={B4BD1198-1A40-4138-9E8D-3B3AD383D9D6}
  Shortcut Id=startmenuTfirmwareutil
Name=$(var.ProductName)
WorkingDirectory=INSTALLDIR
Target=[INSTALLDIR]$(var.ExeName)
Icon=AppIcon
IconIndex=0 /
  Shortcut Id=TFUUsersGuide
Name=$(var.ProductName) Users Guide.pdf
Target=[INSTALLDIR] Firmware Update Users Guide.pdf /
  Shortcut Id=UninstallProduct
Name=Uninstall $(var.ProductName)
Target=[System64Folder]msiexec.exe
Arguments=/x [ProductCode]
Description=Uninstalls $(var.ProductName) /
  RegistryValue Root=HKMU Key=$(var.RegistryKey)
Name=installed Type=integer Value=1 KeyPath=yes /
  RemoveFolder Id=TFirmwareUtilFolder On=uninstall /
  RemoveFolder Id=ProgramMenuFolder Directory=ProgramMenuFolder
On=uninstall /
/Component
  /Directory
/DirectoryRef


!-- Declare Desktop Shortcut --
DirectoryRef Id=DesktopFolder
  Component Id=DesktopComponent
Guid={536F3500-D603-4D59-B4B7-DC7CAFEB7B01}
CreateFolder /
RegistryKey Root=HKMU
 Key=$(var.RegistryKey)
 Action=createAndRemoveOnUninstall
  RegistryValue Name=DTSC Value=1 Type=integer
KeyPath=yes/
/RegistryKey
Shortcut Id=desktopShortcut
  Directory=DesktopFolder
  Name=$(var.ProductName)
  WorkingDirectory='INSTALLDIR'
  Target=[INSTALLDIR]$(var.ExeName)
  Icon=AppIcon /
  /Component
/DirectoryRef

For the old version, I only have the .msi and not the associated code.
According to the table in Orca:
ShortcutDirectory Name
ComponentTarget
New_Shortcut_S3740  newfolder1TABLEA~1|Firmware Update
tabup.exe2   AlwaysInstall
NewShortcut2newfolder1TABLEA~1|Firmware Update User's Guide
ISX_DEFAULTCOMPONENT_2   [INSTALLDIR]Firmware_Update_Users_Guide.pdf
NewShortcut3newfolder1UNINST~1|Uninstall Firmware Update
ISX_DEFAULTCOMPONENT_2   [SystemFolder]Msi.Exec.exe
New_Shortcut_S3815  DesktopFolder TABLEA~1|Firmware Update
tabup.exe2   AlwaysInstall

For comparison purposes, here is the table in Orca for the new code:
ShortcutDirectory Name
Component   Target
desktopShortcut DesktopFolder xxwpvyht|Firmware Update
DesktopComponent[INSTALLDIR]tabup.exe
startmenuTfirmwareutil  TFirmwareUtilFolder   ziyqatsf|Firmware Update
ShortcutComponent   [INSTALLDIR]tabup.exe
TFUUsersGuide   TFirmwareUtilFolder   zwacagjn.pdf|Firmware Update
Users Guide.pdf   ShortcutComponent   [INSTALLDIR]Firmware Update Users
Guide.pdf
UninstallProductTFirmwareUtilFolder   z2qb0bcp|Uninstall Firmware
Update ShortcutComponent   [System64Folder]msiexec.exe

Again, thanks for your help.
Katelyn

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, July 14, 2010 10:41 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrade Help

If you simply remove the older version (without installing the newer
version), do the shortcuts remain?

What is your associated code for the shortcuts in both old and new versions?

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Wednesday, July 14, 2010 7:45 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrade Help

Hello,

I am working on creating a wix installer to upgrade an existing application.
If I try to install an older version of the application, the installer