Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename
Hmm, ok. That's a bummer that they started putting parenthesis in there. There are several workaround for the issue (set another env var, hard-code the path, etc...). Could you open a bug in WiX 3.0 indicating that environment variables with parenthesis won't work? Thanks, Derek -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 5:49 PM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename Derek: The value is being used at build time to determine the location of the appropriate merge modules for Visual Studio 8 run times. Jeffrey Altman Derek Cicerone wrote: > Sorry for all the questions, here's one more: how is the value of the path > to Program Files (x86) being used? This value is specific to the build > machine so it wouldn't be useful in the MSI file since the machine on which > the msi is being installed may use a different path. You'd want to use > something more like the pre-defined property ProgramFilesFolder to get the > path of that folder during installation. > > Thanks, > Derek > > -Original Message- > From: Jeffrey Altman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 18, 2006 5:00 PM > To: [EMAIL PROTECTED] > Cc: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in > thename > > That is a standards Windows environment variable on 64-bit Windows > builds within the WOW64 environment. > > CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files > CommonProgramW6432=C:\Program Files\Common Files > > Jeffrey Altman > > Derek Cicerone wrote: >> Nested parenthesis is unsupported in both versions of WiX. Is that a >> standard Windows environment variable or one which you are defining? >> >> Derek >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey > Altman >> Sent: Tuesday, July 18, 2006 4:36 PM >> To: wix-users@lists.sourceforge.net >> Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in >> thename >> >> In build 2419 it was possible to evaluate the value of the environment >> variable >> >> CommonProgramFiles(x86) >> >> within a define as such >> >> >> >> In 2.0.4310.0 this is broken as the close parens are no longer matched >> with the open parens. >> >> Are there any quoting rules that can be used to make this work in the >> current build? >> >> Thanks. >> >> Jeffrey Altman >> > - 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename
Derek: The value is being used at build time to determine the location of the appropriate merge modules for Visual Studio 8 run times. Jeffrey Altman Derek Cicerone wrote: > Sorry for all the questions, here's one more: how is the value of the path > to Program Files (x86) being used? This value is specific to the build > machine so it wouldn't be useful in the MSI file since the machine on which > the msi is being installed may use a different path. You'd want to use > something more like the pre-defined property ProgramFilesFolder to get the > path of that folder during installation. > > Thanks, > Derek > > -Original Message- > From: Jeffrey Altman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 18, 2006 5:00 PM > To: [EMAIL PROTECTED] > Cc: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in > thename > > That is a standards Windows environment variable on 64-bit Windows > builds within the WOW64 environment. > > CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files > CommonProgramW6432=C:\Program Files\Common Files > > Jeffrey Altman > > Derek Cicerone wrote: >> Nested parenthesis is unsupported in both versions of WiX. Is that a >> standard Windows environment variable or one which you are defining? >> >> Derek >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey > Altman >> Sent: Tuesday, July 18, 2006 4:36 PM >> To: wix-users@lists.sourceforge.net >> Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in >> thename >> >> In build 2419 it was possible to evaluate the value of the environment >> variable >> >> CommonProgramFiles(x86) >> >> within a define as such >> >> >> >> In 2.0.4310.0 this is broken as the close parens are no longer matched >> with the open parens. >> >> Are there any quoting rules that can be used to make this work in the >> current build? >> >> Thanks. >> >> Jeffrey Altman >> > smime.p7s Description: S/MIME Cryptographic Signature - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename
Sorry for all the questions, here's one more: how is the value of the path to Program Files (x86) being used? This value is specific to the build machine so it wouldn't be useful in the MSI file since the machine on which the msi is being installed may use a different path. You'd want to use something more like the pre-defined property ProgramFilesFolder to get the path of that folder during installation. Thanks, Derek -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 5:00 PM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename That is a standards Windows environment variable on 64-bit Windows builds within the WOW64 environment. CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files Jeffrey Altman Derek Cicerone wrote: > Nested parenthesis is unsupported in both versions of WiX. Is that a > standard Windows environment variable or one which you are defining? > > Derek > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman > Sent: Tuesday, July 18, 2006 4:36 PM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in > thename > > In build 2419 it was possible to evaluate the value of the environment > variable > > CommonProgramFiles(x86) > > within a define as such > > > > In 2.0.4310.0 this is broken as the close parens are no longer matched > with the open parens. > > Are there any quoting rules that can be used to make this work in the > current build? > > Thanks. > > Jeffrey Altman > - 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename
That is a standards Windows environment variable on 64-bit Windows builds within the WOW64 environment. CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files Jeffrey Altman Derek Cicerone wrote: > Nested parenthesis is unsupported in both versions of WiX. Is that a > standard Windows environment variable or one which you are defining? > > Derek > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman > Sent: Tuesday, July 18, 2006 4:36 PM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in > thename > > In build 2419 it was possible to evaluate the value of the environment > variable > > CommonProgramFiles(x86) > > within a define as such > > > > In 2.0.4310.0 this is broken as the close parens are no longer matched > with the open parens. > > Are there any quoting rules that can be used to make this work in the > current build? > > Thanks. > > Jeffrey Altman > smime.p7s Description: S/MIME Cryptographic Signature - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename
Nested parenthesis is unsupported in both versions of WiX. Is that a standard Windows environment variable or one which you are defining? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Tuesday, July 18, 2006 4:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename In build 2419 it was possible to evaluate the value of the environment variable CommonProgramFiles(x86) within a define as such In 2.0.4310.0 this is broken as the close parens are no longer matched with the open parens. Are there any quoting rules that can be used to make this work in the current build? Thanks. Jeffrey Altman - 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bug in 2.0.4310.0 - environment vars with parens in the name
In build 2419 it was possible to evaluate the value of the environment variable CommonProgramFiles(x86) within a define as such In 2.0.4310.0 this is broken as the close parens are no longer matched with the open parens. Are there any quoting rules that can be used to make this work in the current build? Thanks. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] error uninstalling website
I have had problems where I used a property to specify the web address and because the property was not set at uninstall time, the uninstall failed. The trailing // in the key makes me suspect that you may have created a virtual directory whoose name came from a property. At uninstall time, the property has not been set and is substituted as a empty string. I wound up storing the web site property values in the registry so that an uninstall could properly initialize the properties uing a . From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don TasanasantaSent: Tuesday, July 18, 2006 5:16 PMTo: wix-users@lists.sourceforge.netSubject: [WiX-users] error uninstalling website I’ve gotten my website to install and now I’m getting an error trying to uninstall the website. “Failed to delete metabase key: /W3SVC/1/Root//” Has anyone experienced this before? __ Don Tasanasanta VIACK Corporation 425-605-7423 - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] error uninstalling website
I’ve gotten my website to install and now I’m getting an error trying to uninstall the website. “Failed to delete metabase key: /W3SVC/1/Root//” Has anyone experienced this before? __ Don Tasanasanta VIACK Corporation 425-605-7423 - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] merge module installation location
OK, thank you. I simply wrapped the component directory tree with: ... and all is well. -- View this message in context: http://www.nabble.com/merge-module-installation-location-tf1955504.html#a5381370 Sent from the wix-users forum at Nabble.com. - 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installing a Service with Varying Dependencies
We're struggling with a problem, and I'm curious if anyone has any creative solutions they can think of. We have a windows service that our MSI installs. This service does some things with MSMQ. We want to ensure that our service has the appropriate ServiceDependency so that Windows starts things in the correct order during system startup. Our WiX structure looks something like this (attributes removed to simplify): Now, in the next version of our product, the MSMQ related functionality is optional and we will have many customers who will not need or care about the MSMQ functionality. We'd like to detect if MSMQ is installed and make sure that the service is installed with the MSMQ dependency only if MSMQ is installed (else the service won't start when MSMQ is not installed). The first attempt to accomplish this with WiX was to have two nearly identical components and use conditions to choose only the correct one: MSMQ_IS_INSTALLED NOT MSMQ_IS_INSTALLED This doesn't work (in WiX v2) because of the . We use ServiceConfig to set the restart options correctly. WiX tries to put two rows in the ServiceConfig table both with the same ServiceName. This fails because ServiceName is the primary key and the second row errors out as a duplicate. So, the next attempt was to move the ServiceConfig element to a separate, shared Component that would always get installed regardless of if MSMQ was needed or not. This compiles into an MSI but fails at install time because the NewService column in the ServiceConfig table is set to 0 and the SchedServiceConfig custom action has code to verify that the service actually exists and this check runs before the installations script is executed (and so the service hasn't been installed yet). I don't like any of the options we're currently exploring, so I'm looking for any brainstorming ideas. Options we're currently looking at: 1. Using to add the ServiceConfig table with the single row we need and with NewService set to 1 and adding SchedServiceConfig to the sequence ourselves. Yuck. 2. Dropping the dependency from the ServiceInstall completely and adding a custom action to conditionally call sc.exe to add the dependency back if MSMQ is installed. Bleh. 3. Dropping the dependency from the ServiceInstall completely and adding code to our service itself so that when it starts up, it ensures that MSMQ is running and attempt to start it if it isn't already running. Windows won't know that our service depends on MSMQ, but we'll try to replicate the logic that Windows would have used. Bummer. Any other suggestions? Note, we haven't looked at WiX v3 yet (that's on my list for today) to see if there is some new way around this issue there. Thanks, Erv - 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action C++ DLL
Sorry didn't post my reply here before. That article was perfect but I have one question. I can get my DLL to execute just fine in the InstlallUISequence but as the author states if the install is a silent install then this action wont fire. I have tried to place it in the InstallExecuteSequence section to run Before FindRelatedProducts but nothing works. Is it not supposed to fire under this section? -- View this message in context: http://www.nabble.com/Custom-Action-C%2B%2B-DLL-tf1955356.html#a5374471 Sent from the wix-users forum at Nabble.com. - 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action C++ DLL
In terms of getting the DLL working, this is a good guide.
http://www.codeproject.com/tips/msicustomaction.asp?df=100&forumid=3159&exp=0&select=785495
It doesn't show you how to do what you want in the DLL, but it does show you
the steps needed to get
one working. As for the actual code, do you not have a programmer at the
company you could get help
from?
Rob
WayneBoyles wrote:
> Hello, I hope the following makes sence to someone!
>
> We have a piece of software which was done before I started with the company
> and now I have taken over the installation side of things.
>
> I am reading a registry value in a property called DATABASEPATH. This works
> fine except the original programmer set the entire path including the
> filename which i don't want, i only want the directory path (so at the
> moment we have for example: 'C:\My Folder\MyFile.txt' and what i NEED is
> 'C:\My Folder\')
>
> I have no idea how to tackle this and I have been playing around with
> CustomActions but I really dont know what I'm doing. I have some sample
> code from the MS Website which I modified and looks like this...
>
> UINT __stdcall DirectoryFormatter(MSIHANDLE hInstall)
> {
> TCHAR* szValueBuf = NULL;
> DWORD cchValueBuf = 0;
> UINT uiStat = MsiGetProperty(hInstall, TEXT("DATABASEPATH"), TEXT(""),
> &cchValueBuf);
> MsiSetProperty(hInstall, TEXT("DATABASEPATH"), TEXT("C:\\")); // set
> the
> property
>
> if (ERROR_MORE_DATA == uiStat)
> {
> ++cchValueBuf;
>
> szValueBuf = new TCHAR[cchValueBuf];
> if (szValueBuf)
> {
> uiStat = MsiGetProperty(hInstall, TEXT("DATABASEPATH"),
> szValueBuf,
> &cchValueBuf);
> MsiSetProperty(hInstall, TEXT("DATABASEPATH"),
> TEXT("C:\\")); // set the
> property
> }
> }
>
> if (ERROR_SUCCESS != uiStat)
> {
> if (szValueBuf != NULL)
> {
> delete [] szValueBuf;
> }
>
> return ERROR_INSTALL_FAILURE;
> }
>
> delete [] szValueBuf;
>
> return ERROR_SUCCESS;
> }
>
> Obviously a function will replace 'C:\\' with the stripped down path (could
> probably figure that out).
>
> My problem is getting this to run and change the DATABASEPATH property. The
> user is not going to get a choice at to where to install this because it
> will be installed into the directory that it finds. Am I over complicating
> things? If there is an easier way I would love to hear it because I'm
> pulling my hair out now!
>
> I am NOT a C++ Programmer so I have no idea what that code is doing!! Any
> help will be greatly appreciated.
>
> Thanks in advance
-
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.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
