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
