[WiX-users] Are conditional service dependencies possible?
We're trying to install a service that is dependent on HTTP SSL in XP, however that service doesn't exist and isn't needed in Vista. When we added another ServiceDependency element to the service for HTTP SSL it stopped the errors we were getting in XP, but now it's impossible to start the service in Vista where it previously worked fine. Is there any sneaky way to give an individual ServiceDependency element a condition or am I going to have to create two different Components with identically named services but different dependencies? Thanks! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ 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
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. 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] 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 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.) In the InstallUISequence we schedule two of the above actions: NOT Installed >Custom Action="SetSqlExpressDir" After="SetSqlExpressDir.SetProperty">NOT Installed And in the ExitDialog we call the first CA when the Finish button is pressed: 1 1 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: 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: 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: 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: ... 1 1 1 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: net.exe 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: (Note that it's required to have the extra set of quotes around "net"!) 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 > > > 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 services are you sure you don't have any > > inter-service dependencies you're not taking care of? > > > > You can always check if the depe
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! > > > > A
[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: - 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] 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:
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] Multi-file assembly problem
I can't use the CopyFile element because even if I figured out how to recreate the obfuscated folder names in WinSxS, you're technically not supposed to be moving files around there yourself, and in fact in Vista you are prevented from doing so. If I put them in separate components using the normal method then they each get installed to their own WinSxS folder. I could look into fudging the manifest files so they're separate components but all installed to the DLL1 WinSxS folder, but that seems prone to difficulties, if it's even possible at all. On Dec 6, 2007 6:08 PM, Maletz, Josh <[EMAIL PROTECTED]> wrote: > Have you tried putting them in separate components or just using the > CopyFile element? > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Geoff > Finger > Sent: Thursday, December 06, 2007 6:16 PM > Cc: wix-users@lists.sourceforge.net; > [EMAIL PROTECTED] > > Subject: 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 and 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 > > > DLL2 in folder > > > > > >
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 and 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 > > DLL2 in folder > > > > 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 >
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
> DLL2 in folder
>
> 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 th
[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] 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 https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=260142";>Microsoft Connect Issue 260142 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
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] 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] 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: > > > > > Name="PFiles"> > > > So at first I thought it'd try > > 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] 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: So at first I thought it'd try 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
[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: > > > > and in AdminUISequence: > > NOT Installed > > 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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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: and in AdminUISequence: NOT Installed 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.php&p=sourceforge&CID=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.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] Using InstallShield msm files causes an error
How does one do that? I tried setting the sequence inside the AdminExecuteSequence element like with my own custom actions but that just caused "error LGHT0112 : Unresolved reference to symbol 'CustomAction:ResolveSource'" I checked the documentation for the Merge element and that doesn't seem to indicate any children that would be appropriate for modifying an internal custom action. The actual problem is "ResolveSource", which only actually shows up in Orca in the "ModuleInstallUISequence" table as: Action SequenceBaseAction After Condition setAllUsersProfile2KResolveSource 0 VersionNT >= 500 ResolveSource 525 On 3/14/07, Thomas Svare <[EMAIL PROTECTED]> wrote: > You should be able to set the sequence of the offending custom action > from the msm in main WiX project I think. > > Thanks, > Tom > > -Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Geoff > Finger > Sent: Wednesday, March 14, 2007 4:21 PM > To: wix-users@lists.sourceforge.net > Cc: Thomas Svare > Subject: 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.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] 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[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.php&p=sourceforge&CID=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: ... NOT Installed 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=lnk&kid=120709&bid=263057&dat=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 "<>" 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 <> instead of <> in your condition? > > Like: > FOOVAR <> "" > > Iso: > FOOVAR <> "" > > 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.php&p=sourceforge&CID=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: SVCLOGONTYPE = "System" SVCLOGONTYPE = "User" 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: 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 System 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.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] 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=" -sv -len 2048 -r pvk2pfx.exe -pvk -spc -pfx [-po Password] pktextract 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: , type=win32, version=, processorArchitecture=X86, 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 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 -hashupdate -makecdfs which updates the hash value and creates a cdf ffile. Next you run: makecat -v to create the cat file. FInally you run signtool sign /f [/p password] /t http://timestamp.verisign.com/scripts/timestamp.dll 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: 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='' version='' processorArchitecture='X86' 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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Side-by-side shared assemblies
Thanks for the advice about assemblies earlier. Since everyone seemed to think we were using assemblies in the wrong way we've once again scaled back our usage and are no longer trying to use the GAC. We have some dlls that are used by several different products. Since different versions of those products might be installed (and possibly even different versions of the same same product) we'd like to use side-by-side shared assemblies to minimize conflicts. I decided to start out converting zlib1.dll as a test and followed the directions at http://msdn2.microsoft.com/en-gb/library/aa374228.aspx for creating a signed side-by-side assembly since it has to be signed to be put into WinSxS as far as I understand. This process seemed to mostly work[1] and resulted in a signed zlib1.dll.cat, zlib1.dll.manifest, and zlib1.dll itself. Checking windows/winSxS seems to agree that this is reasonable for side-by-side assemblies. I still can't find any directions on how to install any kind of assemblies using Wix, so I decided to try modifying the process that seemed to work for the GAC, but use "win32" instead of ".net" since the new assemblies are supposed to be win32. Since I wasn't sure how to handle the multiple files I started out with just the manifest. However i got the same error as I was getting before: error LGHT0124 : Not a valid manifest file; detail: Data at the root level is invalid. Line 1, position 1. c:\Projects\ViewETL\Build\Win32\Release\ViewETL.exe 1 The error is odd because it isn't even referring the the zlib1 file. I'd suspect formatting issues except if i remove the "Assembly='win32'" bit it compiles fine. The actual code is: I tried using zlib1.dll.cat and zlib1.dll instead but got the same error. The (automatically generated) manifest itself is: So is the problem with the manifest I've created or am I trying to install it using the wrong method? I've done a lot of searching for instructions or a tutorial on how to do this and have reread the tutorial at tramontana.co.hu several times but found nothing, so I appologize if I'm asking something really basic. I've found directions on how to install side-by-side assemblies through msi here: http://msdn2.microsoft.com/en-us/library/aa369532.aspx so I could theoretically just edit the msi files that wix generates but that seems very awkward and hard to automate. Thank you very much for any help! This has been driving me crazy! [1] The most significant problem I noted with the creation of the assembly is that the msdn page claims there should be a line like "" which isn't in my manifest. I've tried changing some of the options dealing with files in project options under "Manifest Tool" but haven't had any luck that way. I tried adding the line in myself, with the appropriate file name of course, but that resulted in an mt error of: "manifest authoring error c1010006:The hash algorithm is not specified in the element with name="zlib1.dll"." Which seems wrong given that I was using the "-hashupdate" option specifically to add the hash part. running signtool verify /a /v zlib1.dll.cat results in: "SignTool Error: The signing certificate is not valid for the requested usage. This error sometimes means that you are using the wrong verification policy. Consider using the /pa option." Using "/pa" fixes it however and since the signing is only really used for CRC in WinSxS and not really for identification I was hopping that wouldn't be an issue. And when I've done all this trying to use the three files directly in the projects directory instead of the old dll results in a R6034 error which I can fix by embedding the manifest in the dll with mt. I'm hoping this is because it expects to handle local files and files from WinSxS differently. - 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] Installing shared assemblies
On Fri, 27 Oct 2006, Phil Wilson wrote:
> If you have a .NET assembly exposing COM interfaces you don't need an
> interop Dll, but you need it registering in the same general way that
> Regasm does (there's Tallow). Gacutil just puts it in the GAC. What you
> get for a registered .NET assembly are CLSID/{Guid} entries that show
> mscoree.dll as the COM server, and assemblyname data (and maybe
> codebase) that says which assembly and class to instantiate. You can't
> mark an assembly for type library registration, just Win32 files. If you
> really need a type library, tlbexp will generate one from your assembly.
> I'm not sure whether Wix prefers type library registration with the
> Registry table or with the TypeLib table.
>
> Phil Wilson
It started out as a COM dll, all I changed was embedding the manifest and
adding the assembly info, that doesn't in itself make it a .NET assembly
does it?
I didn't realize that I had to use regasm along with gacutil, but when I
tried using it I got the following error:
RegAsm : error RA : Could not load file or assembly 'SO80,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=a239c3af9cfd6278' or one
of its dependencies.
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(Exception from HRESULT: 0x800736B1)
I checked depends and it doesn't show any missing dependencies so I'm not
sure what's wrong. And although heat shows all the Intermediate Ids tallow
just gives:
Does that mean the assembly I've created is just broken or is there
something else I'm not understanding?
Thanks again!
-
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=lnk&kid=120709&bid=263057&dat=121642
___
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:
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=lnk&kid=120709&bid=263057&dat=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: > > > src="..\..\repository\Build\$(var.PLATFORM)\Release\cr.dll" > Vital="yes" > DiskId="1" Assembly=".net"> > >Value="$(var.PRODUCT_VERSION)"/> > > > > > --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\', 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=lnk&kid=120709&bid=263057&dat=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:
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=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
