[WiX-users] How to grab directory of Excel.exe during installation
I'm aware of the guide at http://support.microsoft.com/kb/240794 however
that only solves half my problem.
Basically, I know that the following registry key contains the directory
I want and that it is consistent over Excel 2002/XP, Excel 2003 and
Excel 2007 (same GUID for all three versions).
HKCR\CLSID\{00024500---C000-0046}\LocalServer32
The value of this registry key is something like:
C:\PROGRA~1\MICROS~2\OFFICE11\EXCEL.EXE /automation
I just want the directory put into another MSI property, so I can copy
another file (Excel.exe.config) to that same directory during my WiX/MSI
installation.
I have tried using ComponentSearch, DirectorySearch and FileSearch but I
can't figure out what combinations to use to get this to work since I
have no examples (http://www.wixwiki.com/index.php?title=Wix_Schema) and
the doc text is very sparse.
Here an example of what I have tried:
Property Id=EXCELDIR2002
ComponentSearch Id=ExcelDirSearch2002
Guid={00024500---C000-0046} Type=directory
FileSearch Id=ExcelExeFile2002 Name=Excel.exe /
/ComponentSearch
/Property
I've tried others too. Any working example of these elements, or any
pointers, would be helpful.
Thx
/Mathias
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] (no subject)
Got this to work on my own, so I'm replying to my own question here for
archive reasons.
There's another registry key that actually holds the exact installation
root path.
This works:
Property Id=EXCELDIR
RegistrySearch Id=ExcelRegistryInstallRoot2002 Type=raw
Root=HKLM Key=SOFTWARE\Microsoft\Office\10.0\Excel\InstallRoot
Name=Path /
RegistrySearch Id=ExcelRegistryInstallRoot2003 Type=raw
Root=HKLM Key=SOFTWARE\Microsoft\Office\11.0\Excel\InstallRoot
Name=Path /
RegistrySearch Id=ExcelRegistryInstallRoot2007 Type=raw
Root=HKLM Key=SOFTWARE\Microsoft\Office\12.0\Excel\InstallRoot
Name=Path /
/Property
Directory Id=TARGETDIR Name=SourceDir
Directory Id=EXCELDIR
Component Id=ExcelConfig
Guid={8F2608BB-E8E2-4ed9-A287-7DC370ABC084}
File Id=ExcelConfig Name=Excel.exe.config
Source=../../Setup/Excel.exe.config Vital=yes Assembly=no /
/Component
/Directory
...
Directory/
And then use that component ref in the respective feature alternatives.
/Mathias
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unable to install Services due to lack of privileges
Have you checked the event log for any error messages about why your server fails to start? -Original Message- From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] Sent: den 20 mars 2009 18:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to install Services due to lack of privileges Ok.. Here is a snippet of my XML file. Am I missing anything from this? I'm hoping someone can offer some direction on how to proceed. I'm in the process of testing an MSI package on a test server however do to server hardening restrictions it's not allowing my MSI package to install some Services. I've contacted my SA and they seem to feel that the account I'm logging in with has the rights to do the install. Could I be over looking something in Wix setting? -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Ram size checking
Thank you for the reply. I tested this on windows 2008,2003 and XP, on all of these machine actual ram size is 2048MB But in wix it shows PhysicalMemory = 2005. So it's causing problem for me. I can't put PhysicalMemory = 2048 condition. so what's the solution? Please help. Thank you in advance. How about PhysicalMemory = 2000? It's kinda funny, but I'm actually serious. Most machines that claim to have like 1 Gb memory on paper often seem to show up as having 1020 Mb or similar give or take a few megs, they do in our team. Thus, you should expect some natural variation in memory available and I'm not sure Windows Installer is actually wrong here btw. Don't know your situation, but you might have other options than to enforce this the hard way using Win Installer only. For instance, on our team our app memory requirements are 1 Gb memory. For us, this limit has been set rather arbitrary based on what our app needs for reasonable performance while still allowing the user to do work using a few other normal apps at the same time. Now most customers can meet those reqs, but not all. Knowing that hardware upgrades can be expensive (esp for a whole org) our approach has been to give some leeway on behalf of the customer while still enforcing our HW standards. This is how we do this. We allow the application to install even if the HW is sub par (512 Mb is our minimum level to allow install at all, since we feel it would simply not be usable at all below that). When the app starts we instead log the sub par HW and light a warning icon in the toolbar of the application window. When hovered, a tooltip informs the user that he might not experience full app performance because his HW (blabla) is below minimum reqs. We light this warning icon for 5 min after launch so it is not too annoying. We like this approach because we feel allowing the user to do work using a potentially slow app is better than stopping him altogether as long as he is informed. If the user is unhappy about performance, he hopefully now knows he should upgrade HW first before blaming the product or calling customer support. If not, support can read the logs and do this for him. We do the same based on CPU speed. Maybe something that can help you, dunno. /Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Support for conditional bootstrapper pre-requisites - Burn/dotNetInstaller/fw bootstrapper/other?
Our application install scenario contains conditional pre-requisites. What bootstrappers can do this today? Basically, we want a bootstrapper that can support this scenario: 1A) If App1 is installed, install X1 (matching addon MSI package to App1) 1B) If App1 is not installed, don't install X1 1C) If App1 and X1 are both installed already, do nothing (done already) 2) Start our own application MSI installer That is, App1 is not a pre-requisite for the bootstrapper, but if installed its presence requires an additional pre-requisite component to be installed. I would want the bootstrapper to use a registry search to detect if application App1 is installed and if so install the matching pre-requisite. 1) dotNetInstaller I've checked out the dotNetInstaller, which looks interesting. It seems to be able to do everything we need, except for the above requirement. dotNetInstaller has the InstalledCheck element, but can it be used for this scenario? It seems to only support checking for the presence of the very same component that is about to be installed. I can't see a way to link a component to be conditionally installed based on the presence of another component. Is there a way to make this work w dotNetInstaller? 2) Other bootstrapper options Can Burn or .NET FW bootstrapper handle this scenario? Some other alternative? By the way, I know Burn is put on hold until 3.0 ships, but what is the current status of Burn as it exists now? Ps. App1 is Excel v Xxxx and X1 is matching PIA v Xxxx. /Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Ram size checking
I want to check Ram size before i start actual installation same as free disk space checking. Check out launch conditions. Like this Condition Message=Installing $(var.ApplicationFullName) requires at least 512 Mb primary memory. PhysicalMemory = 512 /Condition -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper selection questions -Specificscenario requirements
Good stuff, thanks again. Only one thing I still haven't figured out from your answer. Guess my description was a bit fuzzy on that bit. We have an application DLL that is our code, which comes in three different flavors (one for each Office-version we support). This is necessary because it has to reference the corresponding Excel-assembly. If the user has some Excel version installed, the correct version of this app interop assembly is installed as a part of the normal app MSI install. However, to support req 7 that assembly would have to be installed separately on demand after the application has been installed, and after the user has installed Excel (just installing PIA afterwards would not be enough to make app excel-interop go). Q: This gives us two scenarios for installing a version of that app DLL, do I have to have two different MSIs? Or worded in another way, is there a way to include a sub-MSI component (factored step to install the app interop assembly matching excel) in the main app MSI. This way, there is no code and/or component duplication to maintain. That sub-component MSI could be stored on the user's disk available to be installed on demand later. Does this make sense? Scenario1 = App install including sub component install w app DLL Scenario2 = App install, then later sub component install of app DLL If so, does that also allow for the sub component MSI to be automatically removed when the app is uninstalled, even if it was added on demand? (want win installer to understand that the app DLL is part of the app to be uninstalled, even though it was installed later my first thought was that RemoveFile is probably inappropriate for an app assembly?) I'm not sure I understand your relationship with the users of the app. Who is going to run your installer? The partners? Or are the partners giving the installer to end users, and the partner relies on you, the author, to provide appropriate partner-specific defaults? Both. I think you have understood it correctly. The partner's personnel use the app professionally and they do this today. That is no big deal since they have their own IT-ppl in case of any issues. The scenarios I described are intended to support partner's distributing the app to end home users, who are clients of those partners (think top end stock market clients). When those customers are using the app they should basically be experiencing that they are connecting to the partner, and technically they will in most cases. To make all this as no-hassle as possible (big fish can make big splashes), partners will want our team to provide those defaults, or rather have a process in place to produce all relevant installer files etc customized for their needs given those property values. All they want to do is to distribute one installer file to their clients and everything should work. /Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper selection questions-Specificscenario requirements
Good ideas. In our WiX app installation I already detect Excel-version like this: Property Id=EXCELVERS !-- value is Excel.Application.X where X is either 10, 11 or 12 for 2002, 2003 and 2007 respectively -- RegistrySearch Id=ExcelRegistry Type=raw Root=HKCR Key=Excel.Application\CurVer / /Property ...and then install the corresponding Excel-interop assemblies using conditional hidden feature elements: Feature Id=ExcelIntegration2002 Level=0 Title=Excel integration Description=ExcelRTD2002 integration Display=hidden ComponentRef Id=ExcelRTD2002 / ?if $(var.Configuration) = Release? ComponentRef Id=ExcelRTDShim2002/ ?endif? Condition Level=1EXCELVERS = Excel.Application.10/Condition /Feature ...etc So you are saying just re-launching our MSI in repair mode would pick up the change and install on only that feature? In that case my question about uninstall would be a non issue. I'll look into repair mode more, we have not found a reason to use/support that yet. Maybe now we do, thanks. I love the internet ;) /Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper selection questions -Specificscenario requirements
Are you certain you want hard references to Excel's primary interop assemblies (PIA)? Generally, you only reference the PIA during development. Once development is complete you should remove the PIA reference and change the type of the Excel application class to 'object'. Yeah I know what you mean if all we do is export static data to excel, but we do more than that. In our case we build an excel workbook with text references that excel resolves by creating a data subscription to our application that is updated in real time. This is done by having excel host some of our .NET FW interop code through a shim dll, which when activated creates a remoting cross process channel to our real time data subscription layer in our application process. For this to work in retail mode, the dll that hosts our code in the Excel process space needs to be installed into the GAC and be binary compatible with the current Excel version, since it is Excel that calls into our app through that assembly as the cell reference is resolved. This allows us to setup cells that update in real time push style from the server using native excel mechanisms with all the bells and whistles that comes w that (live updating spread sheet objects, and whatnot). But thanks for the heads up! /Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bootstrapper selection questions - Specific scenario requirements
I've read up a bit on bootstrappers, but can't figure out yet which path to take on this. - We got an application MSI built using WiX 3, works great - Application uses Office PIA* to integrate real time with Excel (data update, app-excel) - Depending on the Excel version, our app MSI installs a different version of app DLL for excel-integration (refs matching PIA assembly version) Now we want to streamline pre-requisite installation since distribution through partners to private end users (ie day traders, etc) is expected to expand (previously, pro financial institutions w their own IT-departments was dominant customer segment). Primary Scenario Requirements 1 - Bootstrapper should detect pre-requisites, inform user when missing and install on demand if allowed. 1.1 - Detect OS, download and install required service pack X for this OS as needed 1.2 - If .NET FW 2.0 SP1 is missing, download and install 1.3.1 - Detect Excel version, download and install corresponding PIA version. 1.3.2 - If no Excel, skip PIA install (see 7 below). 1.4 - Install app MSI 2 - Bootstrapper and app MSI should be one single downloadable file (exe/msi or equiv, not zip). 3 - Some app MSI properties should be pre-set w different values based on partner (server url, etc) 4 - Works painless in a modern CI environment (rel paths, text source format, build script friendly, etc) 5 - Seamless and painless full uninstall no matter what (local copy of all necessary MSIs, etc) 6 - Bootstrapper supports all modern Windows platforms: XP, Win Server , Vista, Win7, etc Note that we have different pre-reqs app install depending on which Excel-version the user has installed, if any. Secondary Scenario Requirement 7 - User did not have Excel installed during app installation, but installs it afterwards. On starting application, detect Excel version and launch installation of the correct PIA version on demand. This includes installing matching version of app interop assemblies. That is, no need for user to re-install the whole application from scratch to enable Excel-integration. Uninstall req 5 still applies. Questions A - Is there a bootstrapper supporting these reqs out there today, or do we have to wait for Burn? B - How would you modularize the app/installation/build to support 3 and 7 specifically? * PIA = Ms Office Primary Interop Assemblies, it's a different installer package based on Office version. /Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper selection questions - Specificscenario requirements
Thanks for the good feedback Don! My questions and comments inline, Removal: It sounds like you are asking the removal of your app to remove the prerequisites that the bootstrapper installed. Bootstrappers are not designed to do this because it is a bad idea. Other programs may need these prerequisites, including the PIA assemblies. I did not mean uninstall would uninstall OS SPs or the framework, I agree that would not be a good idea. I just want uninstall to remove all application components (ie exe+interop dll), regardless if those components where installed at first install (primary scenario) or in a second module install according to the secondary scenario. You could provide separate downloads for each installation. In this case, your build process would build separate MSIs and would generate a separate bootstrapper EXE for each partner. If at all possible, I would really want to keep the integrity of one app MSI, so professional organizations would use this same app MSI but without the bootstrapper. This would reduce the corp confusion and team maintenance pain of having multiple app MSIs. A second alternative is to include customization dialogs as part of the MSI that set properties based on the selected partners. This is what I want to do, but there might not have to be any dialogs. For a partner distribution these MSI properties should be filled in with partner specific values at some point (not by end user who has no clue, see below). During installation, these MSI properties are written to app.config (or similar). Pro customers can use msiexec to set these properties at will, or accept the default property values. My question for this scenario is rather my options in how to apply and set these properties and when. Would I have to apply a transform (?) or set them in some other way before the bootstrapper executes? If transform, can this be applied after building the boostrapper, or does it have to be before (CI/build issue). Or, maybe the bootstrapper itself can include the property values in play so all we have to have per partner is a different bootstrap exe (and the app MSI in distributed format can be identical for all customers and partners while avoiding transforms altogether)? As you can see, my knowledge of Windows Installer technology is a bit fuzzy on the whole transform thing and how to best combine it with what a bootstrapper can do in terms of customization and what it can carry in terms of usable payload. The third alternative is to design this partner-specific customization into the app itself, post-installation. There will of course have to be some new code in the app that knows what to do with these property values, which mostly has to do with how to connect to which servers and create user configuration information the first time the app starts. This is why some information must be provided before install time. The whole idea is for the customer to not have to fill in that fragile mumbo jumbo information manually. And in doing so get the user up and running as fast as possible by magic, while reducing customer service issues (due to fat fingers, confusion and whatnot). Post-installation execution of Excel: The bootstrapper cannot really handle this automatically because the bootstrapper does not run again after the app is installed. In fact, the user may have deleted the installation EXE once your app is installed. Your app should detect the missing PIA scenario and initiate the PIA installation. Yeah, the app would of course have to have some code to shell to msiexec or just ask the user to install it and restart. The bootstrapper, at most, would put some sort of installation module/MSI-thingy on disk containing only the PIA packages and corresponding app DLLs based on Excel-version (or the URL to that thingy in app.config). My confusion here is not so much how a bootstrapper fits into this (or rather not) but more about what would be *best practice* for this kind of post install, extra MSI-module install scenario that does not fragment the main installation scenario into a big mess of sub-MSI-packages per Office version?? Here, I fall a little short in my knowledge about merge modules (?), how to combine pieces of one installation into another, etc. Any pointers would be appreciated. I might also suggest not trying to bootstrap OS service packs Ok, seems reasonable. Thanks, we'll follow that advice. Your users should know how to uninstall a program. Yes, you would think. I agree...! ;) Again, I appreciate the quality response Don. /Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day
Re: [WiX-users] Newbie questions
I'm totally newbie about WIX. I've just downloaded the last v3 version (3.0.2925.0) and I'm playing around with it. That's a pretty old release, you get the latest drop here: http://wix.sourceforge.net/releases/ Moreover, if i try to define any other Culture in the Light setttings (for instance es-ES) I'm getting about 500 light errors! . Is there any hint or sample to be able to make a multi-language installer using v3? You are probably not linking in the file with the localized Spanish strings. - I'm not sure to understand how adverstised and unadvertised shortcuts work and are defined in WIX. My idea was to made the installation visible to all the users in a computer (not just the one that executes the installer), so what kind of shortcut should I use? You have to install the application 'per machine' and not 'per user' to achieve what you want. You do this by setting the ALLUSERS property to 1 or to use the [EMAIL PROTECTED] attribute and set it to perMachine. About shortcuts, start by checking out the Shortcut http://www.wixwiki.com/index.php?title=Shortcut_Element element (Advertise attrib specifically). /Mathias - 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] Create EXE wrapper around my MSI?
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2926168SiteID=1 the SDK people surely are not the dumbest programmers around but what does it help. You can be smart as no-one else, you' get outperformed by the resourcefullness MSI Developers. They are that smart that they even can not follow there smartness over time ... ;-( Friedrich, Man, you need to lighten up! Geez, people are trying to be polite and helpful to you on this list and all you do is lash back at them every time. Your posts are just reeking from pent up negative energy that you are venting onto others. You need to ask yourself where all that stuff is coming from? Fix that. Do not identify with negativity, don't even allow it into your mind, it is toxic. YOU are in control of that, nobody else. The Power of Now, by Eckhart Tolle. Just read it. Seriously... /Mathias - 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] Installer options
1. How do I make a feature mandatory? 2. How can I have a default of don't install? Check out the Feature element, specifically the Absent and Level attributes. http://www.wixwiki.com/index.php?title=Feature_Element /Mathias - 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] service fail to install due to networkServiceaccount
Try this: Account=NT AUTHORITY\NetworkService Complete example that works on my machine (tm): ServiceInstall Id=ServiceEXE Name=$(var.ApplicationFullName) DisplayName=$(var.ApplicationFullName) Type=ownProcess Interactive=no Start=auto Account=NT AUTHORITY\NetworkService Vital=yes ErrorControl=normal/ ServiceControl Id=ServiceEXE Name=$(var.ApplicationFullName) Start=install Stop=both Remove=uninstall Wait=yes/ If you need to set additional disk access permissions, check out util:PermissionEx ... /Mathias From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Perlman Sent: den 28 maj 2008 05:08 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] service fail to install due to networkServiceaccount To All, So when I attempted to do this in my service install element I am still getting the Failed because of required permissions. Would it be possible to see a complete snippet of this being used? My ServiceInstall Element is nested under a Component element with a File element whose keypath is set to yes. If I take out the Account attribute all is fine and the service is installed as 'Local System', if I leave the Account and Password attributes and use a created Service Account all is good and the service is installed. All of these configurations for 'Network Service' have failed though: ServiceInstall Id=MyServiceInstall Name=MyService Description=My Description DisplayName=Transaction Service Host Interactive=no Account=[ComputerName]\Network Service Vital=yes ErrorControl=normal Start=auto Type=ownProcess / ServiceControl Id=MyServiceControl Name=MyService Remove=uninstall Stop=both Wait=yes / ServiceInstall Id=MyServiceInstall Name=MyService Description=My Description DisplayName=Transaction Service Host Interactive=no Account=[ComputerName]\NetworkService Vital=yes ErrorControl=normal Start=auto Type=ownProcess / ServiceControl Id=MyServiceControl Name=MyService Remove=uninstall Stop=both Wait=yes / ServiceInstall Id=MyServiceInstall Name=MyService Description=My Description DisplayName=Transaction Service Host Interactive=no Account=NetworkService Vital=yes ErrorControl=normal Start=auto Type=ownProcess / ServiceControl Id=MyServiceControl Name=MyService Remove=uninstall Stop=both Wait=yes / Thanks, Ryan Solved. The network service account needs to be specified with its domain. - 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] yep - back to being 100% frustrated
Don't blame the tools as there are plenty of people out there using these tools and making them work seemlessly and quickly on a day to day basis. Well, you can't just disregard the large majority of people who are struggling a lot with this. And you can't disregard the developer perspective, because developers are the people that have to deal with this. Sure, one part of the story is about expectations and the learning curve of installation. Before building an installation package, you expect it to be pretty easy, like a couple of days work. Then when you start doing it you find out that the level of investment necessary to complete a working real world installer is not 10 but maybe 100 times greater than what you expected, or more (yes, for real, I'm not making this up). And we are talking very experienced people here, not rookie devs. Having to invest your time so heavily to get so little tangible result back is a shock to most people. And when all the bumps, twists and turns of the technology are added on top of that learning process there will be frustration. Now, I'm not much for nursing cry baby mentality either. It will get you nowhere. But I do feel that there is a case to be made here about not putting up with things that are overburdening. This is the other part of the story. If the tools can be improved to make installation simpler, why settle for less? Or are installer technology and the tools already as good as they can ever become? No. Identify the stuff that can be made easier with better tools. Reduce some of the burden of that complexity you are referring to and streamline the more common stories to ease the learning curve. That's what should be done. http://john.mcfadyen.spaces.live.com http://john.mcfadyen.spaces.live.com/ Domain lookup of that comes up blank. Do you have another link? I sure could use some info on those undocumented features. /Mathias - 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] references of WIX 3
http://www.wixwiki.com/index.php?title=Main_Page also recommend the latest source at http://wix.sourceforge.net/releases/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Evan Kim Sent: den 13 maj 2008 20:22 To: wix-users@lists.sourceforge.net Subject: [WiX-users] references of WIX 3 Is there any manual or referece about WIX3? I'm using version 2 now because there's tutorial and manual of it but I couldn't find any for WIX3. If anyone knows, please tip me off - 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] To Prevent Install on Windows 2008
Example: Condition Message=Only Vista install supported VersionNT = 600 AND ServicePackLevel = 1/Condition For more, see this link: http://msdn.microsoft.com/en-us/library/aa370556(VS.85).aspx -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anidil Sent: den 13 maj 2008 09:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] To Prevent Install on Windows 2008 I have an MSI that is intended for Only Vista and Vista SP1.Can anybody give me some hints to prevent install on Windows 2008? I have tried the following condition but it doesn't work Condition Message= blah blah WindowsBuild = 6000 OR WindowsBuild = 6001 AND ServicePackLevel = 1/Condition NB: For Windows 2008 and Vista SP1,VersionNT and WindowsBuild numbers are 600 and 6001 respectively -- View this message in context: http://www.nabble.com/To-Prevent-Install-on-Windows-2008-tp17202645p1720 2645.html Sent from the wix-users mailing list archive at Nabble.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 - 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] Managed custom actions in Wix 3
AFAIK, MSI can not call your managed code directly and there is no supported way to easily call into custom actions written in managed code. But you can use InstallUtilLib.dll from the framework directory to host an AppDomain and load+call your managed code custom action. I got the below to work by using dark to reverse engineer what Visual Studio does with it's own setup projects. WARNING - As far as I know this is all undocumented and likely very unsupported stuff. And I might not understand all the implications of what I did here. But it works - no C++ or unmanaged code necessary. :-) !--Binary Id=InstallUtil SourceFile=$(env.FrameworkDir)/$(env.FrameworkVersion)/InstallUtilLib.d ll /-- Binary Id=InstallUtil SourceFile=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727/InstallUtilLib .dll / Binary Id=VSDNETCFG SourceFile=./VSDNETCFG.config / Binary Id=MSVBDPCADLL SourceFile=../../Assemblies/MSVBDPCA.DLL [snip] !-- DIRCA_CheckFX will check for .NET FW, but also, as a side effect, set required MSI properties (AFAIK required for using InstallUtilLib.dll) -- CustomAction Id=DIRCA_CheckFX BinaryKey=MSVBDPCADLL DllEntry=CheckFX / CustomAction Id=CAInstall.install BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=deferred / CustomAction Id=CAInstall.install.SetProperty Property=CAInstall.install Value=/installtype=notransaction /action=install /LogFile= /PS_DEF=[PS_DEF] /PS_ADR=quot;[PS_ADR]quot; /PS_BYP=[PS_BYP] quot;[#ClientEXE]quot; quot;[VSDFxConfigFile]quot; / CustomAction Id=CACommit.commit BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=commit / CustomAction Id=CACommit.commit.SetProperty Property=CACommit.commit Value=/installtype=notransaction /action=commit /LogFile= quot;[#ClientEXE]quot; quot;[VSDFxConfigFile]quot; / [snip] InstallExecuteSequence Custom Action=DIRCA_CheckFX Sequence=1 / Custom Action=CAInstall.install.SetProperty Before=CAInstall.install$Executablegt;2/Custom Custom Action=CAInstall.install Before=CACommit.commit.SetProperty$Executablegt;2/Custom Custom Action=CACommit.commit.SetProperty Before=CACommit.commit$Executablegt;2/Custom Custom Action=CACommit.commit Before=RegisterUser$Executablegt;2/Custom /InstallExecuteSequence As you can see, you have to explicitly pass in all MSI properties used by your custom actions for your code to access them. They are not automatically available. This is an inherit MSI limitation. The quot;[#ClientEXE]quot; param above is a file reference to the custom action assembly. In our case a File Id=ClientEXE ... assembly file in one component of the install package. Note on the dependent files: The VSDNETCFG.config is a .net config file (w. lots of assembly bindingRedirects). You also need MSVBDPCA.DLL. Both these files are embedded in VS setup project MSI-files as a binary stream. Get them by darking an existing VS setup project or e-mail me and I'll send the ones I extracted. PS. If somebody knows a better/recommended way to call managed CAs, please let me know too. /Mathias - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed custom actions in Wix 3
And BTW, this topic is obviously an old beaten horse... http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActio ns-no-support-on-the-way-and-heres.aspx /M From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Holmgren Mathias Sent: den 29 april 2008 14:39 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Managed custom actions in Wix 3 AFAIK, MSI can not call your managed code directly and there is no supported way to easily call into custom actions written in managed code. But you can use InstallUtilLib.dll from the framework directory to host an AppDomain and load+call your managed code custom action. I got the below to work by using dark to reverse engineer what Visual Studio does with it's own setup projects. WARNING - As far as I know this is all undocumented and likely very unsupported stuff. And I might not understand all the implications of what I did here. But it works - no C++ or unmanaged code necessary. :-) !--Binary Id=InstallUtil SourceFile=$(env.FrameworkDir)/$(env.FrameworkVersion)/InstallUtilLib.d ll /-- Binary Id=InstallUtil SourceFile=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727/InstallUtilLib .dll / Binary Id=VSDNETCFG SourceFile=./VSDNETCFG.config / Binary Id=MSVBDPCADLL SourceFile=../../Assemblies/MSVBDPCA.DLL [snip] !-- DIRCA_CheckFX will check for .NET FW, but also, as a side effect, set required MSI properties (AFAIK required for using InstallUtilLib.dll) -- CustomAction Id=DIRCA_CheckFX BinaryKey=MSVBDPCADLL DllEntry=CheckFX / CustomAction Id=CAInstall.install BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=deferred / CustomAction Id=CAInstall.install.SetProperty Property=CAInstall.install Value=/installtype=notransaction /action=install /LogFile= /PS_DEF=[PS_DEF] /PS_ADR=quot;[PS_ADR]quot; /PS_BYP=[PS_BYP] quot;[#ClientEXE]quot; quot;[VSDFxConfigFile]quot; / CustomAction Id=CACommit.commit BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=commit / CustomAction Id=CACommit.commit.SetProperty Property=CACommit.commit Value=/installtype=notransaction /action=commit /LogFile= quot;[#ClientEXE]quot; quot;[VSDFxConfigFile]quot; / [snip] InstallExecuteSequence Custom Action=DIRCA_CheckFX Sequence=1 / Custom Action=CAInstall.install.SetProperty Before=CAInstall.install$Executablegt;2/Custom Custom Action=CAInstall.install Before=CACommit.commit.SetProperty$Executablegt;2/Custom Custom Action=CACommit.commit.SetProperty Before=CACommit.commit$Executablegt;2/Custom Custom Action=CACommit.commit Before=RegisterUser$Executablegt;2/Custom /InstallExecuteSequence As you can see, you have to explicitly pass in all MSI properties used by your custom actions for your code to access them. They are not automatically available. This is an inherit MSI limitation. The quot;[#ClientEXE]quot; param above is a file reference to the custom action assembly. In our case a File Id=ClientEXE ... assembly file in one component of the install package. Note on the dependent files: The VSDNETCFG.config is a .net config file (w. lots of assembly bindingRedirects). You also need MSVBDPCA.DLL. Both these files are embedded in VS setup project MSI-files as a binary stream. Get them by darking an existing VS setup project or e-mail me and I'll send the ones I extracted. PS. If somebody knows a better/recommended way to call managed CAs, please let me know too. /Mathias - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Release 3.0.4014.0 requires MsBuild 3.5?
Replying to my own thread here just for search archives completeness. I just installed 3.0.4025 and this issue is now resolved. Quoting history.txt: Use 2.0 MSBuild tasks instead of 3.5 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Release 3.0.4014.0 requires MsBuild 3.5?
Seems I jumped the gun a little on this one. Issue in 3.0.4025.0: - The first time VS builds my Wix project, all goes well (= improvement over previous drop). - The second time the same VS process builds the same Wix project (without restarting VS) I get the following exception: Error 1 The build was aborted because of an internal failure. Microsoft.Build.Shared.InternalErrorException: Internal MSBuild Error: Project shouldn't be in ProjectManager already. at Microsoft.Build.Shared.ErrorUtilities.ThrowInternalError(Boolean showAssert, String unformattedMessage, Object[] args) at Microsoft.Build.BuildEngine.Engine.BuildProject(Project project, String[] targetNames, IDictionary targetOutputs, BuildSettings buildFlags, Boolean fireProjectStartedFinishedEvents) C:\Source\StingModules\AddinModule\AddinModule.csproj 0 1 SixEdgeSetupWix Seems some in process state (in the MsBuild ProjectManager) remains between builds. I have also gotten this build output error on the second build: Unhandled Exception:The build was aborted because of an unexpected logger failure. Error: The build was aborted because of an unexpected logger failure. As before, I'm using .NET FW 2.0 SP1. /M -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Holmgren Mathias Sent: den 25 april 2008 16:47 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Release 3.0.4014.0 requires MsBuild 3.5? Replying to my own thread here just for search archives completeness. I just installed 3.0.4025 and this issue is now resolved. Quoting history.txt: Use 2.0 MSBuild tasks instead of 3.5 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Release 3.0.4014.0 requires MsBuild 3.5?
I just installed the latest drop of WiX, 3.0.4014.0, and now I get a compile error saying assembly Microsoft.Build.Tasks.v3.5 is required to build. Full error stack: Error 3 The ResolveNonMSBuildProjectOutput task could not be loaded from the assembly Microsoft.Build.Tasks.v3.5, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Could not load file or assembly 'Microsoft.Build.Tasks.v3.5, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the UsingTask declaration is correct, and that the assembly and all its dependencies are available. C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets 680 6 SixEdgeSetupWix Our team are using VS2005 and .NET FW 2.0 SP1. Is version 3.5 of the .NET Framework required to use the latest version of Wix, or is something in my project setup missing? If 3.5 is required, is there a workaround for .NET FW 2.0? PS. I just upgraded from WiX version 3.0.2925.0 where I had no problems with my project setup. /Mathias - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix mailing lists open to public = more spam
I agree, for me this is normal for a mailing list. Join to post. Agree also on reducing the spam in the searchable archives by doing this. No spam filter there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dale Quigg Sent: den 22 april 2008 22:12 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wix mailing lists open to public = more spam I think that having to subscribe to wix-users is a reasonable prerequisite for people wishing to post. Dale -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 22 April 2008 18:29 To: Rob Hamflett; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wix mailing lists open to public = more spam If anyone has any other opinions on this topic, please do make your voice heard. I'm still following this thread and trying to figure out if I should lock non-members out of the list. I'm still very hesitant to do that since it raises the bar for people just starting to get involved with WiX (and we don't need to make anything *harder* smile/). - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j avaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build behavior for WiX projects
I might be the only one, but I was not surprised by the WiX project not building since it is consistent with the behaviour of Visual Studio Setup Projects. Confusing? Yes, but OTOH I had already paid for that confusion before so it was not confusing any more. What is best? Not sure, but I am fine with the explicit build as is. I don't want it to slow me down every time I compile my code. The setup project should only be built on the integration server anyway. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: den 17 april 2008 07:53 To: dB.; Candy Chiang; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Build behavior for WiX projects I basically agree. I understand the desire to avoid having the WiX projects rebuild every time you hit F5, but this behavior is going to be very difficult to puzzle out without searching the wix-users archive. Personally, I would pick only building by default in the Release configuration over this new behavior. Although, building all the time might be okay too... especially if validation didn't take so freaking long (a different battle to tackle) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dB. Sent: Wednesday, April 16, 2008 22:01 To: Candy Chiang; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Build behavior for WiX projects I am a little confused by this change. In my opinion this should behave exactly like any other project in the solution, whether it's written in C++, C# or even LOGO :) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Candy Chiang Sent: Wednesday, April 16, 2008 8:11 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Build behavior for WiX projects In the recent builds, we have changed the build behavior of WiX project so that it only builds by default if it is the only project in the solution. If you have more than one project in a solution, the WiX project will not build automatically. This allows you to skip building the WiX project with no overhead when you make tweaks in your application code until you have all your bits ready to be packaged. This implies that when you build the solution using MSBuild on the command line, the WiX project in the solution (assuming there is more than one project) will not be built. If you want the WiX project to build with the solution, you will need to change the build configuration via the Configuration Manager console in Visual Studio. Alternatively, you may choose to build the .wixproj separately through another process. We want to get a feel from the community how this new build behavior is working out for people. A few things to consider: * How do you like this new build behavior? Is it intuitive and easier to use? * Consider other options and how those might be better: o Make WiX project to always build by default in the solution. o Make WiX project to only build by default in Release configuration but not in Debug configuration. o Others suggestions? Please let us know your thoughts. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problem controlling dialog sequencing with custom dialog
Hello,
This is my first post on this list, tried searching the archive but did
not help.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VERSION INFO - I'm using Wix-3.0.2925.0.msi, Votive3.msi
(Votive-3.0.2015.0.zip) with some intermittent support from
wixedit-0.6.1762.msi.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I've made a custom dialog and I am having problems sequencing it. I want
it to appear after the CustomizableDlg and before the VerifyReadyDlg.
When I try to specify where in the sequence I want my custom dialog I
can't compile my Wix project.
My code:
UI
UIRef Id=WixUI_Mondo /
UIRef Id=WixUI_ErrorProgressText /
Dialog Id=HelloWorldDlg ... [snip] /
InstallUISequence
Show Dialog=HelloWorldDlg Before=VerifyReadyDlg /
/InstallUISequence
/UI
i.e. when I use the code above I get this link exception.
Error LGHT0094: Unresolved reference to symbol
'WixAction:InstallUISequence/VerifyReadyDlg' in section
'Product:{2B13E785-D47A-4D58-9B8D-12153E5F368A}'.
I have added a project reference to WixUIExtension.dll and my linker is
configured to build output for the en-US culture.
If I try After=CustomizeDlg, linking fails just as above.
If I try scheduling my dialog after say MigrateFeatureStates (or
relative WelcomeDlg) instead it compiles, but I seem to have no control
of the dialog order or dialog navigation gets all screwed up.
I have tried a bunch of other random things, including trying to use the
DialogRef element, but nothing seems to work.
What am I missing? I am assuming (hoping) I don't have to roll my own
UIExtension assembly just to do this?
/Mathias
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
