Re: [WiX-users] Planning a new WiX release
How do you measure the number of successful installs? PS: Sorry for the mess, I'm cleaning up right now and this next build should be much better. - From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederik Carlier Sent: Monday, September 18, 2006 22:48 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Planning a new WiX release Hi all, With the major update to Votive and Derek's enhancements to the core WiX toolset, there for sure is a lot of new stuff that needs to find its way to SourceForge. However, there seem to be some issues that still need to be resolved (for example, Votive not loading). That's why I am waiting for a future build (maybe next build?) that fixes the most visible bugs. I keep an eye on this list to monitor for people's success rates with the interim WiX builds, so please, if you encounter any issues, file a bug or post a message here! Thanks, Frederik. - 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] Problem with install condition based on lang ID
Frankly, with multi-lingual UI support (especially multiple preference levels in Vista - see GetSystemPreferredUILanguages) you probably shouldn't do this at all. Allow any version to install on any system. Allow multiple versions to be installed side-by-side, or move to a single binary plus language packs. You might be running on a Terminal Server installed froma localized (non-US-English) CD which supports users using a different non-English UI language - I believe this is possible. Michael Kaplan (GIFT team) was pretty critical when MSN Toolbar Beta did this (http://blogs.msdn.com/michkap/archive/2005/02/03/366698.aspx). If you want to ensure that the UI can actually be read - that the fonts required to render it are installed - then you're asking a different question. See http://www.microsoft.com/globaldev/drintl/columns/009/default.mspx#EHFfor more. Actually, it looks like you're missing a space after $(var.LCID), which if WIX is simply doing a macro replacement could cause your condition to be: SystemDefaultUILanguage = 1025OR SystemDefaultUILanguage 1033 which won't make any sense to Windows Installer. Try editing the MSI with Orca to see if this is what's happened. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff MacDuffSent: 19 September 2006 04:42To: wix-users@lists.sourceforge.netSubject: [WiX-users] Problem with install condition based on lang ID I am having trouble getting an install condition based on land ID to work I have consulted the WIX docs and my implementation seems to be correct but since its not working I am missing something. We are building a Multilanguage MSI for a small product and we wish to only allow install on the language of the MSI AND English but not a different language. For example a Korean (KOR) MSI should be able to install on a Korean language OS and an English (ENU) language OS but not a German(DEU) language OS. At the same time, a DEU MSI should install on English and German (DEU) but not on a Korean (KOR ) OS ,etc you get the idea. My condition statement is formatted like this: Condition Message="You cannot install this version of because it is not compatible with your language version of Windows. Obtain the language version that matches the language version of Windows running on this PC."![CDATA[SystemDefaultUILanguage = $(var.LCID)OR SystemDefaultUILanguage 1033]]/Condition Var.LCID is passed in as the build language and 1033 is of course English. What we are seeing is that the MSIs can install everywhere. Thanks for help, Jeff - 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] Install service using unprivileged user
Hello, I am trying to install a service that runs under non-Local System account, but under a user account that my WiX script create. I have spent several hours to determine why the service can't be started under the account that MSI creates. The reason is that it didn't have the Log On As a Service right. Everything goes smoothly after I set this using Local Policies. Is it possible to assign Log On As a Service right to an account using WiX? If no, what are possible solutions? I guess that lots of setup engineers suffered with that problem. Thank you in advance, Albert Tuulas - 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] Register a provider in machine.config and how to customize wixui
Guys I have a need to register an assembly in the GAC and in machine.config but I only want to do this if the user has chosen that option. I would like to add a custom installer dialog to present these options but am not sure how to customize the mondo dialog set in wixui. The examples seem to be missing. Can anyone provide any guidance? Thanks Reggie - 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] FW: issue around INSTALLDIR
Hi, Does this mean that users are not supposed to use the INSTALLDIR variable in their custom actions? But this is a windows installer variable (supposed to set by the windows installer service itself) and it should be safe to use it. What is the reason this is not a recommended step not to use INSTALLDIR in custom action? Take Care Anirban -Original Message- From: Anirban Basu Sent: Tuesday, September 19, 2006 2:08 PM To: '[EMAIL PROTECTED]' Subject: RE: [WiX-users] FW: issue around INSTALLDIR Hi Rob, Thanks for your responses so far. I am trying to find some documentation on the [!FileId] syntax in MSI SDK. Still could not find it. If you have some of the documentation available, can you just forward me? Take Care Anirban -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 11:59 AM To: Anirban Basu Subject: RE: [WiX-users] FW: issue around INSTALLDIR You should read: http://blogs.msdn.com/robmen/archive/2004/05/20/136530.aspx about VBScript CustomActions. You really should find better ways to call your code. Really, this CustomAction is scary from many different angles. I suggest reading the Formatted topic in the MSI SDK to understand the [!FileId] syntax. It is a far better way to refer to files you are installing. -Original Message- From: Anirban Basu [mailto:[EMAIL PROTECTED] Sent: Monday, September 18, 2006 23:09 To: [EMAIL PROTECTED] Subject: RE: [WiX-users] FW: issue around INSTALLDIR Here is the list of custom actions. !-- Custom actions -- CustomAction Id='InstallAdapterMethod' BinaryKey='PreReqScripts.vbs' VBScriptCall='InstallAdapter' Return='check'/CustomAction CustomAction Id='DeleteAdapterMethod' BinaryKey='PreReqScripts.vbs' VBScriptCall='UninstallAdapter' Return='check'/CustomAction CustomAction Id='IsAdapterExistMethod' BinaryKey='PreReqScripts.vbs' VBScriptCall='IsAdapterExists' Return='check'/CustomAction CustomAction Id='IsSendPortExistMethod' BinaryKey='PreReqScripts.vbs' VBScriptCall='IsSendPortExists' Return='check'/CustomAction CustomAction Id='IsSSORunningMethod' BinaryKey='PreReqScripts.vbs' VBScriptCall='IsSSOServiceRunning' Return='check'/CustomAction CustomAction Id=PrintEula BinaryKey=WixCA DllEntry=PrintEula Return=ignore Execute=immediate/ AdminExecuteSequence / InstallExecuteSequence Custom Action=InstallAdapterMethod After=InstallFinalize$copydllsgt;2/Custom Custom Action=DeleteAdapterMethod After=InstallInitialize$copydlls=2/Custom RemoveExistingProducts After=InstallFinalize / /InstallExecuteSequence The script file we are using Pre-reqScripts.vbs is attached here. Please look into the method RegisterDllAndCallMethod. It is called from InstallAdaptrer and UninstallAdapter. But how the [!FileId] can be used? I have a file with id xyz. Then how I can access the dll? What will be the syntax? Take Care Anirban -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 11:31 AM To: Anirban Basu; [EMAIL PROTECTED] Subject: RE: [WiX-users] FW: issue around INSTALLDIR Why are you using INSTALLDIR at all? Can you show the CustomAction element that you're calling? I expect we'll find that you can use [!FileId] instead of [INSTALLDIR]filename.dll and get better results. From: Anirban Basu Sent: Monday, September 18, 2006 6:28 PM To: Rob Mensching; Windows Installer XML Subject: RE: issue around INSTALLDIR Hi, Thanks for your responses. Rob, probably it is not possible to do away with the custom action. I am giving you more details on this. The custom action registers a dll which is copied to the installation directory. The dll is a .NET assembly. Then it calls Install and Uninstall method within the assembly which does specific actions. (like making BizTalk WMI calls etc.). I agree that storing the installation directory specifically into the registry is an option, but is it what all users of WIX are supposed to do? Does WIX not handle the modified installation directory? I agree that if I do not store modified installation directory somewhere it is not possible for WIX to identify the installation directory. But what I want to know is that from where WIX reads this value of INSTALLDIR? Your help is much appreciated. Take Care Anirban From: Rob Mensching Sent: Saturday, September 16, 2006 3:17 PM To: Cullen Waters; Anirban Basu; Windows Installer XML Subject: RE: issue around INSTALLDIR Or better yet, quit calling your CustomAction. Something sounds very fishy in this design. More details about what you are doing in the CustomAction are probably necessary to really provide useful information. From: Cullen Waters Sent: Friday, September 15, 2006 09:58 To: Anirban Basu; Windows Installer XML Subject: RE: issue around INSTALLDIR Other users have reported that you have to save the
Re: [WiX-users] Heat - Unable to locate component
Thanks From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 11:00 AM To: Steven Chin Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Heat - Unable to locate component Steven Chin wrote: I am running Wix 3.0 and heat.exe is returning the error pop-up This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem. I eventually get another popup Java Plug-in 1.5.0_07 in not installed properly as well. Heat tries to load DLLs to find their self-registration code. If the DLLs don't have their dependencies met, Heat can fail. -- sig://boBhttp://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] Heat - Unable to locate component
Steven Chin wrote: I am running Wix 3.0 and heat.exe is returning the error pop-up This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem. I eventually get another popup Java Plug-in 1.5.0_07 in not installed properly as well. Heat tries to load DLLs to find their self-registration code. If the DLLs don't have their dependencies met, Heat can fail. -- 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] FW: issue around INSTALLDIR
Hi Bob, Thanks for the reply. We have already found out what caused this. U said MSI doesn't set INSTALLDIR; it's entirely up to your package what the directory structure looks like. MSI records where it installs components. U r completely right, but as per our experiment installer can resolve the directory paths from the path where is installs components. As there was no direct component that was getting installed under the directory INSTALLDIR (all the components were present through intermediate directories) installer was unable to set the property INSTALLDIR. We confirmed this because just after adding a component beneath INSTALLDIR, installer started calculating INSTALLDIR properly. So the paths of the directories are resolved from the path of components just under it. This was the info I was looking for. Bob, Can you please confirm whether I am right or not? Thanks for all your helps and suggestions so far. Take Care Anirban From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 8:30 PM To: Anirban Basu Cc: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] FW: issue around INSTALLDIR Anirban Basu wrote: Are users not supposed to use the INSTALLDIR variable in their custom actions? But this is a windows installer variable (supposed to set by the windows installer service itself) and it should be safe to use it. MSI doesn't set INSTALLDIR; it's entirely up to your package what the directory structure looks like. MSI records where it installs components but doesn't persists property changes your package makes. If you need that data, you need to persist it (e.g., in the registry) and load it (using RegistrySearch). -- sig://boBhttp://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] Shortcut problem, and a few other notes
Thanks, I tried your suggestion, but unfortunately it did not work out, and I end up with the same error about KeyPath and HKCU registry
C:\Users\Simon\Documents\Visual Studio 2005\Projects\ComicBook\ComicBook\installer\installer.wxs(35): error LGHT0204: ICE43: Component ComicBookExecutable has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath,not a file.
C:\Users\Simon\Documents\Visual Studio 2005\Projects\ComicBook\ComicBook\installer\installer.wxs(35): error LGHT0204: ICE57: Component 'ComicBookExecutable' hasboth per-user and per-machine data with a per-machine KeyPath.
0 Warning(s) 2 Error(s)So, I'm still out in the dark about what to do now...
/Simon
On 9/19/06, Eric Epstein [EMAIL PROTECTED] wrote:
Simon,I am new to using WiX too, but I just got some help from the list, soI think I will try to give back.
I think your first attempt is really close.I think that all you need to add is the following lineDirectory Id=ProgramMenuFolder/after yourDirectory Id= TARGETDIR Name= SourceDir
and before yourDirectory Id= ProgramFilesFolder Name= PFilesProgramMenuFolder is a special (reserved/magic) name(check out
http://msdn.microsoft.com/library/default.asp?url="">)but it seems like you still need to define it in your .wxs file in aDirectory tag so that your reference to it in your shortcut tag
will pick up properly.If adding the Directory Id=ProgramMenuFolder/ doesn't work foryou, then either a) I am a n00b too :-) , b) perhaps it has somethingto do with Vista X64, c) something else.:-(
Good Luck!EricOn 9/18/06, Simon Dahlbacka [EMAIL PROTECTED] wrote: Let's begin with the facts:I'm a relative wix n00b and I'm running Wix
3.0.2015.0 (under Vista RC1 x64 if that matters) Due to the lack of samples I'm having trouble with creating a shortcut in my wxs file. My first attempt:
Directory Id= TARGETDIR Name= SourceDir Directory Id= ProgramFilesFolder Name= PFiles Directory Id= INSTALLDIR Name= ComicBook
Directory Id= ComicBookPluginsFolder Name= plugins /Directory Component Id= ComicBookExecutable Guid= ab49562c-5784-474b-8314-45d6086bc238 DiskId= 1
File Id= ComicBook.exe Name= ComicBook.exe Source= ..\bin\Release\ComicBook.exe Shortcut Id= ShortcutComicBook Name= ComicBook Directory=
ProgramMenuFolder WorkingDirectory=INSTALLDIR / /File /Component /Directory /Directory
/Directory However, that blows up with C:\Users\Simon\Documents\Visual Studio 2005\Projects\ComicBook\ComicBook\installer\installer.wxs(37):
error LGHT0094: Unresolved reference to symbol 'Directory:ProgramMenuFolder' in section 'Product:{D025DC70-6ADD-4AAE-8F58-A3455DD27DEE}'. C:\Users\Simon\Documents\Visual Studio 2005\Projects\ComicBook\ComicBook\installer\installer.wxs(51):
error LGHT0094: Unresolved reference to symbol 'Component:ComicBookShortcutComponent' in section 'Product:{D025DC70-6ADD-4AAE-8F58-A3455DD27DEE}'. Then I found a sample doing something along the lines of
Directory Id= ProgramMenuFolder Name= ProgMenu Directory Id= ComicBookShortcutFolder Name= !(wix.ProductName) Component Id= ComicBookShortcutComponent Guid=
74519baa-2501-4a50-be7f-e3c813d949f4 KeyPath=yes CreateFolder / Shortcut Id= ComicBookShortcut Directory= ComicBookShortcutFolder
Target=[!ComicBook.exe] Name=!(wix.ProductName) / /Component /Directory /Directory Again, this blows up as follows:
C:\Users\Simon\Documents\Visual Studio 2005\Projects\ComicBook\ComicBook\installer\installer.wxs(22): error LGHT0204: ICE38: Component ComicBookShortcutComponent installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.
C:\Users\Simon\Documents\Visual Studio 2005\Projects\ComicBook\ComicBook\installer\installer.wxs(22): error LGHT0204: ICE43: Component ComicBookShortcutComponent has non-advertised shortcuts. It should use a registry key under HKCU as its
KeyPath, not a file. C:\Users\Simon\Documents\Visual Studio 2005\Projects\ComicBook\ComicBook\installer\installer.wxs(21): error LGHT0204: ICE64: The directory ComicBookShortcutFolder is in the user
profile but is not listed in the RemoveFile table. So it seems that I am missing something, but I don't know where to look. A related note, the CHM file bundled with the binaries does not work on
Vista, clicking it first gets me a security warning and if I OK that I get the chm file open with the contents and index tabs working but the content area shows a constant The address is not valid
Pointers/hints appreciated! regards, Simon PS. sorry if the formatting is bad.. -
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
Re: [WiX-users] FW: issue around INSTALLDIR
For your problem you could simply use a ComponentSearch tofind the component that contains the assembly. Still, I don't like the idea of registering the component using regasm, it still seems far too fragile. -- Mike Dimmick From: Anirban Basu [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 15:27To: Mike Dimmick; [EMAIL PROTECTED]Subject: RE: [WiX-users] FW: issue around INSTALLDIR Hi Mike, Thanks for the reply. I agree that the approach may not be a good one, but we are not in a position to change it. Moreover my question is not around what is the best practice (I know what is described here is not the best practice), but my question is as follows Are users not supposed to use the "INSTALLDIR" variable in their custom actions? But this is a windows installer variable (supposed to set by the windows installer service itself) and it should be safe to use it. My observation is that the msi is removing all the dll and registry entries it has installed so I assume that the non-default installation directory is available to windows installer service somewhere but it is not passing it in the INSTALLDIR. Have any one of you faced similar kind of problem? Why is it happening? Take Care Anirban From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 7:18 PMTo: Anirban Basu; [EMAIL PROTECTED]Subject: RE: [WiX-users] FW: issue around INSTALLDIR Why do you have to register this assembly? Is BizTalk calling back into this assembly via COM Interop? Is it simply that you're trying to call the Custom Action implemented in the .NET DLL from _vbscript_? Frankly, that's messy. Do it properly: write your custom actionas a'flat' C++ DLL, then you won't be polluting the user's system with an otherwise-useless COM object. If you must do it, use the correct Windows Installer mechanisms for registering COM objects: the Class and Typelib tables. See Rob's blog entry at http://blogs.msdn.com/robmen/archive/2004/04/28/122491.aspx. -- Mike Dimmick Anirban From: Anirban Basu Sent: Monday, September 18, 2006 6:28 PMTo: Rob Mensching; Cullen Waters; Windows Installer XMLSubject: RE: issue around INSTALLDIR Hi, Thanks for your responses. Rob, probably it is not possible to do away with the custom action. I am giving you more details on this. The custom action registers a dll which is copied to the installation directory. The dll is a .NET assembly. Then it calls Install and Uninstall method within the assembly which does specific actions. (like making BizTalk WMI calls etc.). I agree that storing the installation directory specifically into the registry is an option, but is it what all users of WIX are supposed to do? Does WIX not handle the modified installation directory? I agree that if I do not store modified installation directory somewhere it is not possible for WIX to identify the installation directory. But what I want to know is that from where WIX reads this value of INSTALLDIR? Your help is much appreciated. Take Care Anirban From: Rob Mensching Sent: Saturday, September 16, 2006 3:17 PMTo: Cullen Waters; Anirban Basu; Windows Installer XMLSubject: RE: issue around INSTALLDIR Or better yet, quit calling your CustomAction. Something sounds very fishy in this design. More details about what you are doing in the CustomAction are probably necessary to really provide useful information. From: Cullen Waters Sent: Friday, September 15, 2006 09:58To: Anirban Basu; Windows Installer XMLSubject: RE: issue around INSTALLDIR Other users have reported that you have to save the modified installation directory value during install somewhere(like the registry). Then, on untinstall/reinstall/modify, do a regsearch to get the value of the key you created, and change INSTALLDIR to that value. Make sense? From: Anirban Basu Sent: Friday, September 15, 2006 7:50 AMTo: Windows Installer XMLSubject: issue around INSTALLDIRImportance: High Hi, I am running into a very severe issue. I may be having some problem in my setup.wxs file but really not being able to debug it. The issue is as follows. We have a very simple setup, which during setup registers an assembly (for custom action) and calls its methods. If the installation directory of the product is changed to something else from the default installation directory, the installation gets through properly. Actually in this case INSTALLDIR is changed properly to the value of the installation directory that user has selected. During un-installation the variable INSTALLDIR takes the default value and never changes to what user has selected during installation. So during un-installation the registration of the custom action assembly fails. Hence the un-installation fails. I can not find what from where windows installer is setting INSTALLDIR to default installation directory. Is using the INSTALLDIR property reliable? Do
Re: [WiX-users] Shortcut problem, and a few other notes
See the validation references:
ICE 43 (http://msdn.microsoft.com/library/default.asp?url="">):
"The
attributes column of Component1 is 0, meaning that the component uses a file as
its KeyPath. This causes non-advertised shortcuts in this component to be
installed for the first user on the computer ONLY. Users who install the
component later do not see the shortcuts because the component appear to the
installer as already existing on the computer.
To fix this error, set the RegistryKeyPath bit of the
attributes to switch the Component to a Registry entry, then change the KeyPath
value to a valid entry in the Registry table."
ICE 57, see http://msdn.microsoft.com/library/default.asp?url="">.
Still, that's not
very helpful. It's odd that the shortcuts seem to be non-advertised by
default: most other tools create advertised shortcuts, which invoke repair
(potentially) when invoked. You could set @Advertise to 'yes', which would make
these shortcuts advertised.
-- Mike
Dimmick
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon
DahlbackaSent: 19 September 2006 17:17To: Eric
EpsteinCc: wix-users@lists.sourceforge.netSubject: Re:
[WiX-users] Shortcut problem, and a few other notes
Thanks, I tried your suggestion, but unfortunately it did not work out, and
I end up with the same error about KeyPath and HKCU registry
C:\Users\Simon\Documents\Visual Studio
2005\Projects\ComicBook\ComicBook\installer\installer.wxs(35): error LGHT0204:
ICE43: Component ComicBookExecutable has non-advertised shortcuts. It should use
a registry key under HKCU as its KeyPath,not a file.
C:\Users\Simon\Documents\Visual Studio
2005\Projects\ComicBook\ComicBook\installer\installer.wxs(35): error LGHT0204:
ICE57: Component 'ComicBookExecutable' hasboth per-user and per-machine
data with a per-machine KeyPath. 0
Warning(s) 2 Error(s)So, I'm still out in the dark
about what to do now...
/Simon
On 9/19/06, Eric
Epstein [EMAIL PROTECTED] wrote:
Simon,I
am new to using WiX too, but I just got some help from the list, soI think
I will try to give back. I think your first attempt is really close.I
think that all you need to add is the following lineDirectory
Id="ProgramMenuFolder"/after yourDirectory Id=" TARGETDIR"
Name=" SourceDir" and before yourDirectory Id="
ProgramFilesFolder" Name=" PFiles""ProgramMenuFolder" is a
special (reserved/magic) name(check outhttp://msdn.microsoft.com/library/default.asp?url="">)but
it seems like you still need to define it in your .wxs file in
aDirectory tag so that your reference to it in your
shortcut tag will pick up properly.If adding the
Directory Id="ProgramMenuFolder"/ doesn't work foryou, then either
a) I am a n00b too :-) , b) perhaps it has somethingto do with Vista X64,
c) something else.:-( Good Luck!EricOn
9/18/06, Simon Dahlbacka [EMAIL PROTECTED]
wrote: Let's begin with the
facts:I'm a relative wix n00b and I'm running Wix
3.0.2015.0 (under Vista RC1 x64 if that matters) Due
to the lack of samples I'm having trouble with creating a shortcut in
my wxs file. My first attempt:
Directory Id=" TARGETDIR" Name=" SourceDir"
Directory Id=" ProgramFilesFolder" Name=" PFiles"
Directory Id=" INSTALLDIR" Name=" ComicBook"
Directory Id=" ComicBookPluginsFolder" Name=" plugins"
/Directory Component Id=" ComicBookExecutable"
Guid=" ab49562c-5784-474b-8314-45d6086bc238" DiskId=" 1"
File Id=" ComicBook.exe" Name=" ComicBook.exe"
Source=" ..\bin\Release\ComicBook.exe"
Shortcut Id=" ShortcutComicBook" Name=" ComicBook" Directory="
ProgramMenuFolder" WorkingDirectory="INSTALLDIR "
/ /File
/Component /Directory
/Directory
/Directory However, that blows up
with C:\Users\Simon\Documents\Visual
Studio 2005\Projects\ComicBook\ComicBook\installer\installer.wxs(37):
error LGHT0094: Unresolved reference to symbol
'Directory:ProgramMenuFolder' in section
'Product:{D025DC70-6ADD-4AAE-8F58-A3455DD27DEE}'.
C:\Users\Simon\Documents\Visual Studio
2005\Projects\ComicBook\ComicBook\installer\installer.wxs(51): error
LGHT0094: Unresolved reference to symbol
'Component:ComicBookShortcutComponent' in section
'Product:{D025DC70-6ADD-4AAE-8F58-A3455DD27DEE}'.
Then I found a sample doing something along the lines of
Directory Id=" ProgramMenuFolder" Name=" ProgMenu"
Directory Id=" ComicBookShortcutFolder" Name="
!(wix.ProductName)" Component Id="
ComicBookShortcutComponent" Guid="
74519baa-2501-4a50-be7f-e3c813d949f4" KeyPath="yes"
CreateFolder / Shortcut Id="
ComicBookShortcut" Directory=" ComicBookShortcutFolder"
Target="[!ComicBook.exe]" Name="!(wix.ProductName)" /
/Component /Directory
/Directory Again, this blows up as follows:
C:\Users\Simon\Documents\Visual
Studio
2005\Projects\ComicBook\ComicBook\installer\installer.wxs(22): error
LGHT0204: ICE38: Component ComicBookShortcutComponent installs
[WiX-users] Two products from one MSI
Hello. Is it possible to install two separate products from one MSI? -- Best regards, Peter G. Sakhno C-MAP RUSSIA Ltd http://www.c-map.ru/ - 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] ODBCDataSource Errors?
All,I have searched high and low for information regarding the ODBCDataSource element. The only thing I can find is a posting on this list. From that post, I created the following Code in a component: ODBCDataSource Id=SMSHistoryDSN DriverName=SQL Server Name=SMS-3000 History SQL Registration=machine Property Id=DatabaseFile Value=[MergeRedirecFolder]SMS_History_data.mdf / /ODBCDataSourceI get an error on install that tells me that the file SMS-3000 History SQL could not be found. I want that to be the DSN name after creation, and I want to point to a SQL Server DB on the current machine. I assume that I should be using some property other than DatabaseFile (since it is SQL Server and not an access MDB), but I don't know what. I am also confused about the DBFile name error that I'm getting. here is the entry in the log file I get: MSI (s) (7C:7C) [11:58:52:147]: Executing op: ActionStart(Name=InstallODBC,Description=Installing ODBC components,)Action 11:58:52: InstallODBC. Installing ODBC componentsMSI (s) (7C:7C) [11:58:52:157]: Executing op: ODBCDataSource(DriverKey=SQL Server,,Registration=4,Attribute_=DSN,Value_=SMS-3000 History SQL) 1: SQL Server 2: 3: 4 4: DSN 5: SMS-3000 History SQL 6: DatabaseFile 7: SMS_History_data.mdf MSI (s) (7C:7C) [11:58:52:347]: LocalSQLConfigDataSource returned 0 in remote context.MSI (s) (7C:7C) [11:58:52:398]: LocalSQLConfigDataSource returned 0 in remote context. MSI (s) (7C:7C) [11:58:52:398]: LocalSQLInstallerError returned 0 in remote context.MSI (s) (7C:7C) [11:58:52:398]: Note: 1: 2205 2: 3: Error MSI (s) (7C:7C) [11:58:52:398]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1919 Error 1919. Error configuring ODBC data source: SMS-3000 History SQL, ODBC error 8: Invalid keyword-value pairs. Verify that the file SMS-3000 History SQL exists and that you can access it.MSI (s) (7C:7C) [12:00:04:551]: Note: 1: 2205 2: 3: Error MSI (s) (7C:7C) [12:00:04:551]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (7C:7C) [12:00:04:611]: Product: Fiji Prototype -- Error 1919. Error configuring ODBC data source: SMS-3000 History SQL, ODBC error 8: Invalid keyword-value pairs. Verify that the file SMS-3000 History SQL exists and that you can access it. Any help would be appreciated. Can I get this information from the WiX source code or something. I'm willing to dig, I just don't know where to start with the shovel...Thanks,Joseph - 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] Petition to upgrade source repository to subversion
Hi,I've been using WiX for a while now and I'd like to contribute more. However, since most community projects are moving to Subversion, it would be nice if WiX was using subversion as well. Subversion is a much better source repository. Source Forge has a nice easy script to update the repository to subversion. So, I'd like to start a petition to update to subversion. What does everyone else think? -- ~ Paul - 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] Planning a new WiX release
If Votive is a stumbling block, I hope you'll consider that some users are interested in a new, stable WiX release without particularly caring about Votive. At least this one is. :-) CHarlie From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederik CarlierSent: Monday, September 18, 2006 10:48 PMTo: wix-users@lists.sourceforge.netSubject: [WiX-users] Planning a new WiX release Hi all, With the major update to Votive and Derek's enhancements to the core WiX toolset, there for sure is a lot of new stuff that needs to find its way to SourceForge. However, there seem to be some issues that still need to be resolved (for example, Votive not loading). That's why I am waiting for a future build (maybe next build?) that fixes the most visible bugs. I keep an eye on this list to monitor for people's success rates with the interim WiX builds, so please, if you encounter any issues, file a bug or post a message here! Thanks, Frederik. - 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] FW: issue around INSTALLDIR
Anirban Basu wrote: Are users not supposed to use the "INSTALLDIR" variable in their custom actions? But this is a windows installer variable (supposed to set by the windows installer service itself) and it should be safe to use it. MSI doesn't set INSTALLDIR; it's entirely up to your package what the directory structure looks like. MSI records where it installs components but doesn't persists property changes your package makes. If you need that data, you need to persist it (e.g., in the registry) and load it (using RegistrySearch). -- 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] Planning a new WiX release
Hi Justin, Thanks for the info. I find feature stability in the toolset to be important for distributed projects. We just dropped the VS setup from NUnit and began using WiX for the msi installs. I guess I should try out WiX 3 for our development branch before settling on one or the other. Charlie From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 12:23 PMTo: 'Charlie Poole'; 'Frederik Carlier'; wix-users@lists.sourceforge.netSubject: RE: [WiX-users] Planning a new WiX release Thanks for your input. Votive is one of two things that are a stumbling block from last drop. Please be aware, however, that Votive went through a major overhaul, and thus there are some growing pains for the first drop. Also note that Wix v3, although very stable, is still a beta version and goes through more code churn and is not at the same level of stability as Wix v2. Also, you are free to use Wix v3 without installing Votive. Thats been separate for a while now. So, basically, you shouldnt have to care about Votive if you dont want to. It shouldnt block you from using v3, if thats what youre concerned about. Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie PooleSent: Tuesday, September 19, 2006 11:56 AMTo: 'Frederik Carlier'; wix-users@lists.sourceforge.netSubject: Re: [WiX-users] Planning a new WiX release If Votive is a stumbling block, I hope you'll consider that some users are interested in a new, stable WiX release without particularly caring about Votive. At least this one is. :-) CHarlie From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederik CarlierSent: Monday, September 18, 2006 10:48 PMTo: wix-users@lists.sourceforge.netSubject: [WiX-users] Planning a new WiX release Hi all, With the major update to Votive and Derek's enhancements to the core WiX toolset, there for sure is a lot of new stuff that needs to find its way to SourceForge. However, there seem to be some issues that still need to be resolved (for example, Votive not loading). That's why I am waiting for a future build (maybe next build?) that fixes the most visible bugs. I keep an eye on this list to monitor for people's success rates with the interim WiX builds, so please, if you encounter any issues, file a bug or post a message here! Thanks, Frederik. - 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] Setting sidtype on a service
Title: Setting sidtype on a service Im installing a service and after installing it I need to set the sidtype (sc sidtype srvName UNRESTRICTED if done from the cmdline). Ive looked thru the v2.x schema on ServiceInstall and I dont see where I can set it. Does WIX support setting this value? The definition of SidType: Changes the service security identifier (SID) type setting of a service. If this setting is unrestricted, the Service Control Manager (SCM) will add this service's SID to the service process token when the service process starts the next time due to the first service in the process being started. This setting is valid only for Win32 user mode services. If this setting is restricted, the Service Control Manager (SCM) will add this service's SID to the service process token when the service process starts the next time due to the first service in the process being started. In addition, this service's SID will also be added to the restricting SID list in the process token. The process token will be a restricted token. See MSDN for details on restricted token. This setting is valid only for Win32 user mode services. In addition, for a share process service, all services cohosted in the process must have this SID type set for this to take effect. If this setting is none, the SCM will not add the service's SID to the service process token. Thanks Danny Smith - 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] Planning a new WiX release
Title: RE: [WiX-users] Planning a new WiX release Heh, so it's more of a negative test: nothing bad seems to have happened so that's good. smile/ That's fine, I was just more curious than anything. You never told me (or I just forgot) how you determined which releases were good to go to the Release Page. From: Frederik Carlier [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 09:32 To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Planning a new WiX release Well, I didn't say succesful installs but success rate, but indeed the metric is more like the failure rate. I don't have any metric available to find out how many downloads there are form the wix.sourceforge.net/releases website, neither can I know how many people actually installed the thing. On the other hand, the number of questions asked (albeit very low) about people running the latest version is already a good indication of the number of installs. Most people are vocal when things don't work out, so that still remains the key metric. That's more or less the kind of things that I skim for. - 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] Setting sidtype on a service
Title: Setting sidtype on a service Right now I think the only way will be to use a DLL custom action to call ChangeServiceConfig2 with the SERVICE_CONFIG_SERVICE_SID_INFO parameter and a SERVICE_SID_INFO structure with the dwServiceSidType member set to SERVICE_SID_TYPE_UNRESTRICTED. This isn't so much a limitation of WiX as one of Windows Installer - if this feature has been added to Windows Installer 4.0, it's not in the SDK yet. I'm assuming a base version of 4.0 because this whole area is a new feature in Vista and "Longhorn" Server. Even if there were support in MSI 4.0, or in a WiX-supplied custom action, I wouldn't expect to see it in v2 since the aim is to keep v2 stable, generallynot adding new features. -- Mike Dimmick From: [EMAIL PROTECTED] on behalf of Danny SmithSent: Tue 19/09/2006 22:26To: wix-users@lists.sourceforge.netSubject: [WiX-users] Setting sidtype on a service Im installing a service and after installing it I need to set the sidtype (sc sidtype srvName UNRESTRICTED if done from the cmdline). Ive looked thru the v2.x schema on ServiceInstall and I dont see where I can set it. Does WIX support setting this value? The definition of SidType: Changes the service security identifier (SID) type setting of a service. If this setting is "unrestricted", the Service Control Manager (SCM) will add this service's SID to the service process token when the service process starts the next time due to the first service in the process being started. This setting is valid only for Win32 user mode services. If this setting is "restricted", the Service Control Manager (SCM) will add this service's SID to the service process token when the service process starts the next time due to the first service in the process being started. In addition, this service's SID will also be added to the restricting SID list in the process token. The process token will be a restricted token. See MSDN for details on restricted token. This setting is valid only for Win32 user mode services. In addition, for a share process service, all services cohosted in the process must have this SID type set for this to take effect. If this setting is "none", the SCM will not add the service's SID to the service process token. Thanks Danny Smith - 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] Using BrowseDlg Twice
Error 2812's textis given in http://msdn.microsoft.com/library/default.asp?url="">as 'The event [2] is not recognized.' Looking up the SelectionBrowse ControlEvent (http://msdn.microsoft.com/library/default.asp?url="">) suggests that you should have a SelectionTree control on the same dialog: it is the SelectionTree which actually creates the dialog. I'm guessing that since you don't have one there is no subscriber to the event so when you try to fire it, the error occurs. I'm trying to get my head around this model of publishing and subscribing to events. Perhaps you need to have a hidden SelectionTree? I'm not sure how to - or whether to - remove the actual feature selections from it. I assume that you're installing data files to this directory, rather than specifying where files will be created by the application once installed. If the latter I'd suggest making it part of your application's UI, orcommand-line configuration interface,rather than the installer's UI, so that the user can change it after installation without having to rerun the installer. Your fragment suggests that they can't change it without reinstalling anyway - I note you hide the Browse button if the product is already Installed. It may be beneficial to load your generated MSI into Orca (from the Windows Installer SDK)and use Tools/Validate. This will run the Internal Consistency Evaluators (ICEs). light.exe in WiX v3 runs the ICEs for you and will refuse to link if any ICEs produce errors. I don't think there is one that will pick up this problem but it's worth seeing what other problems show up. -- Mike Dimmick From: [EMAIL PROTECTED] on behalf of Douglas WattsSent: Tue 19/09/2006 23:54To: wix-users@lists.sourceforge.netSubject: [WiX-users] Using BrowseDlg Twice WIX Version: 2.0.4415.0 Problem Summary: How to use the BrowseDlg twice. I use the BrowseDlg from the WiXUI library to allow the user to specify the installation directory. I also need to allow the user to specify a data directory. I have created a dialog to allow the user to select the data directory. I set the PathEdits property to CommonAppDataFolder. I have a Directory element with that ID. My thought is that I would include a browse button that would display the BrowseDlg dialog and I would get the directory that the user selected. No can do! Upon clicking the Browse button I immediately get a 2812 error. I figure this has to do with the _BrowseProperty but I dont understand how this works. How do I get this to work? Dialog Id="DataPathDlg" Width="370" Height="270" Title="[ProductName] [Setup]" NoMinimize="yes" Control Id="DataPathLabel" Type="Text" X="45" Y="73" Width="100" Height="15" TabSkip="no" Text="Data Path:" / Control Id="PathEdit" Type="PathEdit" X="90" Y="71" Width="240" Height="18" Property="CommonAppDataFolder" / Control Id="Back" Type="PushButton" X="180" Y="243" Width="56" Height="17" Text="[ButtonText_Back]" Publish Event="NewDialog" Value="CustomizeDlg"1/Publish /Control Control Id="Next" Type="PushButton" X="236" Y="243" Width="56" Height="17" Default="yes" Text="[ButtonText_Next]" Publish Event="SpawnWaitDialog" Value="WaitForCostingDlg"CostingComplete = 1/Publish Publish Event="NewDialog" Value="VerifyReadyDlg"ProductID/Publish /Control Control Id="Cancel" Type="PushButton" X="304" Y="243" Width="56" Height="17" Cancel="yes" Text="[ButtonText_Cancel]" Publish Event="SpawnDialog" Value="CancelDlg"1/Publish /Control Control Id="BannerBitmap" Type="Bitmap" X="0" Y="0" Width="370" Height="44" TabSkip="no" Text="[BannerBitmap]" / Control Id="Description" Type="Text" X="25" Y="23" Width="280" Height="15" Transparent="yes" NoPrefix="yes" TextSelect the path where data should be stored/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[DlgTitleFont]Data Path/Text /Control Control Id="BannerLine" Type="Line" X="0" Y="44" Width="370" Height="0" / Control Id="DataBrowse" Type="PushButton" X="275" Y="100" Width="56" Height="17" Text="[ButtonText_Browse]" Publish Event="SelectionBrowse" Value="BrowseDlg"1/Publish Condition Action=""Installed/Condition /Control /Dialog - 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] prerequisite download from WiX!!!
Hi All,My requirement: Setup msipackage need to performsome pre-installation checks for certain software installations existing on the machineand if a particular software is not found,it shoulddownloadand install the missing software and then continue with my package installation.Is itpossible to do this using WiX? Please advice me a better way of doing this.Any resources/pointers will be highly appreciated! thanks Vij Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.- 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
