Alright, so if I understand things right, I need to capture the
registry entries created by installutil and write them into the Wix
file so that the Windows Installer writes them directly.
How about running mmcperf which is necessary to get the MMC 3.0 API
into the global assembly cache on XP and
You're running at high DPI, 125%. You'll get the same behavior if you
set High DPI on Vista I bet, so the artwork is being scaled up to
compensate. It's a Windows Installer issue, not a WiX issue.
By default it looks like the WiX dialogs have bitmap scaling enabled,
by this logic you could create
Thanks, I've fired a message through requesting the
disclaimer/waiver/whatever it is to sign. I'll provide the missing
translations once it comes through :)
2009/6/26 DEÁK JAHN, Gábor d...@tramontana.co.hu:
On Wed, 24 Jun 2009 18:15:22 +1000, Sascha Beaumont wrote:
Sascha,
localization is
Ok thanks for the reply Sascha. I'll experiment with 125% or 150% larger
artwork and see what happens.
Interesting that my Windows 7 installation for this machine says that a
resolution of 'Medium - 125%' - is the 'default'.
-Original Message-
From: Sascha Beaumont
No luck - the 'scaling down' when you use oversized artwork for the dialog
and banner under Vista at a 'standard' 96 pixels per inch - introduces
horizontal lines or artifacts in the artwork. Looks pretty bad. Attached.
If the screen resolution of 'Medium - 125%' (or 120 pixels per inch) really
Just checked our Windows 7 test server and it has the text size set to 'Smaller
- 100% (default)'.
Rob
Anthony Bouch wrote:
No luck - the 'scaling down' when you use oversized artwork for the dialog
and banner under Vista at a 'standard' 96 pixels per inch - introduces
horizontal lines or
Be aware that this is not just a Windows 7 problem. I run my Windows XP
machine with large fonts set in the control panel's Display Properties
and also see the bitmap stretching. I believe it arises because the
dialog size is based on the font size.
When not using an external UI, we just either
Thanks Rob.
Also understood Peter. I just tested a Vista box - setting the DPI to 120
and running the installer - and sure enough the installer dialog increased
in size (stretching the artwork as well). Just surprised I didn't notice
this earlier since I was using a high DPI setting on my
hi,
I have been using WiX 3.0 for migrating my installlers in Installshield to
WiX.
One thing i am not able to understand is the Difference between *typical*and
*complete* installation.
Can any one please throw some light on this.
Regards,
Akash
Here's the code I used:
Property Id=MMC3
DirectorySearch Id=MMC3Path Path=[SystemFolder] Depth=3
FileSearch Id=MMC3Installed Name=mmc.exe
MinVersion=5.2.3790.3959 /
/DirectorySearch
/Property
If MMC3 has a value, then it's installed.My snap in is optional, so I
just make it
Hi Neil,
Thanks for the suggestion. I did take out the Registryvalue lines and
help the complus: / stuff, then tried it again. I'm still getting
failed to find component errors. I don't understand how to get around
this.
Jim
-Original Message-
From: Neil Sleightholm
It is interesting that the latest Windows Installer release doesn't
handle this better. Especially considering that High DPI support for
apps is highly recommended on Windows XP, Vista, and 7, based on the
latest Windows Application Quality Cookbook from Microsoft
Hello Fellow WiX Users,
I posted an update to my Paraffin tool which generates and update WiX fragments
for your installers. Thanks to everyone who has used it and especially to
everyone who sent feedback. See what's new and fixed here:
Hi
I have the following code to create a IIS application pool. How can I put in
logic says that don't create if it's already exists?
DirectoryRef Id=TARGETDIR
Component Id='SFSAEAppPoolComp'
Guid='B7D1E298-5A98-11DE-937D-1DD455D89593'
Neil, or anyone,
I think I have it working for a few of my DLLs, however I have one more
question. What if the DLL has more than one CLSID?
Do I need to list both of them or just the first one?
Thanks,
Jim
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Thanks, as always, Bob!
I put in the feature request
(https://sourceforge.net/tracker/?func=detailaid=2814132group_id=105970atid=642717).
Using the registry key SOFTWARE\Microsoft\Windows Installer XML\version is
sufficient.
I guess anyone using a Product Id=* really needs to plan a detection
Hi,
I am using the following code to launch my exe. Now, I set
Return=Check, so install shouldn't succeed in case of failure. Well,
the install did succeed, but my exe is not doing what it is supposed
to do. The only problem i can think of is setting CURRENT FOLDER path,
as if I run my exe after
I don't think it has to be complicated. Typical is the feature set that most
users will use all of the time. Complete is everything, all the features.
Without details it's hard to say, but Typical might exclude tutorials, samples,
templates, migration tools etc that aren't need to run the app.
I want to all who gave input to helping me with this most painful thorn
in my side. LOL I finally managed to get my components installed.
Now to dowse my head in some much needed Rogaine. :)
Jim
--
I see you got it working, out of interest what was the answer to this?
Neil
-Original Message-
From: MacDiarmid, James D [mailto:james.macdiar...@eds.com]
Sent: 29 June 2009 18:26
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing VB6 COM+
It was a couple things actually. 1.) I discovered that I wasn't using
the CLSIDs of the DLL for the component in the assembly, and 2) I
changed the path to the dll from an actual path to [#component-id] to
match the actual component/file id.
Now I'm working on how to fill in all the values that
Forgive me for shameless advertising. dotNetInstaller 1.6 has been
released. dotNetInstaller is an open-source, imperfect, but very
feature-rich setup bootstrapper. It might just be what you're looking
for before Burn and might give some good ideas for a more perfect
bootstrapper developed by the
Akash,
Typical and Complete are names of feature sets. A feature set
installs a particular group of components. Each feature set can install
a different set of components (though a component can be used in more
than one feature set if needed). An install always requires at least
one
Is there a way to delete registry value?
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
It appears the ExtractFiles() methods don't work on merge modules. The
methods work fine on an MSI but not merge modules. It appears just by
browsing through the source of the
Microsoft.Deployment.WindowsInstaller.Package assembly that we are trying to
count the number of rows in the Media table
I have read several postings from Rob that the heat website harvester could
possibly be broken? What is the status on that specific portion of heat? I
have been receiving many of the same errors that are on the mailing list.
heat.exe : error HEAT5158 : The web site
Hey Aaron,
Could you share your command line string? This error is of interest to me.
heat.exe : error HEAT0001 : Value cannot be null. Parameter name: argument
Exception Type: System.ArgumentNullException
Thanks,
Brian Rogers
Intelligence removes complexity. - Me
It's a bug (oversight) in the implementation of ExtractFiles(). Can you create
a bug report on SourceForge?
-Original Message-
From: jnewton [mailto:jonathan.new...@ni.com]
Sent: Monday, June 29, 2009 2:46 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ExtractFiles() Method
I posted a thread last week that no one has replied to. I was using
ExtractFiles on an MSI and it doesn't raise an error or extract any files.
http://n2.nabble.com/DTF-ExtractFiles-Problem-td3148972.html
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret
kezhong zhou wrote:
ReserveCost table in a custom action. But I tried a lot of times, found that
I can only 'SELECT' the ReserveCost table at install time, but can not
INSERT or UPDATE the table. :(
You can't permanently update tables in custom actions. You can make
temporary changes.
Quinton Tormanen wrote:
doesn't invoke the PCA when done. However, if I choose to run it
directly from the web (using Run instead of Save), then it mysteriously
runs in the Windows Vista context and DOES invoke the PCA.
Probably depends on how each browser handles the download.
--
John Robbins wrote:
Using the registry key SOFTWARE\Microsoft\Windows Installer XML\version is
sufficient.
Agreed. The right values are probably there, as we did some work to
enable the WiX that was to ship in VS2010 to be swapped out for the
public version.
I guess anyone using a
little.forest wrote:
So that means, if I need to run an executable as asyncNoWait, then I'll
have to use a different kind of customaction? If so, do you know what that
type of customaction is?
See the MSI SDK topic Custom Action Return Processing Options.
--
sig://boB
David Bartmess wrote:
So what can I use to check if the product has already been installed? I
thought Installed was the proper way
It is -- I'm saying WixUI uses it and it works. Try @Hidden=yes.
--
sig://boB
http://joyofsetup.com/
34 matches
Mail list logo
