Re: [WiX-users] ModuleInstallExecuteSequence not being merged into msi
That was in fact the problem, thanks! On Sat, Mar 22, 2008 at 11:42 AM, Bob Arnson [EMAIL PROTECTED] wrote: Geoff Finger wrote: In the ModuleInstallExecuteSequence table of the msm files we have rows such as: Action: RemoveOldDriver.B391C18A_6953_11D4_82CB_00D0B72E1DB9 Sequence: BaseAction: CostInitialize After: 0 Condition: INSTALLCONDITION=1 Does the ModuleInstallExecuteSequence table in the .msm also have a row for CostInitialize? Mergemod.dll requires merge modules to be self-contained in how they schedule actions. See the ModuleInstallExecuteSequence table doc in the MSI SDK for an explanation -- even if it's a lame one.g Try using smoke.exe to run validation on the merge module; it might provide details about problems that lead to a fix. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Changing an installation in Add/Remove fails if msi is missing
If we run our installation and then delete the msi when we're done,
uninstalling the program through add/remove works but selecting the
Change option fails. First it pops up the The feature you are trying
to use is on a network resource that is unavailable dialog, and if we
cancel out of that it generates a 1706 error.
I turned on automatic logging but don't see any obvious problems. I'm
not sure what's triggering the ResolveSource action that causes the
problem. Unless there's some specific error that's causing the problem
I need a way to make sure the msi is always available even if the user
gets rid of the original copy.
The person who handles the older InstallAware msi's says that they
have an web install option they can set that will make sure the
whole msi gets cached in Windows\Installer. Are there any similar
options in Wix, either for individual components or the whole msi?
The other alternative I'm considering is copying the entire msi to the
target folder during installation, but that seems rather awkward and I
haven't figure out what registry setting I'd need to fix to get
Add/Remove Programs to look for the msi in the new location.
The relevant section from the automatic log (as best as I can tell anyways):
Action ended 13:23:44: CostFinalize. Return value 1.
MSI (c) (58:4C) [13:23:44:451]: Doing action: setUserProfileNT
Action 13:23:44: setUserProfileNT.
Action start 13:23:44: setUserProfileNT.
MSI (c) (58:4C) [13:23:44:451]: PROPERTY CHANGE: Modifying USERPROFILE
property. Its current value is 'C:\Program Files
(x86)\Laserfiche\Server\'. Its new value: 'C:\Documents and
Settings\gfinger'.
Action ended 13:23:44: setUserProfileNT. Return value 1.
MSI (c) (58:4C) [13:23:44:451]: Skipping action: SetAllUsersProfileNT
(condition is false)
MSI (c) (58:4C) [13:23:44:451]: Doing action: setAllUsersProfile2K
Action 13:23:44: setAllUsersProfile2K.
Action start 13:23:44: setAllUsersProfile2K.
MSI (c) (58:4C) [13:23:44:451]: PROPERTY CHANGE: Modifying
ALLUSERSPROFILE property. Its current value is 'C:\Program Files
(x86)\Laserfiche\Server\'. Its new value: 'C:\Documents and
Settings\All Users'.
Action ended 13:23:44: setAllUsersProfile2K. Return value 1.
MSI (c) (58:4C) [13:23:44:451]: Doing action: ResolveSource
Action 13:23:44: ResolveSource.
Action start 13:23:44: ResolveSource.
MSI (c) (58:4C) [13:23:44:451]: Resolving source.
MSI (c) (58:4C) [13:23:44:451]: User policy value 'SearchOrder' is 'nmu'
MSI (c) (58:4C) [13:23:44:451]: User policy value 'DisableMedia' is 0
MSI (c) (58:4C) [13:23:44:451]: Machine policy value 'AllowLockdownMedia' is 0
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Media enabled only if
package is safe.
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Looking for sourcelist for
product {Product-ID}
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Adding {Product-ID}; to
potential sourcelist list (pcode;disk;relpath).
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Now checking product {Product-ID}
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Media is enabled for product.
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Attempting to use
LastUsedSource from source list.
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Trying source C:\Install\Server\.
MSI (c) (58:4C) [13:23:44:467]: Note: 1: 2203 2:
C:\Install\Server\server.msi 3: -2147287038
MSI (c) (58:4C) [13:23:44:467]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (c) (58:4C) [13:23:44:467]: Note: 1: 1706 2: -2147483647 3: server.msi
Thanks!
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] SetTargetPath causes errors in remote installations. Is there an alternative?
Our installation needs to install SQLExpress under certain conditions, and unfortunately we don't know what those condtions are until the user has already gotten through the installation, so we can't run it ahead of time through the setup.exe. After much experimentation I got an ExeCommand custom action hooked up to the Finish button of the ExitDialog page which runs the SQLExpress installer's setup.exe after our own msi has finished. This worked perfectly until people started trying to run the installation remotely over a mapped network drive, at which point whenever they hit Finish with the Sql installation box checked they'd get Error 1315: Unable to write to the specified folder: E:\Install\SQLEXPRESS\. and when they hit okay instead of exiting it goes back to the final dialog page instead of exiting. Since when I try double-clicking the setup.exe file at the same location I get a Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item. error I'm sure there's no way to get the SQLExpress installation to work under these conditions, but I'd like to be able to have it fail gracefully. Some research has indicated that the Publish Event SetTargetPath is the problem, and if I remove it then the error goes away, but the SQLExpress installation is no longer successfully run when the installer is run from a local location either. Is there anyway to get rid of the error with SetTargetPath or replace it with something else that will work locally but fail silently remotely? Here's the relevant bits of code: The custom action to actually run the setup.exe CustomAction Id=InstallSqlExpress Directory=SQLEXPRESSDIR ExeCommand='[SQLEXPRESSDIR]setup.exe -q /morebootchk /qb reboot=ReallySuppress addlocal=all instancename=OURNAMESPACE SCCCHECKLEVEL=IncompatibleComponents:1;MDAC25Version:0 ERRORREPORTING=1 SQLAUTOSTART=1 SAPWD=%1!s! DISABLENETWORKPROTOCOLS=0 /l*v %2!s!' Return=asyncNoWait / And the custom actions to set the location of the setup.exe (Using my own custom action was the only way I could find to reference a directory above the one which our own installer was running from.) CustomAction Id=SetSqlExpressDir Execute=immediate BinaryKey=mofc.dll DllEntry=SetSqlExpressDir / CustomAction Id=SetSqlExpressDir.SetProperty Return=check Property=SetSqlExpressDir Value=[SOURCEDIR] / In the InstallUISequence we schedule two of the above actions: Custom Action=SetSqlExpressDir.SetProperty Before=ExecuteActionNOT Installed/Custom Custom Action=SetSqlExpressDir After=SetSqlExpressDir.SetPropertyNOT Installed/Custom And in the ExitDialog we call the first CA when the Finish button is pressed: Control Id=Finish Type=PushButton X=246 Y=242 Width=56 Height=17 Default=yes Cancel=yes Text=[ButtonText_Finish] Publish Event=SetTargetPath Value=SQLEXPRESSDIR1/Publish Publish Event=DoAction Value=InstallSqlExpress![CDATA[(NOT Installed) AND InstallSqlExpressCheck AND (GROUP = 1) AND NOT OURNAMESPACELOCATION]]/Publish Publish Event=EndDialog Value=Return1/Publish /Control If the SetTargetPath event is removed then when we try to run it locally clicking Finish causes it to exit properly but the SQLExpress setup isn't run and the log shows: Action 6:50:30: ExitDialog. Dialog created MSI (c) (83:CD) [06:52:26:459]: Doing action: InstallSqlExpress Action 6:52:26: InstallSqlExpress. Action start 6:52:26: InstallSqlExpress. Action ended 6:52:26: ExitDialog. Return value 1. Action ended 6:52:26: INSTALL. Return value 1. Action ended 6:52:26: InstallSqlExpress. Return value 1631. Thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ModuleInstallExecuteSequence not being merged into msi
I'm having some trouble getting a couple of 3rd party msm files to work correctly. The original instructions said that along with including the merge module we should also schedule several custom actions in the msi. After that failed I looked around the archives and found several threads saying that's not how it's supposed to work and merge modules that require that are badly designed. (Of course I already kind of suspected that when I discovered that all three of the merge modules in the package had identical GUIDs with just one digit switched between each of them =) So we decided to edit the original merge modules with Install Shield and insert the custom actions into the ModuleInstallExecuteSequence tables. However when we rebuilt the msi we found the custom actions still weren't getting called. When I opened the newly built msi with Orca I found that the Custom Actions show up correctly in the CustomAction table, but that no new rows are being merged into InstallExecuteSequence. Is there something special that needs to be done to get that to happen? I didn't see any obvious errors when running the makefile, and I don't see anything about it in the documentation for the merge element. I'm using Wix 2.0 and what I have in the code is elements such as: Merge Id=ConfigFilesMSM Language=0 src=I:\Install\Files\Shared\ConfigFiles.Msm DiskId=1 FileCompression=yes / In the ModuleInstallExecuteSequence table of the msm files we have rows such as: Action: RemoveOldDriver.B391C18A_6953_11D4_82CB_00D0B72E1DB9 Sequence: BaseAction: CostInitialize After: 0 Condition: INSTALLCONDITION=1 I was a bit suspicious of the GUID being tacked on there, but doing it with and without the GUID doesn't seem to make any difference. I was also unsure about leaving the Sequence column blank, but adding a specific sequence number didn't seem to help either. Since I haven't been able to find any threads from other people encountering the issue it seems like it has to be something really simple that I'm missing. Thanks for any help! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Accessing directories above SourceDir
We have two Projects, A and B. There is a file in ProjectB that needs to be run by ProjectA. Originally thinking that ProjectB was a child of ProjectA I wrote some code that included the lines: CustomAction Id=ResetProjectBDir Property=PROJECTBDIR Value=[SourceDir]\PROJECTBDIR / CustomAction Id=RunBFile Directory=PROJECTBDIR ExeCommand='[PROJECTBDIR]file.exe ' Return=asyncNoWait / That worked fine, and to show a random example from the install log right after CostFinalize, resulted in: PROPERTY CHANGE: Modifying PROJECTBDIR property. Its current value is 'C:\Documents and Settings\gfinger\Desktop\Install\\PROJECTBDIR'. Its new value: 'C:\Documents and Settings\gfinger\Desktop\Install\PROJECTBDIR\'. However then I was informed that ProjectB was actually a sibling of ProjectA, and their install folders would be at the same level, along with some other sibling projects that would also need to access ProjectB in the same manner. So I changed the above to: CustomAction Id=ResetProjectBDir Property=PROJECTBDIR Value=[SourceDir]..\PROJECTBDIR / However now when I try to run it I get: Product: Project A -- Error 1324. The folder path '..' contains an invalid character. Is there some way to fix the Custom Action so it will work properly? Or some other way to access a folder that's above SourceDir in the folder hierarchy? Thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding an ok/cancel popup dialog?
Okay, thanks. I added an extra page after the Welcome dialog with the confirm/cancel message. Just one more page for the users to click through I guess :) On Sat, Mar 1, 2008 at 2:47 PM, Bob Arnson [EMAIL PROTECTED] wrote: Geoff Finger wrote: I hooked up the dialog to the Next button for the welcome dialog and everything seem to work fine, except that if you hit OK it goes back to the welcome dialog and doesn't go on to the next section of the installer until you hit Next again. Is there any way to make the Welcome page wait on the results of the spawned dialog before evaluating the next Publish action in the list? Or do I just need to give up and make the warning a standalone dialog page rather than a popup? When a spawned dialog is running, so is the dialog that spawns it. MSI doesn't have a way to close both dialogs from the spawned one. That's why we handled something similar before the welcome dialog, in src\Setup\VStudio.wxs. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Adding an ok/cancel popup dialog?
We just recently added the Upgrade Id value to the installer and the testers have complained that it deletes the old version of the program without asking first, so I'm trying to add an ok/cancel popup dialog at the first step of the installer if a previous version is detected to warn them about that. I hooked up the dialog to the Next button for the welcome dialog and everything seem to work fine, except that if you hit OK it goes back to the welcome dialog and doesn't go on to the next section of the installer until you hit Next again. Is there any way to make the Welcome page wait on the results of the spawned dialog before evaluating the next Publish action in the list? Or do I just need to give up and make the warning a standalone dialog page rather than a popup? What I've got currently is: Control Id=Next Type=PushButton X=230 Y=230 Width=56 Height=17 Default=yes Text=[ButtonText_Next] Publish Event=SpawnDialog Value=OldVerDetected![CDATA[OLDVERPRESENT AND OVERWRITEOKAY = 0]]/Publish Publish Event=NewDialog Value=FindLicenseDlg![CDATA[NOT OLDVERPRESENT OR OVERWRITEOKAY 0]]/Publish /Control Dialog Id=OldVerDetected Width=270 Height=95 Title=[ProductName] [Setup] NoMinimize=yes ... Control Id=OK Type=PushButton X=100 Y=60 Width=60 Height=17 Default=yes Cancel=yes Text=[ButtonText_OK] Publish Property=OVERWRITEOKAY Value=11/Publish Publish Event=EndDialog Value=Return1/Publish /Control Control Id=Cancel Type=PushButton X=200 Y=60 Width=60 Height=17 Default=yes Cancel=yes Text=[ButtonText_Cancel] Publish Event=EndDialog Value=Return1/Publish /Control /Dialog Thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Failing gracefully from ServiceControl?
Well it took me about six hours of websearching and following false leads to get the pretty easy custom action working, so just to try and save anyone else the effort in the future... I figured out almost immediately that you _can_ perform the action fairly simply using the following: Property Id=NETEXEnet.exe/Property CustomAction Id=StartMyService Property=NETEXE ExeCommand=start lfs Return=ignore / InstallExecuteSequence Custom Action=StartMyService After=InstallFinalize![CDATA[(MyServiceFeature = 3)]]/Custom /InstallExecuteSequence However that way you get a command line window popping up in the background as net.exe tries to start the service. I tried fiddling around with a lot of the properties but couldn't get it to run quietly. I finally found there's a specific function in wixca.dll to run command line function quietly. First you've got to find wixca.dll so you can either reference the location or copy it into your project. In my case it was in C:\Program Files (x86)\Windows Installer XML\bin. You then need something similar to the following: Binary Id=wixca src=wixca.dll/ CustomAction Id=StartMyService BinaryKey=wixca DllEntry=CAQuietExec Execute=immediate Return=ignore / CustomAction Id=StartMyService.SetProperty Property=QtExecCmdLine Value='net start MyService' / (Note that it's required to have the extra set of quotes around net!) InstallExecuteSequence Custom Action=StartMyService.SetProperty After=InstallFinalize![CDATA[(MyServiceFeature = 3)]]/Custom Custom Action=StartMyService After=StartMyService.SetProperty![CDATA[(MyServiceFeature = 3)]]/Custom /InstallExecuteSequence Thanks to everyone who offered suggestions on how to get this worked out! On Fri, Feb 22, 2008 at 4:03 PM, Alexander Shevchuk [EMAIL PROTECTED] wrote: It should be pretty easy to accomplish with custom action type 34 scheduled after InstallFinalize and with ExeCommand set to: net start servicename Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: Friday, February 22, 2008 3:42 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Failing gracefully from ServiceControl? That worked! When the service install fails the error box now has an Ignore option. When I saw that option in the docs it never occurred to me that it might also control the criticality of the item, I figured turning it off would just make the installation continue on a little further before it died. Thanks! So does anyone know of a way to make it always choose Ignore without popping up the window first? And KStuart, when I first started looking into this problem I found a couple posts from last year saying things like: The assemblies are not committed until successful execution of the InstallFinalize Action. This means that if you author a custom action or resource that relies on the assembly, it must be sequenced after the InstallFinalize Action. For example, if you need to start a service that depends on an assembly in the Global Assembly Cache (GAC), you must schedule the starting of that service after the InstallFinalize Action. This means you cannot use the ServiceControl Table to start the service, instead you must use a custom action that is sequenced after InstallFinalize. That certainly seems to indicate that if I want the services to start on a system where the assemblies haven't already been installed I'd have to make a custom action to do it, and we probably don't have time to deal with that before the release, which is why we're trying to get the fire and forget method working. On Fri, Feb 22, 2008 at 2:26 PM, Wilson, Phil [EMAIL PROTECTED] wrote: It's possible that setting the ServiceControl Wait value to 0 might make a difference. Generally speaking, this is the way you say you don't care if the service starts properly or not. However the documentation says that the SCM needs to get the service into pending state, and I don't know off the top of my head if this means the process has to at least start (and missing dependencies could mean it doesn't). Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KStuart Sent: Thursday, February 21, 2008 6:18 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Failing gracefully from ServiceControl? I haven't been using windows installer/wix very long so am a little confused, from what I can see the default behaviour of the install sequence is to process all files before attempting to start any services, therefore if your product includes dependent assemblies they will already have processed before the StartServices action, in fact starting services is close to the last action in the install sequence, of course you can always move it further back. If you're installing several
Re: [WiX-users] Failing gracefully from ServiceControl?
That worked! When the service install fails the error box now has an Ignore option. When I saw that option in the docs it never occurred to me that it might also control the criticality of the item, I figured turning it off would just make the installation continue on a little further before it died. Thanks! So does anyone know of a way to make it always choose Ignore without popping up the window first? And KStuart, when I first started looking into this problem I found a couple posts from last year saying things like: The assemblies are not committed until successful execution of the InstallFinalize Action. This means that if you author a custom action or resource that relies on the assembly, it must be sequenced after the InstallFinalize Action. For example, if you need to start a service that depends on an assembly in the Global Assembly Cache (GAC), you must schedule the starting of that service after the InstallFinalize Action. This means you cannot use the ServiceControl Table to start the service, instead you must use a custom action that is sequenced after InstallFinalize. That certainly seems to indicate that if I want the services to start on a system where the assemblies haven't already been installed I'd have to make a custom action to do it, and we probably don't have time to deal with that before the release, which is why we're trying to get the fire and forget method working. On Fri, Feb 22, 2008 at 2:26 PM, Wilson, Phil [EMAIL PROTECTED] wrote: It's possible that setting the ServiceControl Wait value to 0 might make a difference. Generally speaking, this is the way you say you don't care if the service starts properly or not. However the documentation says that the SCM needs to get the service into pending state, and I don't know off the top of my head if this means the process has to at least start (and missing dependencies could mean it doesn't). Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KStuart Sent: Thursday, February 21, 2008 6:18 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Failing gracefully from ServiceControl? I haven't been using windows installer/wix very long so am a little confused, from what I can see the default behaviour of the install sequence is to process all files before attempting to start any services, therefore if your product includes dependent assemblies they will already have processed before the StartServices action, in fact starting services is close to the last action in the install sequence, of course you can always move it further back. If you're installing several services are you sure you don't have any inter-service dependencies you're not taking care of? You can always check if the dependencies are already installed and skip trying to start the service if they are not, but like I said, if your product is installing those assemblies anyhow it shouldn't be an issue. Geoff Finger-2 wrote: I've got several services I'm trying to install. If I add Start='install' to the ServiceControl element then it will try to start them, but it will almost always fail with a 1920 error. I'm pretty sure this is because some of the services are dependent on side-by-side assemblies that are being installed at the same time and so won't be available until the install actually finishes. However is there a way to make it so that it will attempt to start the services but _not_ force a rollback if it fails? There are at least some circumstances where the assemblies might already have been installed by another package and it would be nice to at least make the attempt. There doesn't seem to be any Vital attribute for the ServiceControl element that I can set to no. There is a Vital for ServiceInstall, but I can't set that to no even if it would fix the above problem, because it _is_ vital that they at least install properly, even if they don't start right away, and the same goes for ErrorControl in the ServiceInstall element as well I think. As an added bonus, if the above can be done is there also a way to do the service start step silently? We're expecting it to fail most of the time so there's no need to pop up an error message about it if it does. Thanks! And here's the code I've got in case it matters: ServiceInstall Id=SystemServiceInstall DisplayName=$(loc.IDS_SERVER) $(var.MAJORVER).$(var.MINORVER) Description=$(loc.IDS_SERVER_SERVICE) $(var.MAJORVER).$(var.MINORVER) Name=ServerService ErrorControl=normal Start=auto Type=ownProcess Vital=yes ServiceDependency Id =HTTP / /ServiceInstall ServiceControl Id=SystemServiceControl Name=ServerService Start=install Stop=uninstall Remove=uninstall / - This SF.net email is sponsored by: Microsoft
[WiX-users] Failing gracefully from ServiceControl?
I've got several services I'm trying to install. If I add Start='install' to the ServiceControl element then it will try to start them, but it will almost always fail with a 1920 error. I'm pretty sure this is because some of the services are dependent on side-by-side assemblies that are being installed at the same time and so won't be available until the install actually finishes. However is there a way to make it so that it will attempt to start the services but _not_ force a rollback if it fails? There are at least some circumstances where the assemblies might already have been installed by another package and it would be nice to at least make the attempt. There doesn't seem to be any Vital attribute for the ServiceControl element that I can set to no. There is a Vital for ServiceInstall, but I can't set that to no even if it would fix the above problem, because it _is_ vital that they at least install properly, even if they don't start right away, and the same goes for ErrorControl in the ServiceInstall element as well I think. As an added bonus, if the above can be done is there also a way to do the service start step silently? We're expecting it to fail most of the time so there's no need to pop up an error message about it if it does. Thanks! And here's the code I've got in case it matters: ServiceInstall Id=SystemServiceInstall DisplayName=$(loc.IDS_SERVER) $(var.MAJORVER).$(var.MINORVER) Description=$(loc.IDS_SERVER_SERVICE) $(var.MAJORVER).$(var.MINORVER) Name=ServerService ErrorControl=normal Start=auto Type=ownProcess Vital=yes ServiceDependency Id =HTTP / /ServiceInstall ServiceControl Id=SystemServiceControl Name=ServerService Start=install Stop=uninstall Remove=uninstall / - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Checking for .NET version/existance
The program I'm installing has an Interop we'd like to install on
systems using .NET, but we still want to be able to install the
program with reduced functionality on systems without .NET. However
when we tried installing it on such a system we got an error because
it tried to add the interop to a nonexistant Windows\assembly
directory. So I added a condition to check the version of .NET
installed and make sure it was greater than or equal to .NET 1.0, as
follows:
Component Id=InteropSOLibToGAC Guid=MyGuidHere
File Id=InteropSOLibFile Name=IpSO.dll
LongName=Interop.SOLib.dll KeyPath=yes
src=..\..\Source\Build\Win32\Release\Interop.SOLib.dll
Assembly=.net /
Condition![CDATA[MsiNetAssemblySupport = 1.0.3705]]/Condition
/Component
I figured if .NET wasn't installed that should return false and kill
component. So to test it I grabbed a test machine and uninstalled all
the .NET components, but when I ran the installation it tried to
install the interop anyways. When I checked the log file I found the
following:
MSI (c) (C4:C8) [17:11:22:825]: Note: 1: 1935 2: {MyGuidHere} 3:
0x80004005 4: 5: CreateAssemblyCache 6:
Interop.SOLib,version=7.0.0.0,processorArchitecture=MSIL,publicKeyToken=507ED33EA22D1100,culture=neutral
MSI (c) (C4:C8) [17:11:22:825]: ignoring fusion interface error,
assuming we are bootstrapping (MsiNetAssemblySupport is unset)
followed a little later by:
MSI (s) (D8:7C) [17:12:00:949]: Assembly Error:Function not defined in
specified DLL.
MSI (s) (D8:7C) [17:12:00:949]: Note: 1: 1935 2: {MyGuidHere} 3:
0x8002802F 4: 5: CreateAssemblyNameObject 6:
Interop.SOLib,version=7.0.0.0,processorArchitecture=MSIL,publicKeyToken=507ED33EA22D1100,culture=neutral
Error 1935. An error occured during the installation of assembly
component {MyGuidHere}}. HRESULT: 0x8002802F. assembly interface: ,
function: CreateAssemblyNameObject, assembly name:
Interop.SOLib,version=7.0.0.0,processorArchitecture=MSIL,publicKeyToken=507ED33EA22D1100,culture=neutral
MSI (s) (D8:7C) [17:13:03:975]: Product: Server 7.0 -- Error 1935. An
error occured during the installation of assembly component
{MyGuidHere}. HRESULT: 0x8002802F. assembly interface: , function:
CreateAssemblyNameObject, assembly name:
Interop.SOLib,version=7.0.0.0,processorArchitecture=MSIL,publicKeyToken=507ED33EA22D1100,culture=neutral
If it failed to be able to access the fusion interface then why did
the condition pass? Is this some kind of weirdness because .NET was
installed on the system once and then uninstalled, or will the same
thing happen on a completely clean machine? And is there any way to
force it to fail in that circumstance using the MsiNetAssemblySupport
call or something similar?
If not I think my alternatives are either to check for the existence
of the windows\assembly directory directly or check the registry to
see if the .NET keys are there, but neither of those solutions seems
ideal.
Thanks!
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Checking for .NET version/existance
Whoops, it turns out that it was actually being installed twice in different spots, once I updated _both_ spots to use the check everything was fine. That's what i get for trying to debug stuff at 6pm without making sure i've checked all 5000 or so lines of code =P (And perhaps I ought to pull those two references out into yet another fragment or merge module) Sorry bout that! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Multi-file assembly problem
Short version:
Is there any way to override what seems to be the default behavior and
force Wix/msi to install additional file elements in an assembly
Component into the WinSxS folder even though they aren't included in
the main file's manifest? Or alternately are there any kind and
generous souls out there who know how to correctly combine several
dlls into one multifile assembly using mt.exe , makecat and signtool?
Long version:
I've got a couple legacy dlls that I'm trying to include as
Side-by-side assemblies. I've gone through this process with other
files just fine before. The problem in this case is that one of the
dlls tries to load the others directly via LoadLibrary, and after
digging through the code a little it seems that changing that behavior
would cascade into rewriting the whole library. Making them into a
multifile assembly seems like it would work, but all the instructions
for making those are for C# code compiled with .NET, no explanation
about how to handle legacy code.
This would seem like an occasion to just give up on the whole assembly
idea, but I happened to discover while testing an installation that if
i just copy DLLs 2 and 3 to the Side-by-side folder for DLL 1 then the
whole thing works. So if I can just get Wix to put the files there
everything will be great.
However I've run into issues trying to get the files to install in
that manner. If i add the files to the dll 1 Component then the log
file says things like:
MSI (s) (5C:A8) [13:44:49:394]: Executing op:
AssemblyCopy(SourceName=DLL2.dll|DLL2I.dll,SourceCabKey=DLL2FileLocal.D0119AF2____,DestName=DLL2.dll,Attributes=16384,FileSize=57344,PerTick=32768,,VerifyMedia=1,ComponentId={7049DC30-651B-427D-A90B-3FAF27B23C27}AssemblyMode=0,)
MSI (s) (5C:A8) [13:44:49:394]: Source for file
'DLL2FileLocal.D0119AF2____' is compressed
InstallFiles: File: DLL2.dll, Directory: , Size: 57344
However nothing actually gets copied the DLL1 side-by-side folder
except for DLL1 itself.
I then tried changing the DLL1 manifest to include DLLs 2 and 3. That
either causes an installation error:
Error 1935. An error occured during the installation of assembly
component {7049DC30----}. HRESULT: 0x800736CC.
assembly interface: IAssemblyCacheItem, function: Commit, assembly
name:
DLL1,version=1.0.0.0,type=win32,processorArchitecture=X86,publicKeyToken=0301
Or it _does_ cause them to get copied over to the DLL1 side-by-side
folder, but then my program can't find DLL1 anymore for reasons I
can't figure out. (Depends says the Side-by-Side configuration has an
error, but when I right click on DLL1.dll in the depends file window
and select Properties it can find the file in WinSxS just fine.)
(The difference between the two problems is at what point I embed the
modified manifest file into the original DLL1 file using mt.exe)
I will be much obliged to anyone who can clear any of this mess up.
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-file assembly problem
The problem is that if I installed everything via the old method (each
of the three files set up as its own assembly with its own WinSxS
folder) and then copied the DLL2 and DLL3 files from their WinSxS
folders into the WinSxS folder for DLL1 then everything ran correctly.
If i can just recreate that situation with the installer then
everything would be fine, but Wix/Msi seems to refuse to copy
additional files into DLL1's WinSxS folder unless they're included in
the assembly manifest. Despite the fact they're part of DLL1's
Component block in Wix.
On Dec 6, 2007 4:10 PM, Kelly Leahy [EMAIL PROTECTED] wrote:
Or it _does_ cause them to get copied over to the DLL1 side-by-side
folder, but then my program can't find DLL1 anymore for reasons I
can't figure out.
Uhh... I think I can explain this one. Consider the following case:
DLL1 in folder not in path
DLL2 in folder not in path
DLL1 loads DLL2 using LoadLibrary (and relative path).
Application loads DLL1 by absolute path (like the way SxS works).
DLL1 won't successfully load DLL2. Also, if DLL1 'statically' binds to
DLL2, it will fail to load DLL1 altogether, since DLL2 isn't on the path.
The key thing here is that the only 'application folder' that is used to
resolve DLL dependencies is the EXE path, not the DLL path.
http://msdn2.microsoft.com/en-us/library/ms682586.aspx
Under no circumstances is the location of the DLL that is loading the other
DLL used in determining the DLL search path. This is why people have so
many problems with COM in-process servers that try to load DLL dependencies
from their application directory.
Geoff Finger [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
12/06/2007 03:38 PM
To wix-users@lists.sourceforge.net
cc
Subject [WiX-users] Multi-file assembly problem
Short version:
Is there any way to override what seems to be the default behavior and
force Wix/msi to install additional file elements in an assembly
Component into the WinSxS folder even though they aren't included in
the main file's manifest? Or alternately are there any kind and
generous souls out there who know how to correctly combine several
dlls into one multifile assembly using mt.exe , makecat and signtool?
Long version:
I've got a couple legacy dlls that I'm trying to include as
Side-by-side assemblies. I've gone through this process with other
files just fine before. The problem in this case is that one of the
dlls tries to load the others directly via LoadLibrary, and after
digging through the code a little it seems that changing that behavior
would cascade into rewriting the whole library. Making them into a
multifile assembly seems like it would work, but all the instructions
for making those are for C# code compiled with .NET, no explanation
about how to handle legacy code.
This would seem like an occasion to just give up on the whole assembly
idea, but I happened to discover while testing an installation that if
i just copy DLLs 2 and 3 to the Side-by-side folder for DLL 1 then the
whole thing works. So if I can just get Wix to put the files there
everything will be great.
However I've run into issues trying to get the files to install in
that manner. If i add the files to the dll 1 Component then the log
file says things like:
MSI (s) (5C:A8) [13:44:49:394]: Executing op:
AssemblyCopy(SourceName=DLL2.dll|DLL2I.dll,SourceCabKey=DLL2FileLocal.D0119AF2____,DestName=DLL2.dll,Attributes=16384,FileSize=57344,PerTick=32768,,VerifyMedia=1,ComponentId={7049DC30-651B-427D-A90B-3FAF27B23C27}AssemblyMode=0,)
MSI (s) (5C:A8) [13:44:49:394]: Source for file
'DLL2FileLocal.D0119AF2____' is compressed
InstallFiles: File: DLL2.dll, Directory: , Size: 57344
However nothing actually gets copied the DLL1 side-by-side folder
except for DLL1 itself.
I then tried changing the DLL1 manifest to include DLLs 2 and 3. That
either causes an installation error:
Error 1935. An error occured during the installation of assembly
component {7049DC30----}. HRESULT: 0x800736CC.
assembly interface: IAssemblyCacheItem, function: Commit, assembly
name:
DLL1,version=1.0.0.0,type=win32,processorArchitecture=X86,publicKeyToken=0301
Or it _does_ cause them to get copied over to the DLL1 side-by-side
folder, but then my program can't find DLL1 anymore for reasons I
can't figure out. (Depends says the Side-by-Side configuration has an
error, but when I right click on DLL1.dll in the depends file window
and select Properties it can find the file in WinSxS just fine.)
(The difference between the two problems is at what point I embed the
modified manifest file into the original DLL1 file using mt.exe)
I will be much obliged to anyone who can clear any of this mess up.
-
SF.Net
Re: [WiX-users] Multi-file assembly problem
Yes, I'm creating the manifests myself. Or rather I'm taking the automatically generated manifests, modifying them if necessary, and signing them by hand using mt.exe, makecat and signtool. I started out with manifest dependencies in DLL1 for DLL2 and DLL3, but that doesn't help with a LoadLibrary call, which expects to load the files directly. (I could remove the LoadLibrary call, but the results of that are passed on to a couple different functions, which pass results on to a couple different functions, and in the end ripping it out would directly or indirectly effect a lot of the code.) Putting the multiple file references into a single manifest file was what I was trying at the end of the original email. If I embedded the manifest back into the DLL1 file then Wix threw an error on installation. If I just left the original unmodified manifest in the DLL1 file then all the files get installed to the correct place, but then the program can't locate DLL1 anymore. It seems like I may need to do something differently with the manifest embedding for multifile assemblies, but I'm not sure what. The _simple_ solution would be finding a way to just force Wix to copy the files over without futzing about with the manifests any more than I already have. On Dec 6, 2007 4:58 PM, Kelly Leahy [EMAIL PROTECTED] wrote: Are you creating the manifest yourself? You should be able to create a manifest that has dependency references in it for DLL2 and DLL3... See the dependency and dependentAssembly tags in Manifest reference: http://msdn2.microsoft.com/en-us/library/aa374219.aspx It also looks like you can put multiple files in a single 'assembly manifest', but I don't know how to get WiX to install them. I still don't understand why your LoadLibrary works when you have the files in the same folder though - I'd be curious to see what GetModuleFileName returns on those modules. Kelly Geoff Finger [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/06/2007 04:29 PM To wix-users@lists.sourceforge.net, [EMAIL PROTECTED] cc Subject Re: [WiX-users] Multi-file assembly problem The problem is that if I installed everything via the old method (each of the three files set up as its own assembly with its own WinSxS folder) and then copied the DLL2 and DLL3 files from their WinSxS folders into the WinSxS folder for DLL1 then everything ran correctly. If i can just recreate that situation with the installer then everything would be fine, but Wix/Msi seems to refuse to copy additional files into DLL1's WinSxS folder unless they're included in the assembly manifest. Despite the fact they're part of DLL1's Component block in Wix. On Dec 6, 2007 4:10 PM, Kelly Leahy [EMAIL PROTECTED] wrote: Or it _does_ cause them to get copied over to the DLL1 side-by-side folder, but then my program can't find DLL1 anymore for reasons I can't figure out. Uhh... I think I can explain this one. Consider the following case: DLL1 in folder not in path DLL2 in folder not in path DLL1 loads DLL2 using LoadLibrary (and relative path). Application loads DLL1 by absolute path (like the way SxS works). DLL1 won't successfully load DLL2. Also, if DLL1 'statically' binds to DLL2, it will fail to load DLL1 altogether, since DLL2 isn't on the path. The key thing here is that the only 'application folder' that is used to resolve DLL dependencies is the EXE path, not the DLL path. http://msdn2.microsoft.com/en-us/library/ms682586.aspx Under no circumstances is the location of the DLL that is loading the other DLL used in determining the DLL search path. This is why people have so many problems with COM in-process servers that try to load DLL dependencies from their application directory. Geoff Finger [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/06/2007 03:38 PM To wix-users@lists.sourceforge.net cc Subject [WiX-users] Multi-file assembly problem Short version: Is there any way to override what seems to be the default behavior and force Wix/msi to install additional file elements in an assembly Component into the WinSxS folder even though they aren't included in the main file's manifest? Or alternately are there any kind and generous souls out there who know how to correctly combine several dlls into one multifile assembly using mt.exe , makecat and signtool? Long version: I've got a couple legacy dlls that I'm trying to include as Side-by-side assemblies. I've gone through this process with other files just fine before. The problem in this case is that one of the dlls tries to load the others directly via LoadLibrary, and after digging through the code a little it seems that changing that behavior would cascade into rewriting the whole library. Making them into a multifile assembly seems like
Re: [WiX-users] Uninstalling WinSxS in Vista
On Nov 5, 2007 9:33 PM, Bob Arnson [EMAIL PROTECTED] wrote: Geoff Finger wrote: I've run into an issue with Vista where the side by side assemblies installed to WinSxS do not get removed when the uninstaller is run. Known issue and I'm not aware of a workaround. And yes it sucks. Well good to know that it's still a current issue and not something wrong on my end. Thanks! - 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] Uninstalling WinSxS in Vista
I've run into an issue with Vista where the side by side assemblies installed to WinSxS do not get removed when the uninstaller is run. I found the a href=https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=260142;Microsoft Connect Issue 260142/a which seems to indicate that it is normal behavior for the WinSxS files in Vista to stick around and be deleted at some later unspecified time. I think the uninstaller is working properly because AssemblyUnpublish is being called, but I have no way to be sure since the files never seem to be removed. The computer i'm testing it on now had the uninstaller run four or five days ago and has been rebooted several times since then and the files are still there. Has anyone else run into this issue and if so have you figured out any way how to deal with it? Is there somewhere that can be checked that will indicate that the files are indeed marked for deletion and possible when that deletion is scheduled for? Or a way to force the cleanup to happen? (Either as part of the uninstall process or at some later date.) Thanks for the help! - 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] x64 and ProgramFilesFolder vs. ProgramFiles64Folder
On Oct 24, 2007 7:59 AM, Bob Arnson [EMAIL PROTECTED] wrote: Geoff Finger wrote: Instead what I found was a post claiming I don't think you want to reference ProgramFiles64Folder either. Use ProgramFilesFolder and Windows Installer will put things in the correct directory based upon the Component's Win64 setting. That's not how it works. A 64-bit package can write to both folders (as appropriate given the bitness of its components) but it's not automatic so you need both directory hierarchies. How do you avoid getting the error LGHT0109 : Duplicate symbol 'Directory:INSTALLDIR' found. errors in that case? I can change INSTALLDIR to INSTALLDIR2 or something similar, but then the file structure in Program Files (x86) won't match that in Program Files if the user changes the install directory, right? Do I need to make some kind of custom action to copy the value of INSTALLDIR to INSTALLDIR2 after the directory selection page? Thanks! (And sorry about the slow response, I got sidetracked onto another project for awhile.) - 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] x64 and ProgramFilesFolder vs. ProgramFiles64Folder
I have two installers for our project, one for 32 bit and one for 64 bit and I'm running into some problems with the x64 version. My first question, is there a tutorial for how to build x64 installers with wix 2.0 somewhere? I could have sworn I saw a link to one at some point, but I can't find any such links in the Documentation sections on wix.sourceforge, and I don't see anything on the subject in the tutorial on Tramontana. The specific problem in this case is the x64 installer was working just fine but someone pointed out that one of the files was 32 bit and thus should be installed to Program Files (x86) instead of the normal Program Files folder. The component already had Win64=no set, so I figured I needed to add a ProgramFilesFolder Directory as well as the ProgramFiles64Folder directory, but that caused errors such as Duplicate symbol 'Directory:INSTALLDIR' found. So I started looking around for how to have the hierarchies beneath both ProgramFilesFolder and ProgramFiles64Folder mirror each other. Instead what I found was a post claiming I don't think you want to reference ProgramFiles64Folder either. Use ProgramFilesFolder and Windows Installer will put things in the correct directory based upon the Component's Win64 setting. I tried that out, and instead _everything_ got installed to Program Files (x86), regardless of what its Win64 tag was set to. I have InstallerVersion=200 Compressed=yes Platforms=x64 in the Package element, and Win64=yes for all the components (except the one that's _supposed_ to end up in the x86 folder of course.) So was that post wrong and I need to find a different method, and if so what? Or was that post right and I'm trying to implement it incorrectly? Thanks for the help! - 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] x64 and ProgramFilesFolder vs. ProgramFiles64Folder
After poking around a little more I've found something in the logs that might be related. There are a lot of messages about: WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\InstallDir\File.exe' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0). Some google searches have indicated that some other people have complained in the past about it changing their install location between Program Files (x86) and Program Files, which is exactly what I want it to be doing in my case, but in all those examples iSwapAttrib was set to 1. And aside from those occasional complaints I've so far found nothing at all about what WIN64DUALFOLDERS and iSwapAttrib are or how to set the value of the later. Anyone have any clues of what I'm doing wrong in Wix to get that value screwed up? Thanks again! - 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] Allowing sources from either x64 or x86
I've got a rather simple question that is probably due to some obvious in hindsight error, but I'm totally stymied by it and haven't had any luck searching for a solution. I just recently switched from an x86 machine to an x64 machine running XP x64. I suddenly find that some of the installers I've written don't compile because they're looking for files in Program Files rather than Program Files (x86). In particular the Microsoft VC80 CRT and MFC merge modules in Program Files (x86)\Common Files\Merge Modules are being problematic. I thought for starters I could try using ProgramFilesFolder to see if that would resolve properly, but I can't get it to work correctly. I've got the following setup in the relevant wxs file: ?if ($(var.PLATFORM) = Win32)? ?define PROGRAMFILESFOLDER = ProgramFilesFolder? Directory Id=$(var.PROGRAMFILESFOLDER) Name=PFiles So at first I thought it'd try Merge Id=CRT Language=0 src=$(var.PROGRAMFILESFOLDER)\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm DiskId=1 FileCompression=yes / However that results in the error: Error 25 error LGHT0100 : File of type 'Module' with name 'ProgramFilesFolder\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm' could not be found. light.exe So it's getting resolved to ProgramFilesFolder but not getting any further. I tried [ProgramFilesFolder] instead, but that didn't work either. Is there some other variable I should be using or am I going about this in entirely the wrong way? Thanks! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Allowing sources from either x64 or x86
That worked, thank you! And of _course_ var.PROGRAMFILESFOLDER is going to have issues at build time, what was I thinking? *sigh* On 5/22/07, Mike Dimmick [EMAIL PROTECTED] wrote: You're looking for something defined at build time. Try $(env.ProgramFiles). Windows defines the ProgramFiles environment variable to the location of the Program Files folder. I'm not guaranteeing this will work as I don't have an x64 system and don't know whether ProgramFiles is defined differently for a 64-bit versus 32-bit process. I _think_ that since the WiX toolset is compiled with .NET 1.1, all the programs will run in 32-bit processes. Personally I prefer to put all my dependencies under my source tree and check them into source control so I can be certain that all builds are fully reproducible. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: 22 May 2007 23:23 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Allowing sources from either x64 or x86 I've got a rather simple question that is probably due to some obvious in hindsight error, but I'm totally stymied by it and haven't had any luck searching for a solution. I just recently switched from an x86 machine to an x64 machine running XP x64. I suddenly find that some of the installers I've written don't compile because they're looking for files in Program Files rather than Program Files (x86). In particular the Microsoft VC80 CRT and MFC merge modules in Program Files (x86)\Common Files\Merge Modules are being problematic. I thought for starters I could try using ProgramFilesFolder to see if that would resolve properly, but I can't get it to work correctly. I've got the following setup in the relevant wxs file: ?if ($(var.PLATFORM) = Win32)? ?define PROGRAMFILESFOLDER = ProgramFilesFolder? Directory Id=$(var.PROGRAMFILESFOLDER) Name=PFiles So at first I thought it'd try Merge Id=CRT Language=0 src=$(var.PROGRAMFILESFOLDER)\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm DiskId=1 FileCompression=yes / However that results in the error: Error 25 error LGHT0100 : File of type 'Module' with name 'ProgramFilesFolder\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm' could not be found. light.exe So it's getting resolved to ProgramFilesFolder but not getting any further. I tried [ProgramFilesFolder] instead, but that didn't work either. Is there some other variable I should be using or am I going about this in entirely the wrong way? Thanks! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] InstallLevel has no effect when modifying an installation
My projects has three options in the Setup dialog. Typical with InstallLevel 3, Admin with InstallLevel 1, and the Custom option which takes it to the Custom Setup dialog with InstallLevel 3 as the default. This all works fine, but I've run into trouble trying to modify the installation by running the msi file again later. If I install it at the Admin level and then try to modify it to Typical nothing is added. Likewise if I install at the Typical level and try to modify it to Admin nothing is removed. In both cases selecting Custom and manually selecting which files i want added or removed works fine. Is there some additional work i need to do to get the Typical and Admin settings working on modification, or is that not the way Wix was meant to be used and should I have it skip the Setup dialog and go straight to the Custom Setup dialog? Thanks! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Accessing the Source Directory
Most of the files are made part of the installer using the File element, however there are two files that are an exception for two reasons. First, they're both part of the readme file which we want users to be able to access before they actually install the product. If it were just that we could include the file both in the installer and on the disk (though that seems slightly inelegant,) but the second reason is because historically these two files have been changed hours or even minutes before the actual release. Not that I think that's a very wise policy, but it's not anything I have any control over. On 3/22/07, Rob Mensching [EMAIL PROTECTED] wrote: Why are you copying files from the original media instead of just using the File element? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: Thursday, March 22, 2007 3:45 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Accessing the Source Directory I've been trying to figure out how to copy some files located in the directory the msi file is being run from to the Install directory, the big problem being that I couldn't find an easy way to fetch the value of the source directory. SourceDir leads to the root of the drive and CURRENTDIRECTORY isn't accessible through Wix. Searching through the archives let to a lot of suggestions involving the msi property OriginalDatabase, however that includes the file name so there is the added complication of writing a custom action to strip that off. While looking through the log files after some experiments however I noticed that SourceDir starts at the actual Source directory before being truncated to just the root. I managed to use the following custom action to grab the value before the truncation happens: CustomAction Id=ResetSetupDir Property=SETUPDIR Value=[SourceDir] / and in AdminUISequence: Custom Action=ResetSetupDir Before=ExecuteActionNOT Installed/Custom Since I didn't see that suggestion in response to any of the previous similar questions I thought it might be useful to share. - 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 - 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] Accessing the Source Directory
I've been trying to figure out how to copy some files located in the directory the msi file is being run from to the Install directory, the big problem being that I couldn't find an easy way to fetch the value of the source directory. SourceDir leads to the root of the drive and CURRENTDIRECTORY isn't accessible through Wix. Searching through the archives let to a lot of suggestions involving the msi property OriginalDatabase, however that includes the file name so there is the added complication of writing a custom action to strip that off. While looking through the log files after some experiments however I noticed that SourceDir starts at the actual Source directory before being truncated to just the root. I managed to use the following custom action to grab the value before the truncation happens: CustomAction Id=ResetSetupDir Property=SETUPDIR Value=[SourceDir] / and in AdminUISequence: Custom Action=ResetSetupDir Before=ExecuteActionNOT Installed/Custom Since I didn't see that suggestion in response to any of the previous similar questions I thought it might be useful to share. - 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] Disabling a Feature
I have a feature that can only installed if .net 1.1 or higher is also installed. The description for the feature indicates this requirement but I don't want to trust to the users' good sense, some of them will either not read the message or ignore it and get into trouble. Searching through the archives showed several posts about disabling a feature by using a Condition to set the Level to 0. I tried this and it worked fine except that the feature wasn't just disabled, it was entirely removed. I'd like the feature to be visible but unchangeable from the won't be installed state so the users can select it and see the requirement in the description and then go install .net if necessary. Is there any way to do this? Thanks! - 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 InstallShield msm files causes an error
Yeah, changing the sequence of ResolveSource from 525 to 1025 fixed it, thanks! Is there a way to override the sequence of an item in a Merge Module when you reference it, or am I going to have to run Orca and fix it manually every time I recompile? On 3/14/07, Thomas Svare [EMAIL PROTECTED] wrote: That should work. If you have any custom actions in your msm verify that the sequencing is after the cost standard actions. Thanks, Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: Wednesday, March 14, 2007 1:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using InstallShield msm files causes an error I'm trying to include a merge module from an older project that was made when we were using InstallShield to create our installations. When I try including it in my Wix project it compiles fine but when running it I get the error: Action start 16:32:36: ResolveSource. MSI (c) (EC:E0) [16:32:36:124]: Note: 1: 2732 2: 0 DEBUG: Error 2732: Directory Manager not initialized. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2732. The arguments are: 0, , I tried using dark to decompile the msm file and recompiled it directly into a new Wix merge module, and that seems to work fine. So if necessary I can just do that instead, but it would be preferable to get the original msm working. Is there something extra I need to do in order to get InstallShield merge modules to work with Wix? Or are the two just fundamentally incompatible? (I tried searching the list archives for any info on this but I keep getting 500 - Internal Server Error) - 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] Sequential msi installations
The program I'm working on needs to have either SQL 2005 or the SQL Server Native Client installed. We've decided that if neither of those have been installed we should give the user the option of installing the Native Client after the basic installation is finished in order to simplify things for them. I've looked through the archives and am aware that concurrent installation has been deprecated, so I've been trying to make it so the SQL installation only happens after my installation has finished. I put together the following code fragments just to test before I worried about the UI or detecting an existing installation: CustomAction Id=RunSQLNativeClientMsi BinaryKey=SQLNativeClientMsi ExeCommand=/ InstallExecuteSequence ... Custom Action=RunSQLNativeClientMsi After=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence Binary Id=SQLNativeClientMsi src=sqlncli.msi/ However that results in the following error: Action 11:59:58: RunSQLNativeClientMsi. Action start 11:59:58: RunSQLNativeClientMsi. MSI (s) (B0:A4) [11:59:59:228]: Note: 1: 1721 2: RunSQLNativeClientMsi 3: C:\WINDOWS\Installer\MSI9C0.tmp 4: Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RunSQLNativeClientMsi, location: C:\WINDOWS\Installer\MSI9C0.tmp, command: MSI (s) (B0:A4) [12:17:46:746]: Product: Server -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RunSQLNativeClientMsi, location: C:\WINDOWS\Installer\MSI9C0.tmp, command: Action ended 12:17:46: RunSQLNativeClientMsi. Return value 3. Action ended 12:17:46: INSTALL. Return value 3. Am I doing something wrong, or it it just not possible to run msi files with a Type 2 custom action? On the plus side the failure doesn't cause a rollback which seems to indicate that I've at least got the timing right. If it's not possible this way then is there some other manner in which I can trigger the second msi to run after the first one finishes? Thanks! - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with CDATA and default values in Conditionstatements
Swapping in lt;gt; fixed both issues! Thank you! Why is it necessary to use that in some cases though when in other spots I used without any problem? Shouldn't using the CDATA wrapper have prevented it from being an issue? On 1/30/07, Albert van Peppen [EMAIL PROTECTED] wrote: Did you try using lt;gt; instead of in your condition? Like: ConditionFOOVAR lt;gt; /Condition Iso: ConditionFOOVAR /Condition Regards, Albert van Peppen - 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] Problem with CDATA and default values in Condition statements
I can't get the comparison to work in the CDATA statement for my Condition elements and trying to set a default value on the property that is being tested is breaking them as well. I have a radio button selection during the setup that determines whether the service that is being installed will be run by the system or a user, with elements such as this: Control Id=AccountName Type=Edit X=120 Y=85 Width=150 Height=18 TabSkip=no Property=SVCACCOUNTNAME Condition Action=disableSVCLOGONTYPE = System/Condition Condition Action=enableSVCLOGONTYPE = User/Condition /Control I haven't determined a better way to handle the actual installation than to have two almost identical components, one with Account and Password attributes in the ServiceInstall element and the other without. In the feature I have two sub-features that I'm trying to choose between using Condition elements. I've gotten the following code which works: Feature Id=SystemService Display=hidden TypicalDefault=install Level=1 ComponentRef Id=SystemServiceComponent/ Condition Level=0![CDATA[SVCLOGONTYPE = User]]/Condition /Feature Feature Id=UserService Display=hidden TypicalDefault=install Level=1 ComponentRef Id=UserServiceComponent/ Condition Level=0![CDATA[SVCLOGONTYPE = System]]/Condition /Feature There are two changes I'd like to make, I'd like to change it so that the condition for disabling the SystemService feature is that SVCLOGONTYPE is not set to System, rather than disabling it if it is set to User. However if I change the = to and swap the names then no matter which option I select neither gets installed. The log file shows Feature: SystemService; Installed: Absent; Request: Null; Action: Null Feature: UserService; Installed: Absent; Request: Null; Action: Null but as far as I can tell there's no logging of the evaluation of the Condition statement so I can't tell what's going wrong. Second I want to have the radio buttons default to System rather than neither being selected when I get to that page. However if I add Property Id=SVCLOGONTYPESystem/Property then again neither element gets installed and the same messages show up in the log. There are also messages like PROPERTY CHANGE: Modifying SVCLOGONTYPE property. Its current value is 'System'. Its new value: 'User'. So I know that the default is being used and then getting overridden, but again there's no debug info about the Condition evaluation so I don't know why neither feature is being installed. Any help on how to fix this, especially the default property value, or some other workaround on how to make the dialog start with System selected, would be greatly appreciated! Thanks! - 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] How to integarte an .cat file
I'm not sure what steps you've already completed so here's the entire process I followed. In my case I was using MS VS 2005, obviously some steps my have to be addapted depending on the enviroment you're working under. First you have to create a key if you don't have one already: makecert -n CN=CompanyName -sv PVKFile.pvk CertificateFile.cer -len 2048 -r pvk2pfx.exe -pvk PVKFile.pvk -spc CertificateFile.cer -pfx PFXFile.pfx [-po Password] pktextract CertificateFile.cer The password, if any, will be the one you enter for the first step. The last step generates the public key token you'll be needing later. You'll need a manifest file, you can write it yourself or take the easy way out by compiling the project once after going to project properties and selecting General-Manifest. Set the Assembly Identity to: DllName, type=win32, version=VersionNumber, processorArchitecture=X86, publicKeyToken=PublicKeyToken DllName is the name without the extension, VersionNumber is of the form 1.2.3.4, and the PublicKeyToken is the one you got from pktextract. Make sure you have Embed Manidest under Input and Output set to no for this first time. Depending on the compiler you're using you may need to edit the resulting manifest file and add the line file name=dllFile.dll hash= hashalg=SHA1/ before any dependency elements. the file name is the final name of the file, with the extension. The value of the hash bit is unimportant because it will be overwritten later. You can save the resulting manifest file and reuse it for the following steps multiple times as long as none of the fundamental values change (file name, version number, encryption key, etc) You then run mt.exe -manifest dllFile.dll.manifest -hashupdate -makecdfs which updates the hash value and creates a cdf ffile. Next you run: makecat -v dllFile.dll.manifest.cdf to create the cat file. FInally you run signtool sign /f PFXFile.pfx [/p password] /t http://timestamp.verisign.com/scripts/timestamp.dll dllFile.dll.cat to sign the catalog file using the key. Now the wix bit, which I had a lot of trouble with and sent a couple messages to the list about without resulting in much progress. Once I figured out what the missiing bits were however it turned out to be pretty simple: Component Id=DllComponent Guid=MYGUID-# File Id=ManFile Name=dllFile.man LongName=dllFile.dll.manifest src=Path\dllFile.dll.manifest Vital=yes DiskId=1 /File File Id=CatFile Name=dllFile.cat LongName=dllFile.dll.cat src=Path\dllFile.dll.cat Vital=yes DiskId=1 /File File Id=DllFile Name=dllFile.dll LongName=dllFile.dll KeyPath=yes src=Path\dllFile.dll Vital=yes DiskId=1 Assembly=win32 AssemblyManifest=ManFile /File /Component And of course finally once you've installed your new assembly you need to reference it in any other projects that will be using it by going to Project Options-Linker-Manifest File-Additional Manifest Dependencies and adding type='win32' name='DllName' version='VersionNumber' processorArchitecture='X86' publicKeyToken='PublicKeyToken' language='*' There are a couple pages that halped me figure this stuff out if you want to take a look at them: http://msdn2.microsoft.com/en-us/library/aa376307.aspx http://msdn2.microsoft.com/en-us/library/ms235512.aspx and especially: http://msdn2.microsoft.com/en-gb/library/aa374228.aspx On 1/25/07, Frank Büttner [EMAIL PROTECTED] wrote: How can I integrate an .cat file in my merge module. This file is needed for my side-by-side assembly. Simple use the File Tag will get the error: error LGHT0104 : Not a valid manifest file; How can I do this?? - 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 - 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] Installing shared assemblies
Thanks Mike for your earlier help with private assemblies. We've dropped
the idea of doing anything special with them but as expected we've moved
on to shared assemblies so I've got some more questions for anyone who can
help.
I've taken one of our old COM dlls and added an AssemblyInfo.cpp with what
I hope is the right Assembly values. The debug version still builds as a
normal dll which I then use to generate the manifest for the release
version (I'm unsure if there's anyway around this.)
There's a warning that embedding the manifest invalidates the signature,
but resigning it sn works, as does adding it to the GAC directly with
gacutil.
When I ran heat on the dll it generates a a file id line and a whole lof
of Interface Id lines. I modified them to fit the merge module slightly as
follows:
Directory Id=TARGETDIR Name=SourceDir
Directory Id=Assembly Name=Assembly
Component Id=MyModuleComponent
Guid=6C291D26-C78D-45e4-B05E-27EC5EEA97A7
File Id=SO80.dll Name=SO80.dll Assembly=.net
KeyPath=yes
Source=..\..\libs\SO\Build\$(var.PLATFORM)\Release\SO80.dll
TypeLib Id={DC37D6AD-1489-45B9-8F1E-162CF65E1FB2}
Description=Server
Objects 8.0 HelpDirectory=Assembly Language=0
MajorVersion=1 MinorVersion=0
Interface Id={0118AF21-A6C1-44EE-9AAE-2C48E634DE17}
Name=IAnnotation
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
etc.
If I use that then upon instalation I get Could not register type library
for file C:\Assembly\SO80.dll.
If I remove the Interface lines it seems to install fine and it shows up
in the GAC when I check with .Net Framework 2.0 Configuration. However
when I try to use the assembly in VBS with the line set s =
CreateObject(SO80.Application) (which worked with the old dll) I get
ActiveX Component can't create object: 'SO80.Application' Code: 800A01AD
I know that if you're dealing with a .Net assembly you have to make a COM
interop, but I thought that was what the manifest was for in an assembly
that was already COM. I had the initial impression that the purpose of the
GAC was to eliminate storing information in the registry, but I've been
informed that in order for COM objects to be accessible there still needs
to be information in the registry which isn't currently showing up when I
run the installation. Is gacutil/msi supposed to have done the
registration, meaning that my assembly is just broken, or was that
something I needed to include in wix? If it's the Interface stuff that I
had to remove then how can I include it without getting the above error?
Thanks for any help!
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Private Assemblies with Wix
On Fri, 20 Oct 2006, Mike Dimmick wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: 20 October 2006 00:54 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Private Assemblies with Wix I hope this email gets through (several earlier emails sent from my gmail account resulted in SMTP Error (state 9): 451-Could not complete sender verify callout) I've been working on the Wix installer for a project at my company for the past couple weeks, but the project manager has decided that we should install all our private dll's and exe's as assemblies. These files aren't actually compiled as assemblies but he thinks we may be able to do so anyways by making them private assemblies since those don't require signing. I haven't been able to find much documentation about assemblies here or in the tutorial on tramontana, but I've pieced together the following in the primary feature in the main wxs file: Component Id=CrDllComponent Guid=MyGuid Win64=$(var.IS64) File Id=CrDllFile Name=cr.dll KeyPath=yes src=..\..\repository\Build\$(var.PLATFORM)\Release\cr.dll Vital=yes DiskId=1 Assembly=.net AssemblyName Id=Name Value=Assembly/ AssemblyName Id=FileVersion Value=$(var.PRODUCT_VERSION)/ AssemblyName Id=Culture Value=neutral / /File /Component --8--snip--8-- I have a general rule I follow. It goes, 'if it hurts when you do this, don't do that.' If you're talking about .NET, anything compiled to the CLR is automatically an assembly. If an assembly is strong-named, the actual target version of the assembly is compiled into the referencing assembly. At run-time, the Framework will look for strong-named assemblies in the GAC first, then in the local folder, then under the culture, a 'bin' folder, then 'bin\culture', then fail. For a non-strong-named-assembly, the GAC is not checked. Generally, I only sign an assembly if I actually intend it to be shared, and install it to the GAC; if it's only intended for one application, or not designed for compatibility between versions, I don't sign it and install to the application directory. These can only be serviced as part of an application. The Assembly=.net attribute instructs Windows Installer to add the assembly to the GAC. You cannot do this if it is not strongly-named - the Framework will not let you (and as I said, it would be pointless to try since the Framework won't look there for the assembly anyway). Tell your project manager that the technology does not support his suggestion. Yes, we're using .Net so I was told that all the files already have an internal manifest so I shouldn't need to worry about an external manifest file. We intend to make the public dll's shared at some point in the future, so I think the intent is to be consistent by treating all the dll's and exe's as assemblies, either shared or private. So would the above code be correct if it were a shared dll? (If I added a publicKeyToken value at least) What do i need to change in order to have cr.dll treated as a private assembly? I tried just changing .net to win32, however for some reason that caused light.exe to start generating errors about other unrelated files in other features, saying file.ext : error LGHT0124 : Not a valid manifest file; detail: Data at the root level is invalid. Line 1, position 1. And i'd still like to know if thee are actually any good tutorials on the subject since even if I end up having to give up on the private assemblies I'll need to figure out how to handle the shared assemblies later. Thanks! - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Private Assemblies with Wix
I hope this email gets through (several earlier emails sent from my gmail
account resulted in SMTP Error (state 9): 451-Could not complete sender
verify callout)
I've been working on the Wix installer for a project at my company for the
past couple weeks, but the project manager has decided that we should
install all our private dll's and exe's as assemblies. These files aren't
actually compiled as assemblies but he thinks we may be able to do so
anyways by making them private assemblies since those don't require
signing.
I haven't been able to find much documentation about assemblies here or in
the tutorial on tramontana, but I've pieced together the following in
the primary feature in the main wxs file:
Component Id=CrDllComponent Guid=MyGuid Win64=$(var.IS64)
File Id=CrDllFile Name=cr.dll KeyPath=yes
src=..\..\repository\Build\$(var.PLATFORM)\Release\cr.dll Vital=yes
DiskId=1 Assembly=.net
AssemblyName Id=Name Value=Assembly/
AssemblyName Id=FileVersion Value=$(var.PRODUCT_VERSION)/
AssemblyName Id=Culture Value=neutral /
/File
/Component
This compiles fine and when I run it it starts to install, but partway
through it gets a 2908 error and then says that it couldn't install
cr.dll. The relevant bit from the log file is:
MSI (s) (20:18) [16:44:59:283]: Executing op:
ComponentRegister(ComponentId={MyGuid},KeyPath=\Assembly,FileVersion=0.0.0001,Culture=neutral,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
1: {91A299CF-3538-486C-87EE-1F0DD79ECB3F} 2: {MyGuid} 3:
\Assembly,FileVersion=0.0.0001,Culture=neutral
MSI (s) (20:18) [16:44:59:298]: MSCOREE already loaded, using loaded copy
MSI (s) (20:18) [16:44:59:330]: Assembly Error:The given assembly name or
codebase, '%1', was invalid.
MSI (s) (20:18) [16:44:59:330]: Note: 1: 1935 2: 3: 0x80131047 4: 5:
CreateAssemblyNameObject 6:
CrDll,FileVersion=0.0.0001,language=en,processArchitecture=x86,Culture=neutral
DEBUG: Error 2908: Could not register component {MyGuid}.
The installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2908. The
arguments are: {MyGuid}, ,
MSI (s) (20:18) [16:45:12:673]: Product: Laserfiche Server 8.1 -- The
installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2908. The
arguments are: {MyGuid}, ,
I'd appreciate any advice about what I'm doing wrong here, and would love
to know about any tutorials on installing assemblies with Wix that might
be out there on the net that I just haven't found yet. Thanks!
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
