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:
...
And then use that component ref in the r
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).
HK
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-user
> 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.
> I want to check Ram size before i start actual installation same as
free
> disk space checking.
Check out launch conditions. Like this
PhysicalMemory >= 512
--
Apps built with the Adobe(R) Flex(R) framework and
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
1
> 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 w
Good ideas.
In our WiX app installation I already detect Excel-version like this:
...and then install the corresponding Excel-interop assemblies using
conditional hidden feature elements:
EXCELVERS = "Excel.Application.10"
...etc
So you are saying just re-launching our
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 t
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
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
> 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 (
> 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
---
> http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2926168&SiteID=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
Windows keeps CPU speed information in the registry at the following
key:
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\[core#]\
~MHz
Try searching the registry for the core zero value. I have no experience
setting this up as a launch condition in an installer, but it should be
w
Try this:
Account="NT AUTHORITY\NetworkService"
Complete example that works on my machine (tm):
If you need to set additional disk access permissions, check out
/Mathias
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ryan
Perlman
Sent:
et
Cc: Holmgren Mathias
Subject: Re: [WiX-users] Automatic major upgrade installation of
application
Major upgrades require primarily the following things:
http://msdn.microsoft.com/en-us/library/aa370579(VS.85).aspx
* ProductCode changed
* ProductVersion changed
* UpgradeCode being the same be
> 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
perspecti
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
Example:
VersionNT = 600 AND
ServicePackLevel >= 1
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.s
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
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 wor
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
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
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=
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: wi
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
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.
28 matches
Mail list logo
