Re: [WiX-users] Two Entries in Add or Remove Programs
Success! Alex Shevchuk wrote: OK, here is the problem. Upgrade/@Id must have the same value as Product/@UpgradeCode. Thank you, Alex. That was the problem. FindRelatedProducts is working and only one entry exists in the Add or Remove Programs table after the installation of the new version. Now, along with Do not change the Product UpgradeCode, I have Verify that the Product UpgradeCode is identical to the Upgrade ID in my upgrade checklist. My gratitude goes also to Phil, Stephen and Michael. In this exchange I have uncovered other problems in my installer. -- Charles -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Two Entries in Add or Remove Programs
Wilson, Phil wrote: Get an MSI log to see what's going on. Look at all instances of FindRelatedProducts to see if it's detecting your older product. There are two sections of FindRelatedProducts in the log for the 1.1 version upgrade installation. MSI (c) (28:8C) [18:56:27:953]: Doing action: FindRelatedProducts MSI (c) (28:8C) [18:56:27:968]: Note: 1: 2205 2: 3: ActionText Action 18:56:27: FindRelatedProducts. Searching for related applications Action start 18:56:27: FindRelatedProducts. Action ended 18:56:27: FindRelatedProducts. Return value 1. and MSI (s) (C8:34) [18:56:32:968]: Doing action: FindRelatedProducts MSI (s) (C8:34) [18:56:32:984]: Note: 1: 2205 2: 3: ActionText Action 18:56:32: FindRelatedProducts. Searching for related applications Action start 18:56:32: FindRelatedProducts. MSI (s) (C8:34) [18:56:32:984]: Skipping FindRelatedProducts action: already done on client side Action ended 18:56:32: FindRelatedProducts. Return value 0. Does that look right? Why is REP after InstallFinalize? I was following the recommendation in the fourth bullet point of the Sequence Restrictions section of http://msdn.microsoft.com/en-us/library/aa371197(VS.85).aspx. I've tried the other possibilities too. I still end up with two entries in the Add or Remove Programs table. -- Charles -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Two Entries in Add or Remove Programs
Wilson, Phil wrote:
That means it didn't find the previous version for some reason
otherwise it would mention the ProductCode guid of the discovered
product. What's actually in the Upgrade table in the MSI file? I'm
wondering if the version range is really correct.
From Orca, here are the two entries in the Upgrade table for the Version 1.1
package:
UpgradeCode: {49AB249B-C143-412E-B138-6689533DC53A}
VersionMin: 1.1.0.0
VersionMax: [none]
Attributes: 258
ActionProperty: NEWERVERSIONDETECTED
UpgradeCode: {49AB249B-C143-412E-B138-6689533DC53A}
VersionMin: 0.0.0.0
VersionMax: 1.1.0.0
Attributes: 256
ActionProperty: OLDERVERSIONBEINGUPGRADED
That location for REP is more efficient because the file replacement
rules are such that you have many files that aren't going to be
updated. If a lot are going to be updated anyway the efficiency
decreases. However it's not a safe location because of the rollback
issue. There is a similar efficient location (assuming efficiency is
valued more than safety ;=) ) which is directly before
InstallFinalize using [InstallExecute, RemovePreviousVersions,
InstallFinalize ], which is what the 3rd bullet is saying...
I have now moved RemovePreviousVersions to the position after InstallExecute
and before InstallFinalize.
--
Charles
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Two Entries in Add or Remove Programs
Schaff, Stephen wrote: That fixed it! Thanks! I think you replied to the wrong message, Stephen. The 'two entries' problem continues. -- Charles -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Two Entries in Add or Remove Programs
Alex Shevchuk wrote: Well, if per-user/per-machine context did not change, I can only suggest comparing your upgrade steps to steps in here: ...from-msi-to-wix-part-8-major-upgrade.aspx I worked through that page of instructions. That resulted in a few changes. In the Package element I added SummaryCodepage=1252, a few Keywords, ShortNames=no AdminImage=no and ReadOnly=no. Apparently I still have problems with FindRelatedProducts. Next I'm going to analyze the installation log. -- Charles -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Two Entries in Add or Remove Programs
I have been testing the major upgrade procedure under WiX Version 3.0.5217.0 and Windows XP. I install version 1.0 of my application successfully. (It has the required Upgrade element.) To prepare for the next version of my application I increment the FILEVERSION, PRODUCTVERSION and FileVersion values in resource file from 1.0 to 1.1 and rebuild the executable. (WiX Edit reads the File Version--see below.) I go back to Wix Edit and change both the Product GUID and the Package GUID. The Upgrade ID GUID does not change. I rebuild the MSI setup package. Then I use this new package to install version 1.1 of my application. Version 1.1 of the program installs successfully but I am left with two entries in Control Panel Add or Remove Programs. One points to version 1.0; the other points to version 1.1. Upgrade Id=49AB249B-C143-412E-B138-6689533DC53A UpgradeVersion Property=OLDERVERSIONBEINGUPGRADED Maximum=!(bind.FileVersion.gssta_exe) IncludeMinimum=yes OnlyDetect=no IncludeMaximum=no Minimum=0.0.0.0 / UpgradeVersion Property=NEWERVERSIONDETECTED Minimum=!(bind.FileVersion.gssta_exe) OnlyDetect=yes IncludeMinimum=yes / /Upgrade InstallExecuteSequence RemoveExistingProducts After=InstallFinalize / /InstallExecuteSequence In the Add or Remove Programs table, if I select Remove for version 1.0 (after version 1.1 is installed) the application is not removed. (The table entry does go away.) If I select Remove for version 1.1, the application is removed. What can I do to ensure that only the latest version is shown in the Add or Remove Programs table? -- Charles -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Compression level
Chris Ridd wrote: Yes, the higher compression levels make building the msi much slower. If you've got the concept of a debug vs release build, I'd suggest using no compression when debugging, and high when doing a release. In the interest of science I ran through the compression levels on the .msi build of one of my programs. Compression Level Time (seconds) File Size (MB) none 11 6.05 mszip 11 2.25 (default) low 11 1.91 medium 12 1.81 high 14 1.73 That's quite a space saving for a few seconds wait. Windows XP on an AMD running at 2.1 GHz. -- Chuck Brockman -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating Per-User Registry Entries in a Per-Machine Installation
Neil Sleightholm wrote: ...I would suggest that the right place to do this is in your application on first run not in the installation. Rob Mensching wrote: IMHO, the best way to handle this is to put the default settings in the code or, if you must, put them in HKLM. Then your application reads from HKCU and if it doesn't find the setting there it falls back to where the default location is. That way you only write the settings that the user changes from the default (saves time and space). I'll take your advice and put the routine to write create the HKCU entries and default values into my application. This is even more important since there is no good way to clean up all HKCU registry keys on uninstall. If a user runs my application and later it is uninstalled, the users will have to live with the orphaned registry entry. Perhaps a registry cleaner will scrub it away. Few, if any, users will notice. george_r wrote: Chuck, try: Property Id=ALLUSERS1/Property That's what InstallScope=perMachine does and from http://www.joyofsetup.com/2008/04/01/new-wix-feature-setting-package-installation-scope/: If you specify perMachine, you must remove any Property element that sets ALLUSERS. and set the initial registry values to HKCU. Are you sure that the HKCU registry entry exists for any user other than the one that performed the installation? In my experience only the installing user receives the HKCU entry. -- Charles -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Creating Per-User Registry Entries in a Per-Machine Installation
My application installs on a per-machine basis so that it is available to all users. I have InstallPrivileges=elevated and InstallScope=perMachine. In addition, the installer creates some registry entries for my application in HKLM because I have specified Root=HKMU. I would like to set some default registry values so that they are available to the individual user upon the first invocation of the application. The user must be able to modify those values and the values for each user must be distinct from those of other users. Therefore HKCU and not HKLM registry entries must be used. Is there a mechanism for the installer to create registry entries in the HKCU tree for each user in this scenario? If that is possible, can all such HKCU registry entries be removed when the application is uninstalled? Configuration: schemas.microsoft.com/wix/2006/wi, WiX binaries version 3.0.4909.0, WiXEdit version 0.6.1762.0 -- Charles -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] wix nubie - Cannot connect to IIS error message
This is probably something very simple, but seeing as I am new to wix I just can't figure it out... I am installing a web app on a 2008 server with IIS7. When I run the .msi everything seems to work properly except that a window pops up with the message, Cannot connect to Internet Information Server (-2147221164 ). When I check the install directory all the files are installed correctly and they even show up in IIS manager. The only thing I have to do from that point is right click my app under the default web site and choose 'convert to application'. After that everything works just fine. I checked the log files and from what I can tell there are no errors...I just don't understand why its giving me the message and how to fix it. Any help would be appreciated. -- Thanks, Chuck Hanna - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Vista error?
I have created a WIX installer that works perfectly on XP and it also works, almost perfectly, on Vista. The problem I'm having is that after the installation has completed Vista puts up a message box that says ProductName installer has stopped working. The software has been installed properly and everything works!! Any ideas of what might be this issue would be greatly appreciated. Thanx Chuck - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [Fwd: Re: CA with elevated privileges under Vista!]
Phil, In my initial post is said " I am wrapping the msi in a setup.exe boot strapper that has a manifest with requestedExecutionLevel level="requireAdministrator"." When the setup.exe is run it does prompt for an Administrators password. However, the CA is still not running as Administrator. I know it is failing because I have the exact same code that the CA calls wrapped up as an exe and if I run it as admin and then look at the output from both it is different. Any other thoughts would be greatly appreciated. Thanx Chuck I suspect you're misunderstanding something, assuming I understand your point 4. Neither AdminUser nor Privileged will cause your CA to run elevated. They're typically used as LaunchConditions, and they also happen to be unreliable in Vista in the UI sequence. To get your CA to run elevated in the UI sequence you need to launch it with elevated privilege, and an elevated bootstrapper can do that, and that in turn requires an administrator account to do the launching. Bottom line, you must supply an admin account somewhere. At the risk of stating the obvious, this is not a scenario in which a standard user can cause elevated code to run during an install.=20 Phil Wilson=20 Phil, Thanx for your response. 1. Yes, "early in the installation process" does mean in the UI sequence... I know that this is not a recommended way to execute elevated CAs but I have a task that must be done prior to displaying a custom dialog that requires it. 2. I stuffed the manifest into the dll to ensure that all of my bases were covered...I haven't done a lot of work with them in the past and I figured that what you said would be true but just wanted to make sure I hadn't missed it if it was needed. 3. The setup.exe is asking for an Admin password if I am running the install as a "Standard" user...and it is asking for the OK to go ahead and run if I am logged on as an Admin user. 4. I've tried using both AdminUser and Privileged properties and neither of them causes the CA to run as admin! Any other thoughts on how I can get this CA to run as an Administrator? Thanx Chuck A couple or four things:=20 1) Does "early in the installation process" mean in the UI sequence?=20 2) Manifests target executables, not Dlls - they run with the level of the exe that loads them.=20 3) If the setup.exe isn't asking for elevation via Cancel/Allow but is asking for an admin account, then it means you're not an administrator but you need to be. Someone has to provide admin credentials, either you elevated to admin or somebody "over the shoulder" on your behalf.=20 4) AdminUser is unreliable under Vista. =20 =20 http://blogs.msdn.com/rflaming/archive/2006/09/21/uac-in-msi-notes-the-a dminuser-mistake.aspx =20 Phil Wilson=20 Chuck wrote: I have the following situation: I am creating an MSI in which I need to run a CA early in the installation process, the DA is in a C dll. The CA "Requires" Admin access under Vista. I am wrapping the msi in a setup.exe boot strapper that has a manifest with requestedExecutionLevel level="requireAdministrator". In my WIX project I have a condition for AdminUser and in the package I have InstallPrivileges set to elevated. The dll has requireAdministrator in its manifest. The problem that I'm having is that the code that I'm executing in my CA fails to execute correctly. I extracted the code and compiled it into an exe with the same manifest as above. When I run the exe the code completes correctly! In both cases I am getting prompted for an Admin password...which would lead one to think that the installer is running as an Admin user...but the CA fails. Any thoughts on this would be greatly appreciated. Thanx Chuck -- Chuck Hatt Magic Kite Software Ltd Makers of Sourcerer: managing the risks in your software development. Phone: 250.383.8175 Cell: 250.889.0119 email: [EMAIL PROTECTED] -- Chuck Hatt Magic Kite Software Ltd Makers of Sourcerer: managing the risks in your software development. Phone: 250.383.8175 Cell: 250.889.0119 email: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CA with elevated privileges under Vista!
Phil, Thanx for your response. 1. Yes, "early in the installation process" does mean in the UI sequence...I know that this is not a recommended way to execute elevated CAs but I have a task that must be done prior to displaying a custom dialog that requires it. 2. I stuffed the manifest into the dll to ensure that all of my bases were covered...I haven't done a lot of work with them in the past and I figured that what you said would be true but just wanted to make sure I hadn't missed it if it was needed. 3. The setup.exe is asking for an Admin password if I am running the install as a "Standard" user...and it is asking for the OK to go ahead and run if I am logged on as an Admin user. 4. I've tried using both AdminUser and Privileged properties and neither of them causes the CA to run as admin! Any other thoughts on how I can get this CA to run as an Administrator? Thanx Chuck A couple or four things:=20 1) Does "early in the installation process" mean in the UI sequence?=20 2) Manifests target executables, not Dlls - they run with the level of the exe that loads them.=20 3) If the setup.exe isn't asking for elevation via Cancel/Allow but is asking for an admin account, then it means you're not an administrator but you need to be. Someone has to provide admin credentials, either you elevated to admin or somebody "over the shoulder" on your behalf.=20 4) AdminUser is unreliable under Vista. =20 =20 http://blogs.msdn.com/rflaming/archive/2006/09/21/uac-in-msi-notes-the-a dminuser-mistake.aspx =20 Phil Wilson=20 Chuck wrote: I have the following situation: I am creating an MSI in which I need to run a CA early in the installation process, the DA is in a C dll. The CA "Requires" Admin access under Vista. I am wrapping the msi in a setup.exe boot strapper that has a manifest with requestedExecutionLevel level="requireAdministrator". In my WIX project I have a condition for AdminUser and in the package I have InstallPrivileges set to elevated. The dll has requireAdministrator in its manifest. The problem that I'm having is that the code that I'm executing in my CA fails to execute correctly. I extracted the code and compiled it into an exe with the same manifest as above. When I run the exe the code completes correctly! In both cases I am getting prompted for an Admin password...which would lead one to think that the installer is running as an Admin user...but the CA fails. Any thoughts on this would be greatly appreciated. Thanx Chuck -- Chuck Hatt Magic Kite Software Ltd Makers of Sourcerer: managing the risks in your software development. Phone: 250.383.8175 Cell: 250.889.0119 email: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Registering an OCX with Wix v3?
I'm trying to register an OCX control. I ran heat.exe and used the output in my wix project but the ocx isn't properly registered??? If can manually register the ocx using a command line with regsvr32.exe and it registers properly. Am I missing something or does heat not work with ocx controls. Thanx Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] CA with elevated privileges under Vista!
I have the following situation: I am creating an MSI in which I need to run a CA early in the installation process, the DA is in a C dll. The CA Requires Admin access under Vista. I am wrapping the msi in a setup.exe boot strapper that has a manifest with requestedExecutionLevel level=requireAdministrator. In my WIX project I have a condition for AdminUser and in the package I have InstallPrivileges set to elevated. The dll has requireAdministrator in its manifest. The problem that I'm having is that the code that I'm executing in my CA fails to execute correctly. I extracted the code and compiled it into an exe with the same manifest as above. When I run the exe the code completes correctly! In both cases I am getting prompted for an Admin password...which would lead one to think that the installer is running as an Admin user...but the CA fails. Any thoughts on this would be greatly appreciated. Thanx Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Call 3rd party dll from C++ Custom Action
Is it possible to call a third party dll, included in my installer as a binary file only, from a custom action that is in a C++ dll? If that isn't possible is that anyway to access a 3rd party dll from my custom action prior to the installation of files? Thanx Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Condition display of dialog
I have an msi with 2 custom dialogs in it. The first one has a single
edit that the user will enter a registration code in. The next button
has a Custom Action called ValidateRegCode that calls to a helper dll to
validate the users entry. If the user has entered a valid registration
code the dll set the property REGISTRATIONCODEVALID to 'true'...if the
code is not valid it sets REGISTRATIONCODEVALID to 'false'. Depending on
the value of REGISTRATIONCODEVALID I want to go to either my other
custom dialog straight to the VeriyReady dialog.
This all seems to work fine except that I have to click on the next
button twice to move the the next dialog???
The code for my dialog looks like this:
Dialog Id=RegistrationCodeDlg Width=370 Height=270
Title=[ProductName] [Setup] NoMinimize=yes
Control Id=RegCodeLabel Type=Text X=45 Y=73 Width=220
Height=15 TabSkip=no Text=Registration Code: /
Control Id=RegCodeEdit Type=Edit X=45 Y=85 Width=220
Height=18 Property=REGISTRATIONCODE Text={80} /
Control Id=Back Type=PushButton X=180 Y=243 Width=56
Height=17 Text=amp;Back
Publish Event=NewDialog
Value=[RegistrationCodeDlg_Back]1/Publish
/Control
Control Id=Next Type=PushButton X=236 Y=243 Width=56
Height=17 Default=yes Text=amp;Next
Publish Event='DoAction' Value='ValidateRegCode'1/Publish
Publish Event=NewDialog
Value=[RegistrationCodeDlg_FALSE]REGISTRATIONCODEVALID=false/Publish
Publish Event=NewDialog
Value=[RegistrationCodeDlg_TRUE]REGISTRATIONCODEVALID=true/Publish
/Control
Control Id=Cancel Type=PushButton X=304 Y=243 Width=56
Height=17 Cancel=yes Text=Cancel
Publish Event=SpawnDialog Value=CancelDlg1/Publish
/Control
Control Id=Description Type=Text NoWrap=no X=25 Y=23
Width=280 Height=30 Transparent=yes NoPrefix=yes
TextPlease enter your registration code. /Text
/Control
Control Id=BottomLine Type=Line X=0 Y=234 Width=370
Height=0 /
Control Id=Title Type=Text X=15 Y=6 Width=200 Height=15
Transparent=yes NoPrefix=yes
Text{\WixUI_Font_Title}Registration Code/Text
/Control
Control Id=BannerLine Type=Line X=0 Y=44 Width=370
Height=0 /
/Dialog
I know that the dll is being called properly as I can see it in the
install log file and I can write out to file in the dll when it gets called.
Any thoughts or ideas would be greatly appreciated.
Thanx
Chuck
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix v2 Appllication launch fails if user changes install path.
Bob, The answers to your questions are: Yes it does run from a command prompt. It does have some dependencies that are installed with it...they are all installing correctly. It is not dependent on a particular working folder. Just to muddy the waters a little, over the weekend I wrote a quick and dirty DLL that has a single method that launches my application. The path to the app is hard coded in the dll to be C:\testing\foo.exe. If I change the installation directory on install to match this value the application will launch!? I'm going to have to make the dll more dynamic so that it can find the installed executable and launch it. I've got to get this installer finished today but if you have any other ideas I'd love to here them. I've never run into this problem before?? Thanx for all you help! Cheers Chuck Bob Arnson wrote: Chuck wrote: INSTALLDIR is correct and all of my application files where installed there. The 1631 error is ERROR_CREATE_FAILED...The Windows Installer service failed to start... Sounds like MSI is try to start again...not start my app?? HMMM. Other functions can return ERROR_CREATE_FAILED too so I suspect that's the problem rather than the MSI meaning. Some things to check: Does the executable run from a command prompt? Does it depend on any DLLs or data files installed with the product? Does it depend on a particular working directory? -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix v2 Appllication launch fails if user changes install path.
Bob, I generated a log file this morning and here is the section for my custom action... Action 9:21:43: LaunchFile. Action start 9:21:43: LaunchFile. Action ended 9:21:43: LaunchFile. Return value 1631. Action ended 9:21:43: ExitDialog. Return value 1. Action ended 9:21:43: INSTALL. Return value 1. Property(C): INSTALLDIR = C:\Test foo\ INSTALLDIR is correct and all of my application files where installed there. The 1631 error is ERROR_CREATE_FAILED...The Windows Installer service failed to start... Sounds like MSI is try to start again...not start my app?? HMMM. Chuck Bob Arnson wrote: Chuck wrote: I have an installer that has a checkbox on the exit dialog that is supposed to launch the application. It works perfectly unless the user changes the installation folder? I added the checkbox and custom action following the method in section 8.6 of the tutorial. Can you show the code you added to your installer? As long as you use the FileKey CustomAction attribute, MSI uses the installed path. You can also generate a log to get extra information: msiexec /l*vx install.log /i mypackage.msi - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix v2 Appllication launch fails if user changes install path.
Hi, I have an installer that has a checkbox on the exit dialog that is supposed to launch the application. It works perfectly unless the user changes the installation folder? I added the checkbox and custom action following the method in section 8.6 of the tutorial. Any idea as to what would cause this to happen would be greatly appreciated. Cheers Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] UI Issue with .Net Framework Detection
Bob, I just grabbed the 2.0.4221... version and rebuilt everything. It now displays my message box if .Net 2.0 isn't installed but it doesn't do that until after all of the UI components have been displayed?! Any thoughts on how to get this to run first? In my InstallExecuteSequence I have the Custom Action set to run After="LaunchConditions". Cheers Chuck Bob Arnson wrote: Chuck wrote: Thanx for getting back to me...do you have any idea which version of Wix the bug was fixed in? I'm not sure of the exact number. It was fixed either last month or early this month. Are you running v2.0.4221.0? -- sig://boB http://bobs.org Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
