[WiX-users] Getting rid of the warnings when using the VC8 CRT merge modules
Hello, From reading blogs on the web, the way to add the merge modules for the VC8 CRT libraries is shown in the WXS code below. But I get a lot of warnings in the process. We are using Visual Studio 2005 SP1 and Wix v3.0.2925 What is the reason for all the warnings? What can be done to fix the warnings? Or is there a bug/problem with the CRT merge modules? Cheers Francois ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=d1a9a77e-0717-404e-9d84-eb19ba6032a0 Name=MyWixTestApp Language=1033 Version=1.0.0.0 Manufacturer=me UpgradeCode=53518b27-3cb6-4224-8614-9a74207ccbf9 Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=WixProject1.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=MyCompanyFolder Name=MyCompany Directory Id=INSTALLDIR Name=MyProduct-1.x Component Id=ProductComponent Guid=b9396cba-4878-4413-b81b-4ec1ace56eeb !-- TODO: Insert your files, registry keys, and other resources here. -- File Id=ProductExeFile Source=$(var.ConsoleApplication1.TargetPath) / /Component /Directory /Directory /Directory Merge Id=CRT SourceFile=C:\Program Files\Common Files\Merge Modules\Microsoft_VC80_DebugCRT_x86.msm Language=1033 DiskId=1 / Merge Id=CRT Policy SourceFile=C:\Program Files\Common Files\Merge Modules\policy_8_0_Microsoft_VC80_DebugCRT_x86.msm Language=1033 DiskId=1 / /Directory Feature Id=ProductFeature Title=MyTestApp Level=1 ComponentRef Id=ProductComponent / MergeRef Id='CRT' / MergeRef Id='CRT Policy' / /Feature /Product /Wix -- Build started: Project: ConsoleApplication1, Configuration: Debug Any CPU -- ConsoleApplication1 - C:\workspace\WixProject1\ConsoleApplication1\bin\Debug\ConsoleApplication1.ex e -- Build started: Project: WixProject1, Configuration: Debug Any CPU -- C:\Program Files\Windows Installer XML v3\bin\candle.exe -dDebug -dDevEnvDir=C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\\ -dSolutionDir=C:\workspace\WixProject1\ -dSolutionExt=.sln -dSolutionFileName=WixProject1.sln -dSolutionName=WixProject1 -dSolutionPath=C:\workspace\WixProject1\WixProject1.sln -dConsoleApplication1.Configuration= -dConsoleApplication1.FullConfiguration= -dConsoleApplication1.Platform= -dConsoleApplication1.ProjectDir=C:\workspace\WixProject1\ConsoleApplication1 \ -dConsoleApplication1.ProjectExt=.csproj -dConsoleApplication1.ProjectFileName=ConsoleApplication1.csproj -dConsoleApplication1.ProjectName=ConsoleApplication1 -dConsoleApplication1.ProjectPath=C:\workspace\WixProject1\ConsoleApplication 1\ConsoleApplication1.csproj -dConsoleApplication1.TargetDir=C:\workspace\WixProject1\ConsoleApplication1\ bin\Debug\ -dConsoleApplication1.TargetExt=.exe -dConsoleApplication1.TargetFileName=ConsoleApplication1.exe -dConsoleApplication1.TargetName=ConsoleApplication1 -dConsoleApplication1.TargetPath=C:\workspace\WixProject1\ConsoleApplication1 \bin\Debug\ConsoleApplication1.exe -out obj\Debug\WixProject1.wixobj WixProject1.wxs C:\Program Files\Windows Installer XML v3\bin\Light.exe -out C:\workspace\WixProject1\WixProject1\bin\Debug\WixProject1.msi obj\Debug\WixProject1.wixobj C:\workspace\WixProject1\WixProject1\WixProject1.wxs(19,0): Warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsInstallCA' which cannot be merged from the merge module 'C:\Program Files\Common Files\Merge Modules\policy_8_0_Microsoft_VC80_DebugCRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. C:\workspace\WixProject1\WixProject1\WixProject1.wxs(19,0): Warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsUninstallCA' which cannot be merged from the merge module 'C:\Program Files\Common Files\Merge Modules\policy_8_0_Microsoft_VC80_DebugCRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s):
[WiX-users] File Paths and Fragments
I'm using some file keys in custom actions, for example [#MyFile]. This was working fine until I broke the core wxs file up into multiple files containing fragments for easier maintenance. Since I've done this the file references don't seem to be evaluating to anything. I get empty strings in the logs when I try to do the install. Is it not possible to use formatted strings to get the path of file objects when the files are in a fragment? Brian Poploskie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File Paths and Fragments
I'm using 2.0. It's hard enough convincing people around here to use new tech, let alone pre-release tech. They are deferred but all scheduled before InstallFinalize. They're all on the same schedule as they were before I moved everything to fragments and they worked fine before. Brian Poploskie From: John Hall [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 10:01 AM To: Brian Poploskie Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] File Paths and Fragments I'm using some file keys in custom actions, for example [#MyFile]. This was working fine until I broke the core wxs file up into multiple files containing fragments for easier maintenance. Since I've done this the file references don't seem to be evaluating to anything. I get empty strings in the logs when I try to do the install. Is it not possible to use formatted strings to get the path of file objects when the files are in a fragment? Brian, What version of WiX are you using? I am using version 3, and file keys work for me with components in separate fragments. Is it possible you're using deferred custom actions, in which those properties are no longer available? See http://msdn2.microsoft.com/EN-US/library/aa370543.aspxfor more information on what is available during a deferred CA.l Cheers, John - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting rid of the warnings when using the VC8 CRTmerge modules
From reading blogs on the web, the way to add the merge modules for the VC8 CRT libraries is shown in the WXS code below. But I get a lot of warnings in the process. We are using Visual Studio 2005 SP1 and Wix v3.0.2925 What is the reason for all the warnings? What can be done to fix the warnings? Or is there a bug/problem with the CRT merge modules? Francois, As far as I know, there is no way around the warnings. I've taken an approach mentioned by someone else on this list, to disable most ICE warnings normally, but create a separate project configuration with the warnings enabled that defines a preprocessor variable 'Verify' and has all the merge modules removed, i.e. ?ifndef Verify? MergeRef Id=Microsoft_VC80_CRT_x86.msm / MergeRef Id=policy_8_0_Microsoft_VC80_CRT_x86.msm / ?endif ? Cheers, John - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall removes everything in the folder.
Yes, there are other files, files that have nothing to do with the installer(I've tried installing to a folder with other things already present or adding files post install, but both way end up with the same result) that are getting deleted when I run an uninstall. Any file that is within the folder I designate as my install directory or within any of the underlying folders is gone upon uninstall. The other problem isn't a big deal, I can work around that, I just included it in case it was symptomatic of the other problem. Thanks for your help. -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Monday, July 30, 2007 9:22 PM To: Alex Steen Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Uninstall removes everything in the folder. JCWrs wrote: I've continued to track this problem and I'm still no where. I have combed the verbose log, but there is no reference to any removal of the folder I install to. MSI doesn't log when it removes empty folders (as far as I can tell) but it does log each file deletion. So are there extra files not getting logged as deleted? I'm also seeing that, if I edit a file after installation it is still removed with everything else (perhaps it is deleted with the folder, it might be impossible to know)...how would I go about not uninstalling anything that has been edited? AFAIK, it's not possible short of creating unmanaged components. User data should be created at first run. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Yeah, I agree that heat will produce a lot of RegistryValue
elements that are not related to the DLL being looked at (like you said,
usually VB Runtime related). Which is fine since heat shouldn't be used
for automated builds etc, and the output should be hand-tooled/cleaned
up. But I would expect it to create the TypeLibs for the DLL.
I am using heat in an automated fashion... I have written a MSBuild task
that invokes heat and then opens the XML file and tidies up the XML
structure. However, your comments are making me go back and check the
output more carefully.
What also struck me as odd was that heat is generating Class and
Interface elements as Component elements as well as File elements, e.g.:
Component
Class
ProgID /
/Class
Class
ProgID /
/Class
File
Class
ProgID /
/Class
/File
Interface /
Interface /
Interface /
...
RegistryValue /
RegistryValue /
RegistryValue /
...
/Component
And these Class elements were directly related to the DLL being
looked at. In the above instance, there was no TypeLib element at all...
Heat will generate TypeLibs for some of the other DLLs.
Any suggestions?
No suggestions really. I've looked at the output for some of my DLLs and
OCXs and there are some entries outside the File element that are
related, and they are all of this kind of form:
RegistryValue Root=HKCR
Key=CLSID\{5406F822-32BA-4AC7-B355-AD5E8DC28DEC}\Control Value=
Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{5406F822-32BA-4AC7-B355-AD5E8DC28DEC}\MiscStatus\1
Value=131473 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{5406F822-32BA-4AC7-B355-AD5E8DC28DEC}\MiscStatus Value=0
Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{5406F822-32BA-4AC7-B355-AD5E8DC28DEC}\ToolboxBitmap32
Value=[!controls.ocx], 3 Type=string Action=write /
or Interface entries like this that seem to just forward to interfaces
defined inside the File element:
Interface Id={296923CA-99E8-40B8-87E3-0BEF5FF0D67C}
Name=dbUtils ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
RegistryValue Root=HKCR
Key=Interface\{296923CA-99E8-40B8-87E3-0BEF5FF0D67C}\Forward
Value={107C147F-8A37-4E29-813D-5958F10B97CF} Type=string
Action=write /
I don't see any extra Class elements. I need to go away and test the
installation thoroughly to see if I'm throwing away too much.
Cheers,
John
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to update PATH environment variable in WiX?
I think you're just missing [EMAIL PROTECTED]set. Rob Werner, Harvey D wrote: I need to update the PATH environment variable to prepend the value of [TARGETDIR]\bin during our product installation. How is this done in WiX? I tried using the Environment element, but it does not change PATH at all. Environment Id=Environment Name=PATH Part=first System=yes Value=[TARGETDIR]\bin / Obviously, I do not want to delete PATH during uninstall, but just remove what was added. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to update PATH environment variable in WiX?
Werner, Harvey D wrote: I need to update the PATH environment variable to prepend the value of [TARGETDIR]\bin during our product installation. You need Action='set' below, and I believe you have to do a CA to get/manipulate the value to set. Am I the only one who absolutely hates it when a program plays with my path? Drives me nuts. It's MY path. How is this done in WiX? I tried using the Environment element, but it does not change PATH at all. Environment Id=Environment Name=PATH Part=first System=yes Value=[TARGETDIR]\bin / Obviously, I do not want to delete PATH during uninstall, but just remove what was added. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Building a setup.exe
I had seen one product that used DemoShield and I knew that DemoShield was no longer available. But I hadn't found that Installsite link you gave. Thanks Friedrich! Jim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Friedrich Brunzema Sent: Saturday, July 28, 2007 5:45 AM To: WixUsers Subject: [WiX-users] Building a setup.exe Hi Jim, it would seem that you are talking about a CD-browser-like functionality. In the past we have used DemoShield (no longer available) from Installshield to do this. There are a couple of freeware/shareware ones available, a good list is shown on installsite.com [http://installsite.org/pages/en/tt_cdbrowse.htm]. In the past, I have written a launcher in c++ to do prerequisite installs -- the important thing to watch out for these kinds of tools is the prerequisites that must exist on the machine before your launcher starts. You have to assume that the machine you are inserting the CD into has just been installed and has no .NET framework (if XP), no service packs, no updated C++ runtime, not visual basic runtime etc. Be sure to test on a new, virgin OS installation either on a Virtual box or on a real one. Testing this sort of stuff with a Virtualization environment (especially VMWare, where you can do a whole bunch of stuff, and then just not commit, but revert back to the original), is a real timesaver. Hope this helps, Friedrich Brunzema _ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the http://us.rd.yahoo.com/evt=40705/*http:/mrd.mail.yahoo.com/try_beta?.intl=c a All-new Yahoo! Mail - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] FW: Database is trying to be dropped when it was not created during current install
Hi, I didn't get a response to this yet. Can someone pls help me here? Thanks. From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: RE: Database is trying to be dropped when it was not created during current installDate: Sat, 28 Jul 2007 18:23:19 -0700 Hi, I am creating a database using the following wix code. sql:SqlDatabase Id=PWDB Database=pwdb Server=localhost CreateOnInstall=yes CreateOnReinstall=yes DropOnInstall=noDropOnReinstall=no DropOnUninstall=noContinueOnError=no On the first installation it creates the db successfully. During reinstall, if one the db scripts fails to run (any script running on this db using sqlstring), then during rollback setup tries to delete the database. MSI (s) (9C:B8) [22:26:01:440]: Executing op: CustomActionRollback(Action=RollbackCreateDatabase,ActionType=1281,Source=BinaryData,Target=DropDatabase,CustomActionData=PWDB€localhost€€PWDB€65€1€€) MSI (s) (9C:2C) [22:26:01:440]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI304.tmp, Entrypoint: DropDatabase DropDatabase: Error 0x80040e14: failed to drop to database: 'PWDB', error: Cannot drop database PWDB because it is currently in use. MSI (s) (9C!18) [22:26:22:431]: Product: Sql Setup -- Error 26202. Error -2147217900: failed to drop SQL database: PWDB, error detail: Cannot drop database PWDB because it is currently in use.. Error 26202. Error -2147217900: failed to drop SQL database: PWDB, error detail: Cannot drop database PWDB because it is currently in use.. Can someone pls tell me why this happens and how to avoid this? In this particular case db didn't get deleted, but I am really worried it will get deleted during one of the upgrade and we will loose user data. Thanks, Paramesh - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installing a CA certificate with a client application
I've been trying to figure out how to install a CA certificate for a while now without a whole lot of luck. I found the IIS extension listing for the certificate element, and I've run into a couple of different errors with it. I've tried inserting this markup: iis:Certificate Id='CACERT' Request='no' CertificatePath='..\$bin\cacert.cer' StoreLocation='currentUser' StoreName='root'/ If I put this in its own element, I get an ICE18 error saying that the keypath for the component is INSTALLLOCATION, and that The Directory/Component pair must be listed in the CreateFolders table. I've never seen this error before, so I tried adding the certificate element to another component (thinking that having other files in the component might help). This time, the setup compiled, but the certificate wasn't installed. Nothing showed up in the verbose log, so I can't even tell if the installer tried to install the cert or not. Is there something else I'm going wrong here, or is there another way to install a certificate on a client machine? I'm using the latest Wix 3 build with votive. Thanks Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Database is trying to be dropped when it was not created during current install
extern C UINT __stdcall DropDatabase(MSIHANDLE hInstall)
{
…
hr = WcaInitialize(hInstall, DropDatabase);
ExitOnFailure(hr, failed to initialize);
hr = ::CoInitialize(NULL);
ExitOnFailure(hr, failed to intialize COM);
hr = WcaGetProperty( LCustomActionData, pwzData);
ExitOnFailure(hr, failed to get CustomActionData);
WcaLog(LOGMSG_TRACEONLY, CustomActionData: %S, pwzData);
pwz = pwzData;
hr = WcaReadStringFromCaData(pwz, pwzDatabaseKey);
ExitOnFailure(hr, failed to read database key);
hr = WcaReadStringFromCaData(pwz, pwzServer);
ExitOnFailure(hr, failed to read server);
hr = WcaReadStringFromCaData(pwz, pwzInstance);
ExitOnFailure(hr, failed to read instance);
hr = WcaReadStringFromCaData(pwz, pwzDatabase);
ExitOnFailure(hr, failed to read database);
hr = WcaReadIntegerFromCaData(pwz, (int *)lAttributes);
ExitOnFailure(hr, failed to read attributes);
hr = WcaReadIntegerFromCaData(pwz, (int
*)fIntegratedAuth); // Integrated Windows Authentication?
ExitOnFailure(hr, failed to read integrated auth flag);
hr = WcaReadStringFromCaData(pwz, pwzUser);
ExitOnFailure(hr, failed to read user);
hr = WcaReadStringFromCaData(pwz, pwzPassword);
ExitOnFailure(hr, failed to read password);
hr = SqlDropDatabase(pwzServer, pwzInstance, pwzDatabase,
fIntegratedAuth, pwzUser, pwzPassword, bstrErrorDescription); //No checks
here
CustomAction Id=ConfigureSql BinaryKey=ScaSchedule
DllEntry=ConfigureSql Execute=immediate Return=check /
CustomAction Id=CreateDatabase BinaryKey=ScaExecute
DllEntry=CreateDatabase Execute=deferred Return=check /
//no checks here too
CustomAction Id=RollbackCreateDatabase
BinaryKey=ScaExecute DllEntry=DropDatabase
Execute=rollback Return=check /
--
View this message in context:
http://www.nabble.com/Database-is-trying-to-be-dropped-when-it-was-not-created-during-current-install-tf4161278.html#a11929627
Sent from the wix-users mailing list archive at Nabble.com.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] AppSearch during UI
You could write a permanent registry entry containing the path that the user selected, then read the registry entry when the install is run again to find out where it was installed before. -Brian Simoneau -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnette, Bill Sent: Tuesday, July 31, 2007 10:50 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] AppSearch during UI We are trying to mitigate an admittedly pathological case during installation. 1. User installs application to other than default directory. The installation installs a permanent, never-overwrite configuration file which (among other things) specifies a file store [1] path which is specified by the user during installation via a dialog. [2] 2. User later uninstalls the application. Because the configuration file is permanent, it is not deleted. 3. User installs the application again and specifies the same installation location as the last time it was installed. But this time, since the configuration file exists, I don't want to show the UI that allows them to specify the file store location and I want to use the old configuration file (which never-overwrite already takes care of). The problem is, I can do the AppSearch before the UI to locate the configuration file in the default installation directory. But if the user changes the installation directory, how do I determine if the configuration file exists in that new path in order to skip the file store configuration UI? The only thing that comes to mind is to write an AppSearch-like CA that looks for the file in the new path. Is there an easier way? [1] The file store is the place where large media files are stored outside of the XML database. [2] I hear you! The installer should not do configuration. BUT, the application also allows optional installation of sample data. That sample data needs to go in the file store which is specified in the configuration file. So there needs to be some level of configuration in the installer. -- Bill Arnette Principal Software Developer StarWitness Business Unit Signalscape, Inc. www.starwitness.com - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] AppSearch during UI
It's not that I want to know where it was previously installed. It's that I want to know if a configuration file already exists in the path the user selects (INSTALLDIR). If the configuration file already exists, I don't want to give the appearance that it can be changed; i.e. I am presuming that that configuration file points to an orphaned configuration that the user wants to adopt again. Ex. - By default INSTALLDIR is set to C:\Program Files\MyApp - User changes the installation directory to C:\MyApp - User specifies the file store to be D:\MyApp\FileStore - The application is installed and the configuration file is written containing FileStore=D:\MyApp\FileStore - User uninstalls application [1]; configuration file remains. - User installs application again (new version) - User changes installation directory to C:\MyApp - Installer should detect that the configuration file already exists in C:\MyApp and not present the UI to specify the file store location. - The application is installed but the configuration file is not overwritten. [1] He didn't realize that he could just upgrade using the new installer instead of manually uninstalling the old version first. -- Bill Arnette www.starwitness.com -Original Message- From: Brian Simoneau [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 2:15 PM To: Arnette, Bill; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] AppSearch during UI You could write a permanent registry entry containing the path that the user selected, then read the registry entry when the install is run again to find out where it was installed before. -Brian Simoneau -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnette, Bill Sent: Tuesday, July 31, 2007 10:50 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] AppSearch during UI We are trying to mitigate an admittedly pathological case during installation. 1. User installs application to other than default directory. The installation installs a permanent, never-overwrite configuration file which (among other things) specifies a file store [1] path which is specified by the user during installation via a dialog. [2] 2. User later uninstalls the application. Because the configuration file is permanent, it is not deleted. 3. User installs the application again and specifies the same installation location as the last time it was installed. But this time, since the configuration file exists, I don't want to show the UI that allows them to specify the file store location and I want to use the old configuration file (which never-overwrite already takes care of). The problem is, I can do the AppSearch before the UI to locate the configuration file in the default installation directory. But if the user changes the installation directory, how do I determine if the configuration file exists in that new path in order to skip the file store configuration UI? The only thing that comes to mind is to write an AppSearch-like CA that looks for the file in the new path. Is there an easier way? [1] The file store is the place where large media files are stored outside of the XML database. [2] I hear you! The installer should not do configuration. BUT, the application also allows optional installation of sample data. That sample data needs to go in the file store which is specified in the configuration file. So there needs to be some level of configuration in the installer. -- Bill Arnette Principal Software Developer StarWitness Business Unit Signalscape, Inc. www.starwitness.com - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Creating User Environment Variable through Group Policy
Hi, I'm trying to deploy my installer package through Group Policy from Windows Server 2003 to Windows XP clients. The software is being distributed through Computer Configuration and assigned to the clients computers (as opposed to published). The setup installed all the files, system registry keys, and desktop shortcuts. However, the user environment variables are not written (system ones are created though). Local machine install (running MSI directly on the XP machines) did not have this problem. Did I neglect to set certain properties to enable writing to user env vars? How do I guarentee that user environment variables are set properly? Thanks, Vince -- View this message in context: http://www.nabble.com/Creating-User-Environment-Variable-through-Group-Policy-tf4194953.html#a11930339 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating User Environment Variable through Group Policy
Vince, A diff between verbose logs for a user initiated install and the active directory install would probably point out the issue. With the active directory install you don't have UI and I believe the entire install runs as local system. Thanks, Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent Ho Sent: Tuesday, July 31, 2007 3:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Creating User Environment Variable through Group Policy Hi, I'm trying to deploy my installer package through Group Policy from Windows Server 2003 to Windows XP clients. The software is being distributed through Computer Configuration and assigned to the clients computers (as opposed to published). The setup installed all the files, system registry keys, and desktop shortcuts. However, the user environment variables are not written (system ones are created though). Local machine install (running MSI directly on the XP machines) did not have this problem. Did I neglect to set certain properties to enable writing to user env vars? How do I guarentee that user environment variables are set properly? Thanks, Vince -- View this message in context: http://www.nabble.com/Creating-User-Environment-Variable-through-Group-P olicy-tf4194953.html#a11930339 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Multiple action with the same name
Hello In the help of WiX 3.0.3029.0 I saw the following for Quiet Execution CustomAction If you want to run more than one command line in the immediate sequence then you'll need schedule QtExec multiple times and set the QtExecCmdLine property (using a type 51 custom action) right before you want each of them executed. How I actually do that if I want to run a command line one after the other While I use standard custem action I use like this Custom Action=InvokeRsDS After=InstallFinalize NOT REMOVE /Custom Custom Action=InvokeRsRp1 After=InvokeRsDS NOT REMOVE /Custom Custom Action=InvokeRsRp2 After=InvokeRsRp1 NOT REMOVE /Custom Custom Action=InvokeRsRp3 After=InvokeRsRp2 NOT REMOVE /Custom Custom Action=InvokeRsRp4 After=InvokeRsRp3 NOT REMOVE /Custom Custom Action=InvokeRsCu1 After=InvokeRsRp4 NOT REMOVE /Custom Custom Action=InvokeRsCu2 After=InvokeRsCu1 NOT REMOVE /Custom But how I do it with quiet execution I want to start after InstallFinalize and run in sequence ( one after other ). Is there a list of the sequence number of the standard action that can be use? Or Is there option to use Different ID? Also In this situation How can I update the progress text of the action. Thx, Moti - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating User Environment Variable through Group Policy
Thanks Tom. How do I produce a log file from the Active Directory install? Since I can't specify arguments for the MSI execution (e.g. /l*vx log.txt). Cheers, Vince Thomas Svare wrote: Vince, A diff between verbose logs for a user initiated install and the active directory install would probably point out the issue. With the active directory install you don't have UI and I believe the entire install runs as local system. Thanks, Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent Ho Sent: Tuesday, July 31, 2007 3:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Creating User Environment Variable through Group Policy Hi, I'm trying to deploy my installer package through Group Policy from Windows Server 2003 to Windows XP clients. The software is being distributed through Computer Configuration and assigned to the clients computers (as opposed to published). The setup installed all the files, system registry keys, and desktop shortcuts. However, the user environment variables are not written (system ones are created though). Local machine install (running MSI directly on the XP machines) did not have this problem. Did I neglect to set certain properties to enable writing to user env vars? How do I guarentee that user environment variables are set properly? Thanks, Vince -- View this message in context: http://www.nabble.com/Creating-User-Environment-Variable-through-Group-P olicy-tf4194953.html#a11930339 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/Creating-User-Environment-Variable-through-Group-Policy-tf4194953.html#a11931242 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating User Environment Variable through Group Policy
Vince, There's a way to do it through group policy but I can't remember how off the top of my head. Do a search on voicewarmup and you'll find the registry entries you can set before the installation. Thanks, Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent Ho Sent: Tuesday, July 31, 2007 3:51 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Creating User Environment Variable through Group Policy Thanks Tom. How do I produce a log file from the Active Directory install? Since I can't specify arguments for the MSI execution (e.g. /l*vx log.txt). Cheers, Vince Thomas Svare wrote: Vince, A diff between verbose logs for a user initiated install and the active directory install would probably point out the issue. With the active directory install you don't have UI and I believe the entire install runs as local system. Thanks, Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent Ho Sent: Tuesday, July 31, 2007 3:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Creating User Environment Variable through Group Policy Hi, I'm trying to deploy my installer package through Group Policy from Windows Server 2003 to Windows XP clients. The software is being distributed through Computer Configuration and assigned to the clients computers (as opposed to published). The setup installed all the files, system registry keys, and desktop shortcuts. However, the user environment variables are not written (system ones are created though). Local machine install (running MSI directly on the XP machines) did not have this problem. Did I neglect to set certain properties to enable writing to user env vars? How do I guarentee that user environment variables are set properly? Thanks, Vince -- View this message in context: http://www.nabble.com/Creating-User-Environment-Variable-through-Group-P olicy-tf4194953.html#a11930339 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/Creating-User-Environment-Variable-through-Group-P olicy-tf4194953.html#a11931242 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting rid of the warnings when using the VC8 CRTmerge modules
The reason for the warnings is that the VS CRT merge modules aren't particularly well authored. A validation run on the merge modules would have revealed these problems to the authors at Microsoft. Windows Installer databases are really property databases - not using a fixed schema, just a bunch of properties for each row - but at the same time, have a fixed schema declared in the _Validation table. The actual package-building features are happy to allow you to insert anything you like anywhere. Only post-validation with the ICEs reveals where the resulting output doesn't match the declared schema. The names of the identifiers are longer than the length supported for an identifier, for several of the identifiers listed. As for SxsInstallCA/SxsUninstallCA, these should normally have been modularized, i.e. their identifiers suffixed with the module's GUID, so that there wasn't an identifier clash between modules or between the module and the outermost install. However, given what this does - install to the side-by-side Win32 assembly store - it probably would have been hard to ensure it only did the work from the current module rather than for all modules, so it presumably wasn't modularized so that it only runs once. There's some reason that these modules use custom actions to install to the side-by-side assembly store, rather than the built-in functionality (on Windows XP and Windows Server 2003 - the built-in functionality is used on Windows Vista). I'm not sure where the InstallExecuteSequence (etc) stuff is coming from - I can't see these identifiers listed in the ModuleInstallExecuteSequence in the copy of DebugCRT MSM that I have. I will note that you shouldn't be distributing the debug CRT outside your organization (only for internal testing), but the release CRT MSMs have the same problem. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francois Retief Sent: 31 July 2007 10:28 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Getting rid of the warnings when using the VC8 CRTmerge modules Hello, From reading blogs on the web, the way to add the merge modules for the VC8 CRT libraries is shown in the WXS code below. But I get a lot of warnings in the process. We are using Visual Studio 2005 SP1 and Wix v3.0.2925 What is the reason for all the warnings? What can be done to fix the warnings? Or is there a bug/problem with the CRT merge modules? Cheers Francois ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=d1a9a77e-0717-404e-9d84-eb19ba6032a0 Name=MyWixTestApp Language=1033 Version=1.0.0.0 Manufacturer=me UpgradeCode=53518b27-3cb6-4224-8614-9a74207ccbf9 Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=WixProject1.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=MyCompanyFolder Name=MyCompany Directory Id=INSTALLDIR Name=MyProduct-1.x Component Id=ProductComponent Guid=b9396cba-4878-4413-b81b-4ec1ace56eeb !-- TODO: Insert your files, registry keys, and other resources here. -- File Id=ProductExeFile Source=$(var.ConsoleApplication1.TargetPath) / /Component /Directory /Directory /Directory Merge Id=CRT SourceFile=C:\Program Files\Common Files\Merge Modules\Microsoft_VC80_DebugCRT_x86.msm Language=1033 DiskId=1 / Merge Id=CRT Policy SourceFile=C:\Program Files\Common Files\Merge Modules\policy_8_0_Microsoft_VC80_DebugCRT_x86.msm Language=1033 DiskId=1 / /Directory Feature Id=ProductFeature Title=MyTestApp Level=1 ComponentRef Id=ProductComponent / MergeRef Id='CRT' / MergeRef Id='CRT Policy' / /Feature /Product /Wix -- Build started: Project: ConsoleApplication1, Configuration: Debug Any CPU -- ConsoleApplication1 - C:\workspace\WixProject1\ConsoleApplication1\bin\Debug\ConsoleApplication1.e x e -- Build started: Project: WixProject1, Configuration: Debug Any CPU -- C:\Program Files\Windows Installer XML v3\bin\candle.exe -dDebug -dDevEnvDir=C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\\ -dSolutionDir=C:\workspace\WixProject1\ -dSolutionExt=.sln -dSolutionFileName=WixProject1.sln -dSolutionName=WixProject1 -dSolutionPath=C:\workspace\WixProject1\WixProject1.sln -dConsoleApplication1.Configuration= -dConsoleApplication1.FullConfiguration= -dConsoleApplication1.Platform= -dConsoleApplication1.ProjectDir=C:\workspace\WixProject1\ConsoleApplication 1 \ -dConsoleApplication1.ProjectExt=.csproj -dConsoleApplication1.ProjectFileName=ConsoleApplication1.csproj -dConsoleApplication1.ProjectName=ConsoleApplication1 -dConsoleApplication1.ProjectPath=C:\workspace\WixProject1\ConsoleApplicatio n 1\ConsoleApplication1.csproj
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Thanks Dave, I understand what your saying, but I'm managing installers with 16,000+ files. That's not something I'm going to do manually and files can be added and deleted on a daily basis. Heat looks good from my prospective however its missing a critical piece, and that's (what believe what you call) a component catalog. Is there any plans on the horizon for such a feature in heat? Thanks again Jimbo From: David Howell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 4:17 PM To: Collins, James; 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Jimbo, I see your predicament! Again, InstallShield has the ability to add files via wildcards etc (not that I'm promoting InstallShield, for the cost its pretty clunky), can't remember the exact term. A question I would ask is that if you have 16,000+ files that are being changed, added, deleted on a daily basis, with daily builds, is msi technology your best option? Without know the circumstances (e.g. is it an internal project only) perhaps there is an easier way? Sorry, getting off-topic. As for the future of heat, I have no idea. I'm just a user ;-) Good Luck! Dave. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 9:19 AM To: David Howell; Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Thanks Dave, I understand what your saying, but I'm managing installers with 16,000+ files. That's not something I'm going to do manually and files can be added and deleted on a daily basis. Heat looks good from my prospective however its missing a critical piece, and that's (what believe what you call) a component catalog. Is there any plans on the horizon for such a feature in heat? Thanks again Jimbo _ From: David Howell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 4:17 PM To: Collins, James; 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. -
Re: [WiX-users] Uninstall removes everything in the folder.
Alex Steen wrote: Yes, there are other files, files that have nothing to do with the installer(I've tried installing to a folder with other things already present or adding files post install, but both way end up with the same result) that are getting deleted when I run an uninstall. Any file that is within the folder I designate as my install directory or within any of the underlying folders is gone upon uninstall. Sorry, I've never seen that happen without RemoveFile elements or a custom action gone bad. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File Paths and Fragments
Brian Poploskie wrote: I'm using some file keys in custom actions, for example [#MyFile]. This was working fine until I broke the core wxs file up into multiple files containing fragments for easier maintenance. Since I've done this the file references don't seem to be evaluating to anything. I get empty strings in the logs when I try to do the install. Is it not possible to use formatted strings to get the path of file objects when the files are in a fragment? Yes, it should work/does work for me. Can you narrow it down to a simple case? -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating User Environment Variable through Group Policy
Thomas Svare wrote: There's a way to do it through group policy but I can't remember how off the top of my head. Do a search on voicewarmup and you'll find the registry entries you can set before the installation. Copy this to a .reg file and keep it handy for new machines and unsuspecting beta testers: - Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer] Logging=voicewarmup Debug=dword:0007 - -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
