[WiX-users] Best practice for combined 32/64bit installer

2011-07-19 Thread Adam Langley
Hi guys,

We have recently developed a 64-bit version of our Microsoft Office plugin (now 
that 2010 comes in both flavours), and would like to distribute a single 
installer that installs the correct feature, based upon whether the user's 
installation of Office is 32 or 64 bit.
Aside from a bootstrapper that runs the correct MSI, is there some accepted 
practice for achieving this with a single MSI?
I had previously believed that it was [not possible/bad form] to make a 32bit 
installer install 64 bit binaries, and vice versa...

Thanks!

Adam Langley
Senior Developer

--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks  Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WixUICostingPopupOptOut and build 3.5.2325.0

2010-11-28 Thread Adam Langley
I would assume that the error 'is declared more than once' is because the new 
release fixes the bug by including the declaration by default.

Adam Langley
Senior Developer

+64 9 486 9010
+64 21 884400
alang...@winscribe.com
www.winscribe.com



 Please consider the environment before printing this email!

-Original Message-
From: Sharad Patel [mailto:spa...@winscribe.com] 
Sent: Monday, 29 November 2010 4:04 p.m.
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WixUICostingPopupOptOut and build 3.5.2325.0

Hi everyone,

We have been using an old 3.5 beta build (v3.5.2030.0) for a while now
without any big issues. Our projects are mostly in VS2008, VS210 and
build automation is with TFS2010.

For a long time we were suffering from the random Please wait...
dialog issue which was worked around by adding the
'WixUICostingPopupOptOut' property as suggested by Bob Arnson in his
blog (http://www.joyofsetup.com/2010/05/20/its-time-to-experiment/). 

However, after upgrading from v3.5.2030.0 to the escrow release
v3.5.2325.0 we started getting the following error in our builds...

C:\delivery\Dev\wix35_public\src\ext\UIExtension\wixlib\Common.wxs(21):
error LGHT0195: The Windows Installer XML variable
'WixUICostingPopupOptOut' is declared in more than one location.  Please
remove one of the declarations. [C:\Builds\Setup.wixproj]

For now we have commented out the 'WixUICostingPopupOptOut' property and
the error has gone away but I'm not sure if the Please wait... bug is
going to come back now.


Does anyone know if there is an alternate way to opt-out of the costing
dialog that works in the escrow release? Or is that property not
necessary anymore?


Thanks in advance.

Sharad Patel



[Apologies if this message appears twice. I got an error from the mailer

the first time I sent it.]

--
Increase Visibility of Your 3D Game App  Earn a Chance To Win $500!
Tap into the largest installed PC base  get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Increase Visibility of Your 3D Game App  Earn a Chance To Win $500!
Tap into the largest installed PC base  get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Reading Assembly Information

2010-09-27 Thread Adam Langley
This is something that I have actually done a fair bit of recently.
You can use 
AssemblyName name = AssemblyName.Load(string assemblyFile)
to retrieve the strong-name attributes of an assembly. The runtime will
load the DLL temporarily, then release it immediately.
However, I far prefer to go the route of avoiding 'loading' DLLs at all
- STAY AWAY from reflection unless you intend to actually late-bind to
your loaded DLLs.
Reflection has far too many requirements to satisfy, if you only intend
to read some information from the DLL.
Remember, that reflection was designed for EXECUTING MSIL code
dynamically, yes you can read all sorts of data out of the DLL, but in
my opinion it's overkill.

My preferred approach is to treat the DLL as a data document, and read
its meta-data using a library that understands the format of MSIL.

Microsoft has a library for doing just this: Microsoft.Cci
http://ccimetadata.codeplex.com/

Using this library, you can 'read' the DLL into an extremely descriptive
object-model, and obtain any information from it that you desire (even
more information that you can with reflection).

One of the big advantages of this, is that because the DLL is NOT LOADED
FOR BINDING, it doesn't need any of its dependencies (AssemblyName.Load
doesnt either however...), and even more importantly - the DLL can have
been built for a later version of the .net runtime, or different
processor architecture!
So, if your application is .net2, and it is given a .net4 assembly, you
can still read out all the metadata, and present a nice error message
which includes all your assembly-name information, and mention that it
was built for an incompatible version of the .net framework (or however
you want to handle it).

If you use AssemblyName.Load, or Assembly reflection, you will get a
runtime 'BadImageFormatException'...

using Microsoft.Cci is as simple as this:

MetadataReaderHost host1 = new
PeReader.DefaultHost();

var module = host1.LoadUnitFrom(assemblyPath) as
IModule;
// grab the publicKeyToken... but you should
probably check that PublicKeyToken isnt null, as it may not be strongly
named
string publicKeyToken = BitConverter.ToString(new
Listbyte(module.ContainingAssembly.PublicKeyToken).ToArray()).Replace(
-, ).ToLower();
// grab the assembly name
string assemblyName =
module.ContainingAssembly.Name.Value;
// grab the version
Version assemblyVersion =
module.ContainingAssembly.Version;
// grab the culture
string assemblyCulture =
module.ContainingAssembly.Culture;

Note: The MetadataReaderHost used to hold a lock on the assembly until
GC collected these objects, but a recent checkin to Microsoft.Cci has
implemented IDisposable on MetaDataReaderHost which will clean
everything up - nice!

Hope this helps.

Adam Langley
Senior Developer

+64 9 486 9010
+64 21 884400
alang...@winscribe.com
www.winscribe.com

-Original Message-
From: pcristini [mailto:pcrist...@paretoplatform.com] 
Sent: Tuesday, 28 September 2010 9:24 a.m.
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Reading Assembly Information


I'm looking to read information about an assembly (version, culture,
publickey, etc) from an assembly, and store those values in properties
which
will then be added to the application's config file. 

I'm going to be producing elements like this:
Plugin
name=UserManager
assembly=Plugin.Users, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=9d04a1dca2c654ed
class=Plugin.Users.UserManagerPlugin
enabled=true /

Is there any solutions out there for this? I've searched around a bit
but
can't find anything even close to what I'm looking to do.
-- 
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Reading-As
sembly-Information-tp5576754p5576754.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Candle is ignoring preprocessor arguments

2010-06-09 Thread Adam Langley
It's so weird, we have MSBuild message tasks, outputting the environment 
variable, and pre-build events outputting the variable, each correctly 
displaying the value in the build log.
If we place the hard-coded path in the pre-processor args list instead of a 
redirection to the environment var, it works - so yes, the env var is 
evaluating to empty, why would MSBuild NOT tokenize this argument and replace 
env vars? It was working for almost a year

sooo sooo bizarre.

Adam Langley
Senior Developer
+64 9 486 9010
alang...@winscribe.com
www.winscribe.com



 Please consider the environment before printing this email!

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Wednesday, 9 June 2010 3:43 p.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Candle is ignoring preprocessor arguments

The value must be evaluating to blank because it would be failing if the
variable was not defined at all.

On Tue, Jun 8, 2010 at 3:22 PM, Adam Langley alang...@winscribe.com wrote:

 Argh!

 We had a fully functional build server (TFS 2008), creating our installers,
 then on Friday the builds just started turning red.
 The problem seems to be, we pass variables to candle, which defines the
 root folder for all content file locations:

 e.g. (truncated)
 C:\Program Files\Windows Installer XML v3\bin\candle.exe
 -dTasks=D:\TFSBuild\Temp\Product\Installers_v1.0_Trunk\Sources\Tasks\

 This is then used in the source files like this
 File Name=NLog.dll
 Source=$(var.Tasks)\_PublishedWebsites\EmailRelay\bin\NLog.dll Vital=yes
 /

 And we're getting file with path,
 \_PublishedWebsites\EmailRelay\bin\NLog.dll, not found from light.exe.

 I looked at the .obj file generated by candle.exe, and it turns out that
 the Source of the file has failed to embed the value of $(var.Tasks) (it has
 evaluated to empty string), meaning that of course light.exe isnt going to
 be able to find the source files - the problem lies in candle.exe.

 Why would candle.exe just start doing this all of a sudden? We havent
 changed anything in the source files, nor updated our WiX installation.
 We can SEE that candle is being passed the value on the command-line, but
 it just FAILS to put it into Source paths!

 Help!

 Thanks

 Adam Langley
 Senior Developer
 +64 9 486 9010
 alang...@winscribe.com
 www.winscribe.com



  Please consider the environment before printing this email!



 --
 ThinkGeek and WIRED's GeekDad team up for the Ultimate
 GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
 lucky parental unit.  See the prize list and enter to win:
 http://p.sf.net/sfu/thinkgeek-promo
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Candle is ignoring preprocessor arguments

2010-06-08 Thread Adam Langley
Argh!

We had a fully functional build server (TFS 2008), creating our installers, 
then on Friday the builds just started turning red.
The problem seems to be, we pass variables to candle, which defines the root 
folder for all content file locations:

e.g. (truncated)
C:\Program Files\Windows Installer XML v3\bin\candle.exe 
-dTasks=D:\TFSBuild\Temp\Product\Installers_v1.0_Trunk\Sources\Tasks\

This is then used in the source files like this
File Name=NLog.dll 
Source=$(var.Tasks)\_PublishedWebsites\EmailRelay\bin\NLog.dll Vital=yes /

And we're getting file with path, \_PublishedWebsites\EmailRelay\bin\NLog.dll, 
not found from light.exe.

I looked at the .obj file generated by candle.exe, and it turns out that the 
Source of the file has failed to embed the value of $(var.Tasks) (it has 
evaluated to empty string), meaning that of course light.exe isnt going to be 
able to find the source files - the problem lies in candle.exe.

Why would candle.exe just start doing this all of a sudden? We havent changed 
anything in the source files, nor updated our WiX installation.
We can SEE that candle is being passed the value on the command-line, but it 
just FAILS to put it into Source paths!

Help!

Thanks

Adam Langley
Senior Developer
+64 9 486 9010
alang...@winscribe.com
www.winscribe.com



 Please consider the environment before printing this email!


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] managed custom action cannot access target directory

2010-05-05 Thread Adam Langley
I have written a deferred CA which I need to manipulate a file that is
placed in the target-directory, at the end of the install.

 

What is weird is that the path is correctly evaluated in my logging
messages, but when I use the path to open a file, it says FILE NOT
FOUND, even though I KNOW the file is there.

I put in some extra logging, to enumerate the contents of the folder to
prove that the file DOES exist, and I got this surprising result:

 

CustomActionData: 

  APPCONFIGPATH = C:\Program
Files\Company\Client\Client.Windows.exe.config

  SECTIONTOENCRYPT = secureAppSettings

Attempting to load 'C:\Program
Files\Company\Client\Client.Windows.exe.config', to encrypt section
'secureAppSettings'.

Configuration file 'C:\Program
Files\Company\Client\Client.Windows.exe.config' was not found, have you
scheduled the CA to execute after files are installed?

Enumerating files in
'C:\Windows\assembly\GAC_MSIL\Microsoft.Deployment.WindowsInstaller\3.0.
0.0__ce35f76fcda82bad'...

  - Microsoft.Deployment.WindowsInstaller.dll

 

As you can see, I am enumerating my target folder, but as soon as I
start operating on the filesystem (such as Directory.GetFiles()), the
.net runtime resolves all my queries to the GAC path where
Microsoft.Deployment.WindowsInstaller.dll lives!!!

What is up with that? Why am I being sandboxed like this??

 

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] managed custom action cannot access target directory

2010-05-05 Thread Adam Langley
I have written a deferred CA which I need to manipulate a file that is placed 
in the target-directory, at the end of the install.

What is weird is that the path is correctly evaluated in my logging messages, 
but when I use the path to open a file, it says FILE NOT FOUND, even though I 
KNOW the file is there.
I put in some extra logging, to enumerate the contents of the folder to prove 
that the file DOES exist, and I got this surprising result:

CustomActionData: 
  APPCONFIGPATH = C:\Program Files\Company\Client\Client.Windows.exe.config
  SECTIONTOENCRYPT = secureAppSettings
Attempting to load 'C:\Program Files\Company\Client\Client.Windows.exe.config', 
to encrypt section 'secureAppSettings'.
Configuration file 'C:\Program Files\Company\Client\Client.Windows.exe.config' 
was not found, have you scheduled the CA to execute after files are installed?
Enumerating files in 
'C:\Windows\assembly\GAC_MSIL\Microsoft.Deployment.WindowsInstaller\3.0.0.0__ce35f76fcda82bad'...
  - Microsoft.Deployment.WindowsInstaller.dll

As you can see, I am enumerating my target folder, but as soon as I start 
operating on the filesystem (such as Directory.GetFiles()), the .net runtime 
resolves all my queries to the GAC path where 
Microsoft.Deployment.WindowsInstaller.dll lives!!!
What is up with that? Why am I being sandboxed like this??


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] managed custom action cannot access target directory

2010-05-05 Thread Adam Langley
I found the problem. I had to expand my properties (session.Format(string)) 
during my immediate CA, so that the deferred CA gets the actual path values, 
not the path 'tokens'.

Adam Langley

 Please consider the environment before printing this email!

-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com] 
Sent: Thursday, 6 May 2010 3:35 p.m.
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] managed custom action cannot access target directory

I have written a deferred CA which I need to manipulate a file that is placed 
in the target-directory, at the end of the install.

What is weird is that the path is correctly evaluated in my logging messages, 
but when I use the path to open a file, it says FILE NOT FOUND, even though I 
KNOW the file is there.
I put in some extra logging, to enumerate the contents of the folder to prove 
that the file DOES exist, and I got this surprising result:

CustomActionData: 
  APPCONFIGPATH = C:\Program Files\Company\Client\Client.Windows.exe.config
  SECTIONTOENCRYPT = secureAppSettings
Attempting to load 'C:\Program Files\Company\Client\Client.Windows.exe.config', 
to encrypt section 'secureAppSettings'.
Configuration file 'C:\Program Files\Company\Client\Client.Windows.exe.config' 
was not found, have you scheduled the CA to execute after files are installed?
Enumerating files in 
'C:\Windows\assembly\GAC_MSIL\Microsoft.Deployment.WindowsInstaller\3.0.0.0__ce35f76fcda82bad'...
  - Microsoft.Deployment.WindowsInstaller.dll

As you can see, I am enumerating my target folder, but as soon as I start 
operating on the filesystem (such as Directory.GetFiles()), the .net runtime 
resolves all my queries to the GAC path where 
Microsoft.Deployment.WindowsInstaller.dll lives!!!
What is up with that? Why am I being sandboxed like this??


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Deploying SSRS reports using Wix Installer.

2010-01-26 Thread Adam Langley
Aha!

Put them in a folder and tell the user to upload them.

Sad, but true.

-Original Message-
From: Sachin Dubey [mailto:sachin.du...@live.com] 
Sent: Wednesday, 27 January 2010 12:29 p.m.
To: Wix Users
Subject: [WiX-users] Deploying SSRS reports using Wix Installer.


Hi All,

 

What is the best way to deploy SSRS reports using WiX 3.0 installer?

 

Thanks

Sachin!
  
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/196390710/direct/01/

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term
contracts
Personal 24x7 support from experience hosting pros just a phone call
away.
http://p.sf.net/sfu/theplanet-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Building Votive

2010-01-06 Thread Adam Langley
I would like to add some functionality to Votive (3.5 codebase), yet I
am finding it rather difficult getting it to build in Visual Studio
2008.
Is the environment setup documented anywhere?

Thanks

Adam Langley


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Building Votive

2010-01-06 Thread Adam Langley
Fantastic, Thanks Neil, I'll check this out.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: Thursday, 7 January 2010 9:38 a.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Building Votive

This documents what you need for 3.0, it might help:
http://neilsleightholm.blogspot.com/2008/10/how-to-create-wix-build-mach
ine.html. 

The other thing to watch is that the last time I checked the CVS source
didn't contain the binary files saved correctly.

Neil

-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com] 
Sent: 06 January 2010 20:25
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Building Votive

I would like to add some functionality to Votive (3.5 codebase), yet I
am finding it rather difficult getting it to build in Visual Studio
2008.
Is the environment setup documented anywhere?

Thanks

Adam Langley



--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
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 Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
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 Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Registry preprocessor instruction uses 64-bit registry

2009-12-02 Thread Adam Langley
I have a wix installer which collects some of its content files from
installed program-files.

 

For example, we use NLog, and the installer collects the DLL from the
NLog install location. 

We minimize configuration by searching the registry for the location
where NLog is installed, then using that value to populate a
preprocessor variable, which is then used in the WiX XML.

 

So, on our wix build properties tab, the 'define preprocessor variables'
textbox looks like this:

NLogInstallationPath=$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.N
ETFramework\v2.0.50727\AssemblyFoldersEx\NLog);

 

Then, the actual WiX Xml looks like this:

File Id=DiagnosticsNLog Name=NLog.dll
Source=$(var.NLogInstallationPath)\NLog.dll Vital=yes /

 

This works really nicely, on a 32-bit machine.

It seems that on a 64-bit machine, even though Visual Studio is running
in 32-bit emulation-mode, the 64-bit hive is being used (I assume
MSBuild is being triggered in a native process, i.e. 64-bit shell), and
under that hive, the key 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\Assembly
FoldersEx does not exist.

instead - one must search the 32-bit sub-tree, which is this location

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50
727\AssemblyFoldersEx

 

To overcome this, I created TWO 'defines', one for 32-bit, and one for
64-bit (one of which will always be empty), then the WiX becomes this:

 

?if $(env.PROCESSOR_ARCHITECTURE) = AMD64 ?

File Id=DiagnosticsNLog Name=NLog.dll
Source=$(var.NLog64InstallationPath)\NLog.dll Vital=yes /

?else?

File Id=DiagnosticsNLog Name=NLog.dll
Source=$(var.NLogInstallationPath)\NLog.dll Vital=yes /

?endif?

 

Is this the correct way to achieve what I want (it does work), or is
there a functionality/syntax that I am unaware of for taking care of
this dilemma?

 

 

Thanks!

 

Adam Langley

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Is it still a bad idea to rename your MSI files?

2009-10-26 Thread Adam Langley
We are currently considering a convention for file-naming, to assist in
tracking our numerous installers, and the many versions thereof.

I recall some time ago being told that renaming an MSI will break some
features - and also read this:

http://blogs.adobe.com/simplicity/2007/05/dont_rename_that_msi.html

 

Is this still the case, and how are other people handling naming in
these situations?

 

Thanks

Adam Langley

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] The ResolveNonMSBuildProjectOutput task was notfound

2009-05-18 Thread Adam Langley
Aha! Just saw this...
Setting the ToolsVersion fixes the first issue, but leaves me with a
bunch of ICE errors, which I've never had before

light.exe(0,0): error LGHT0217: Error executing ICE action 'ICE08'. The
most common cause of this kind of ICE failure is an incorrectly
registered scripting engine. See
http://wix.sourceforge.net/faq.html#Error217 for details and how to
solve this problem. The following string format was not expected by the
external UI message logger: The installer has encountered an unexpected
error installing this package. This may indicate a problem with this
package. The error code is 2738. .
light.exe(0,0): error LGHT0217: Error executing ICE action 'ICE09'. The
most common cause of this kind of ICE failure is an incorrectly
registered scripting engine. See
http://wix.sourceforge.net/faq.html#Error217 for details and how to
solve this problem. The following string format was not expected by the
external UI message logger: The installer has encountered an unexpected
error installing this package. This may indicate a problem with this
package. The error code is 2738. .
light.exe(0,0): error LGHT0217: Error executing ICE action 'ICE32'. The
most common cause of this kind of ICE failure is an incorrectly
registered scripting engine. See
http://wix.sourceforge.net/faq.html#Error217 for details and how to
solve this problem. The following string format was not expected by the
external UI message logger: The installer has encountered an unexpected
error installing this package. This may indicate a problem with this
package. The error code is 2738. .
light.exe(0,0): error LGHT0217: Error executing ICE action 'ICE61'. The
most common cause of this kind of ICE failure is an incorrectly
registered scripting engine. See
http://wix.sourceforge.net/faq.html#Error217 for details and how to
solve this problem. The following string format was not expected by the
external UI message logger: The installer has encountered an unexpected
error installing this package. This may indicate a problem with this
package. The error code is 2738. .

Adam Langley
Senior Developer
+64 9 486 9010
alang...@winscribe.com
www.winscribe.com


 Please consider the environment before printing this email!

-Original Message-
From: gree...@cox.net [mailto:gree...@cox.net] 
Sent: Tuesday, 19 May 2009 2:06 a.m.
To: General discussion for Windows Installer XML toolset.
Cc: Bob Arnson
Subject: Re: [WiX-users] The ResolveNonMSBuildProjectOutput task was
notfound

If you want to build the project, manually go in and set the
ToolsVersion attribute to 3.5 of the Project tag in the votive project
(.wixproj) file.   This task is in MSBuild 3.5, not 2.0.

I had the same problem.

I tried to send the same message earlier, but Cox munched my email.  I
hope this is not a second one for the same thread.

Regards,
greenaj

 Bob Arnson b...@joyofsetup.com wrote: 
 David Gardiner wrote:
  At a guess, I'd say it might be related to the changes made for bug
2786736

 
 Agreed. I reopened the bug. Can you attach a /v:diag log of a 
 command-line MSBuild run? I suspect MSBuildToolsVersion is a value I 
 didn't expect.
 
 -- 
 sig://boB
 http://joyofsetup.com/
 
 
 


--
 Crystal Reports - New Free Runtime and 30 Day Trial
 Check out the new simplified licensing option that enables 
 unlimited royalty-free distribution of the report engine 
 for externally facing server and web deployment. 
 http://p.sf.net/sfu/businessobjects
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] The ResolveNonMSBuildProjectOutput task was not found

2009-05-18 Thread Adam Langley
Hi All,

Just today all of my wix projects started failing to build. I am not
aware of any new installation which could have affected this.
I have re-installed VS AND WiX, and still the problem remains.

C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(789,5): error
MSB4036: The ResolveNonMSBuildProjectOutput task was not found. Check
the following: 1.) The name of the task in the project file is the same
as the name of the task class. 2.) The task class is public and
implements the Microsoft.Build.Framework.ITask interface. 3.) The task
is correctly declared with UsingTask in the project file, or in the
*.tasks files located in the
c:\Windows\Microsoft.NET\Framework\v2.0.50727 directory.

Does anybody have any clue why this might be happening? It just started
spontaneously, and affects ALL WiX projects that previously built fine
(i.e. it has nothing to do with my WiX, but something underlying, like
in MSBuild).
My GAC contains all the Microsoft.Build.Tasks assemblies that I would
expect it to...

Thanks!!

Adam

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] extracting wix xml from wixlibs

2009-03-31 Thread Adam Langley
Hi,

I am writing a tool to make it easier to create custom WiX dialogs, can someone 
tell me how I would go about extracting the wix dialog files (i.e. 
WelcomeDlg.wxs) from the UI wixlib?
I realise that I could just obtain these files from the source code, but I 
don't want to have to require our team members to extract the source code when 
the WiX binaries are already on the system...

Thanks

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com
 
 


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] votive causing massive pauses in Visual Studio

2009-03-18 Thread Adam Langley
Aha! Absolutely:

WiX/Votive: 3.0.4721.0
Visual Studio 2008 SP1
Windows XP SP3 and Windows Vista SP1

Also, we don't have any C++ projects in the solution - and my machine (Vista 
SP1/VS2008SP2/Wix 4207) doesn't exhibit these problems (they still had the 
problem before they upgraded from this version)...


Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com
 
 


-Original Message-
From: Phil Sayers [mailto:p...@cds-am.net] 
Sent: Thursday, 19 March 2009 1:29 a.m.
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] votive causing massive pauses in Visual Studio

I don't have a solution for you, but I know that the smarter people here
will want to know the versions of the tools you are using.
 
[1]wix/votive
[2]visual studio edition  service pack level.
[3]operating system service pack level.

-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com] 
Sent: Tuesday, March 17, 2009 5:17 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] votive causing massive pauses in Visual Studio

Hi,

We are using WiX in solutions with 15-20 projects, including 4 WiX projects.
On 2 of our machines, one is XP and one is Vista32, Visual Studio hogs 50%
of the CPU for about 4 minutes after startup, then on the Vista machine the
text editor pauses for about a second on every operation (in _any_ file, C#,
Xml etc) such as keypresses and mouse clicks.
Unloading the WiX projects fixes the key-press pause, and uninstalling WiX
(Votive) fixes everything else...

Has anyone else experienced this problem?

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com
 
 




--
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


--
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

--
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] votive causing massive pauses in Visual Studio

2009-03-17 Thread Adam Langley
Hi,

We are using WiX in solutions with 15-20 projects, including 4 WiX projects. On 
2 of our machines, one is XP and one is Vista32, Visual Studio hogs 50% of the 
CPU for about 4 minutes after startup, then on the Vista machine the text 
editor pauses for about a second on every operation (in _any_ file, C#, Xml 
etc) such as keypresses and mouse clicks.
Unloading the WiX projects fixes the key-press pause, and uninstalling WiX 
(Votive) fixes everything else...

Has anyone else experienced this problem?

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com
 
 



--
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] fold not being removed on uninstall: sporadic

2009-03-17 Thread Adam Langley
Hey, Im grasping at staws too, so its all I can ask...
Should this really be a problem if the CA is running in 'check' mode 
(synchronous)?
Also, wouldn't this consistently fail to remove the folder if it were a 
sequencing problem?
I'm not sure if I can put the CA invocation earlier in the 
InstallExecuteSequence...

This is what I have...

CustomAction Id=InstallFFDShow BinaryKey=ffdshow.exe 
ExeCommand=/VERYSILENT /Dir=quot;[INSTALLLOCATION]ffdshow\quot; 
/loadinf=quot;[INSTALLLOCATION]ffdshow.infquot; Execute=deferred 
Impersonate=no HideTarget=no /
CustomAction Id=RollbackInstallFFDShow Property=FFDSHOWROLLBACKPATH 
Execute=rollback  ExeCommand=/VERYSILENT Impersonate=no HideTarget=no /
CustomAction Id=UninstallFFDShow Property=FFDSHOWUNINSTALLPATH 
Execute=deferred  ExeCommand=/VERYSILENT Impersonate=no HideTarget=no /


InstallExecuteSequence
  Custom Action=InstallFFDShow After=InstallFiles![CDATA[ 
$ProductComponent  2 ]]/Custom
  Custom Action=RollbackInstallFFDShow Before=InstallFFDShow1/Custom
  Custom Action=UninstallFFDShow 
Before=RemoveFilesFFDSHOWUNINSTALLPATH AND ![CDATA[ $ProductComponent = 2 
]]/Custom
/InstallExecuteSequence

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com
 
 

-Original Message-
From: Jim Williams [mailto:jimwilliam...@comcast.net] 
Sent: Wednesday, 18 March 2009 10:40 a.m.
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] fold not being removed on uninstall: sporadic

I'm just grasping at straws here, but could it be that in the instances where
the folder doesn't get removed, that the folder was still considered in use
from the process that did the file deletions for the CA, and the folder removal
is attempted before the CA process was completely ended and released the folder.
Can you move your CA earlier in the sequence before RemoveFiles to try and
alleviate the problem?

Jim Williams

-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com] 
Sent: Tuesday, March 17, 2009 1:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] fold not being removed on uninstall: sporadic

Its Synchronous, as it checks the return result...

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 


-Original Message-
From: Jim Williams [mailto:jimwilliam...@comcast.net] 
Sent: Tuesday, 17 March 2009 4:41 p.m.
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] fold not being removed on uninstall: sporadic

Is your custom action synchronous or asynchronous?  If asynchronous, perhaps
your custom action isn't finishing in time before the attempt to delete the
folders is done.

Jim Williams

-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com] 
Sent: Monday, March 16, 2009 7:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] fold not being removed on uninstall: sporadic

I have a WiX generated installer which copies some simple files into a directory
structure under ProgramFiles.
The issue is, _sometimes_ (about 50% of the time), uninstallation fails to
remove these folders - with no errors in the log file.

My WiX looks like this:

  Directory Id=ProgramFilesFolder
Directory Id=CompanyFolder Name=Company Folder
  Directory Id=INSTALLLOCATION Name=Application Folder
Component Id=ProductComponent Guid=GUID

With only files underneath.
The only slightly out of the ordinary thing that I am doing is running an exe
installer as a CA which extracts files within this directory structure aswell -
however there is an equivalent uninstall custom action which removes all these
files before the MSI tries to delete anything from the system.

I end up with an empty folder structure:

C:\Program Files\Company Folder\Application Folder\

Remaining on my system, about 50% of the time.

Can anyone point out why this might be happening?

Thanks

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com
 
 


--
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


--
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

[WiX-users] fold not being removed on uninstall: sporadic

2009-03-16 Thread Adam Langley
I have a WiX generated installer which copies some simple files into a 
directory structure under ProgramFiles.
The issue is, _sometimes_ (about 50% of the time), uninstallation fails to 
remove these folders - with no errors in the log file.

My WiX looks like this:

  Directory Id=ProgramFilesFolder
Directory Id=CompanyFolder Name=Company Folder
  Directory Id=INSTALLLOCATION Name=Application Folder
Component Id=ProductComponent Guid=GUID

With only files underneath.
The only slightly out of the ordinary thing that I am doing is running an exe 
installer as a CA which extracts files within this directory structure aswell - 
however there is an equivalent uninstall custom action which removes all these 
files before the MSI tries to delete anything from the system.

I end up with an empty folder structure:

C:\Program Files\Company Folder\Application Folder\

Remaining on my system, about 50% of the time.

Can anyone point out why this might be happening?

Thanks

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com
 
 


--
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] run custom action on rollback from failure to commit

2009-01-15 Thread Adam Langley
Thanks Rob,

I do handle uninstall, but not uninstall-rollback (that will be next on the 
list).

So do I want something like this?

(I assume that you are referring to the installation action as the execution 
action, which in my case is InstallFFDShow)

CustomAction Id=InstallFFDShow BinaryKey=ffdshow.exe 
ExeCommand=/VERYSILENT /loadinf=quot;ffdshow.infquot; Execute=deferred 
Impersonate=no HideTarget=no /
CustomAction Id=RollbackInstallFFDShow Property=FFDSHOWUNINSTALLPATH 
Execute=rollback  ExeCommand=/VERYSILENT Impersonate=no HideTarget=no /
CustomAction Id=UninstallFFDShow Property=FFDSHOWUNINSTALLPATH 
Execute=deferred  ExeCommand=/VERYSILENT Impersonate=no HideTarget=no /

InstallExecuteSequence
  Custom Action=InstallFFDShow After=InstallFiles![CDATA[ 
$ProductComponent  2 ]]/Custom
  Custom Action=RollbackInstallFFDShow Before= InstallFFDShow 
![CDATA[ $ProductComponent  2 ]]/Custom
  Custom Action=UninstallFFDShow 
Before=InstallFinalizeFFDSHOWUNINSTALLPATH AND ![CDATA[ $ProductComponent = 
2 ]]/Custom
/InstallExecuteSequence

My 'condition' for install-rollback is the same as for my install action, I 
assume that is correct, that when an install is rolled back the component still 
has the same install-status (2)?

Thanks

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 


-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Friday, 16 January 2009 5:05 a.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] run custom action on rollback from failure to commit

You need to mark the rollback action @Execute=rollback and make sure it is 
scheduled *before* the execution action.  Also, make sure your condition on 
your rollback action is correct.

Also, do you handle uninstall and uninstall rollback?


-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com]
Sent: Wednesday, January 14, 2009 20:59
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] run custom action on rollback from failure to commit

I have a vustom action which installs some 3rd party tools...

CustomAction Id=InstallFFDShow BinaryKey=ffdshow.exe
ExeCommand=/VERYSILENT /loadinf=quot;ffdshow.infquot;
Execute=deferred Impersonate=no HideTarget=no /
CustomAction Id=UninstallFFDShow Property=FFDSHOWUNINSTALLPATH
Execute=deferred  ExeCommand=/VERYSILENT Impersonate=no
HideTarget=no /

InstallExecuteSequence
  Custom Action=InstallFFDShow After=InstallFiles![CDATA[
$ProductComponent  2 ]]/Custom
  Custom Action=UninstallFFDShow
Before=InstallFinalizeFFDSHOWUNINSTALLPATH AND ![CDATA[
$ProductComponent = 2 ]]/Custom
/InstallExecuteSequence


This works well, on install it runs the ffdshow.exe, and on uninstall it
runs the ffdshow uninstaller (FFDSHOWUNINSTALLPATH is an exe located via
the registry).

My question is:

How do I get the UninstallFFDShow to run during rollback?
Currently, if there is an exception causing a failure to commit (such as
is simulated by the FailInstallFromCommitCustomAction.msm), there is
nothing to run the ffdshow uninstaller.

What do I put in to do this?

I tried adding another Custom tag, which ran After=RemoveFiles, but
this did nothing...

Can anyone give me an example?

Thanks

Adam

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] run custom action on rollback from failure to commit

2009-01-15 Thread Adam Langley
Fantastic! Thant works perfectly, thank you Rob.
I had to hard-code the location of the uninstaller on the target machine, 
however, because it is normally 'discovered' during uninstall:

Property Id=FFDSHOWUNINSTALLER
  RegistrySearch Id=FFDShowRegKey Root=HKLM 
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ffdshow_is1 
Name=InstallLocation Type=raw /
/Property

!--
Find the FFDShow Uninstaller executable on the target system.
This is used to remove 
--
Property Id=FFDSHOWUNINSTALLPATH Secure=yes
  DirectorySearch Id=FFDShowPath Path=[FFDSHOWUNINSTALLER]
FileSearch Name=unins000.exe/
  /DirectorySearch
/Property

This works find during UNINSTALL, but during the install-rollback, this has 
already been evaluated and returned 'empty' because at install, the 
'uninstaller' doesn't yet exist at the searched location.

How, if its possible, can I force the installer to _re-evaluate_ this 
registry-search and directory-search, _before_ the roll-back custom action (or 
at least after 'InstallFiles'), so that the Property FFDSHOWUNINSTALLPATH is 
available for my CA with the correct location of the uninstaller?



Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 


-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Friday, 16 January 2009 9:52 a.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] run custom action on rollback from failure to commit

That looks much closer.  Your last statement isn't _quite_ correct.  The 
deferred actions (rollback actions are deferred) are scheduled in the first 
pass of the Windows Installer.  That's when the condition is evaluated and 
that's why the rollback action always (almost?) has the same condition as the 
forward action.  The actions are executed during the execution second pass 
and if they weren't scheduled they don't exist.  smile/

-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com] 
Sent: Thursday, January 15, 2009 12:13
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] run custom action on rollback from failure to commit

Thanks Rob,

I do handle uninstall, but not uninstall-rollback (that will be next on the 
list).

So do I want something like this?

(I assume that you are referring to the installation action as the execution 
action, which in my case is InstallFFDShow)

CustomAction Id=InstallFFDShow BinaryKey=ffdshow.exe 
ExeCommand=/VERYSILENT /loadinf=quot;ffdshow.infquot; Execute=deferred 
Impersonate=no HideTarget=no /
CustomAction Id=RollbackInstallFFDShow Property=FFDSHOWUNINSTALLPATH 
Execute=rollback  ExeCommand=/VERYSILENT Impersonate=no HideTarget=no /
CustomAction Id=UninstallFFDShow Property=FFDSHOWUNINSTALLPATH 
Execute=deferred  ExeCommand=/VERYSILENT Impersonate=no HideTarget=no /

InstallExecuteSequence
  Custom Action=InstallFFDShow After=InstallFiles![CDATA[ 
$ProductComponent  2 ]]/Custom
  Custom Action=RollbackInstallFFDShow Before= InstallFFDShow 
![CDATA[ $ProductComponent  2 ]]/Custom
  Custom Action=UninstallFFDShow 
Before=InstallFinalizeFFDSHOWUNINSTALLPATH AND ![CDATA[ $ProductComponent = 
2 ]]/Custom
/InstallExecuteSequence

My 'condition' for install-rollback is the same as for my install action, I 
assume that is correct, that when an install is rolled back the component still 
has the same install-status (2)?

Thanks

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com




-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Friday, 16 January 2009 5:05 a.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] run custom action on rollback from failure to commit

You need to mark the rollback action @Execute=rollback and make sure it is 
scheduled *before* the execution action.  Also, make sure your condition on 
your rollback action is correct.

Also, do you handle uninstall and uninstall rollback?


-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com]
Sent: Wednesday, January 14, 2009 20:59
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] run custom action on rollback from failure to commit

I have a vustom action which installs some 3rd party tools...

CustomAction Id=InstallFFDShow BinaryKey=ffdshow.exe
ExeCommand=/VERYSILENT /loadinf=quot;ffdshow.infquot;
Execute=deferred Impersonate=no HideTarget=no /
CustomAction Id=UninstallFFDShow Property=FFDSHOWUNINSTALLPATH
Execute=deferred  ExeCommand=/VERYSILENT Impersonate=no
HideTarget=no /

InstallExecuteSequence
  Custom Action=InstallFFDShow After=InstallFiles![CDATA[
$ProductComponent  2 ]]/Custom
  Custom Action=UninstallFFDShow
Before=InstallFinalizeFFDSHOWUNINSTALLPATH AND ![CDATA[
$ProductComponent = 2 ]]/Custom
/InstallExecuteSequence


This works well

Re: [WiX-users] run custom action on rollback from failure to commit

2009-01-15 Thread Adam Langley
Thank you Rob, and Richard, that fixed my issues.

Regards,

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 


-Original Message-
From: Richard [mailto:legal...@xmission.com] 
Sent: Friday, 16 January 2009 10:55 a.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] run custom action on rollback from failure to commit


In article 
de33023b477fe44eaa71983f5279f6ce50fc456...@na-exmsg-c102.redmond.corp.microsoft.com,
Rob Mensching rob.mensch...@microsoft.com  writes:

 That looks much closer.  Your last statement isn't _quite_ correct.
 The defe rred actions (rollback actions are deferred) are scheduled
 in the first pass of the Windows Installer.  That's when the condition
 is evaluated and that's wh y the rollback action always (almost?) has
 the same condition as the forward action.  The actions are executed
 during the execution second pass and if the y weren't scheduled they
 don't exist.

When I first started supporting rollback on my custom actions, I
concluded that you *always* want the rollback custom action to have the
same condition as the custom action.  Otherwise, there's a chance you
could get one and not both.  They always go together.

Also, you need to make sure that the rollback custom action is always
sequenced before the custom action it rolls back.  Why?  Because
otherwise, you could have the custom action run without its rollback
action being available.

To enforce this relationship, we adopted a naming convention for
custom actions like VendorXXX and for rollback custom actions
VendorXXXRollback.  Then I wrote an ICE that checked that the
conditions between VendorXXX and VendorXXXRollback were consistent
and that VendorXXXRollback was sequenced before VendorXXX.  (We used a
prefix that represented our company name, but I'm using the generic
text 'Vendor' here, but you get the idea.)
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Custom rollback action needs to fire BEFORE remove files...

2009-01-15 Thread Adam Langley
In the same vein as my previous question...

My installer copies a file onto the target system, which is a windows service, 
however, its a 3rd party exe, and cannot be installed using the typical WiX 
method - it must be executed with /service as an argument.
This works.
However, my rollback custom action is getting fired AFTER the file is removed 
from the system, which is obviously a problem, because the file must be 
executed with /unregserver to clean up after itself.

Why is this happening? This is my WiX

CustomAction Id=RegisterService FileKey=olydvrsv.exe ExeCommand=/Service 
Execute=deferred Impersonate=no /
CustomAction Id=RollbackRegisterService FileKey=olydvrsv.exe 
ExeCommand=/unregserver Execute=rollback Impersonate=no /

Custom Action=RegisterService After=InstallFiles1/Custom
Custom Action=RollbackRegisterService Before=InstallFiles1/Custom

The install logs say:

MSI (s) (B0:D4) [18:22:48:465]: Executing op: 
ActionStart(Name=RollbackRegisterService,,)
MSI (s) (B0:D4) [18:22:48:475]: Executing op: 
CustomActionRollback(Action=RollbackRegisterService,ActionType=3346,Source=C:\Program
 Files\Common Files\olydvrsv.exe,Target=/unregserver,)
MSI (s) (B0:D4) [18:22:48:475]: Note: 1: 1721 2: RollbackRegisterService 3: 
C:\Program Files\Common Files\olydvrsv.exe 4: /unregserver 
MSI (s) (B0:D4) [18:22:48:475]: Note: 1: 2205 2:  3: Error 
MSI (s) (B0:D4) [18:22:48:475]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` 
FROM `Error` WHERE `Error` = 1721 
Info 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: RollbackRegisterService, location: 
C:\Program Files\Common Files\olydvrsv.exe, command: /unregserver

.. which makes sense, because its preceded by this (note the time stamps):

MSI (s) (B0:D4) [18:22:47:434]: Executing op: FileRemove(,FileName=C:\Program 
Files\Common Files\olydvrsv.exe,,)

So, the file is removed BEFORE the rollback custom action is fired - which is 
the wrong way around.

How can I get this the right way around?

Thanks!

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 



--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] run custom action on rollback from failure to commit

2009-01-14 Thread Adam Langley
I have a vustom action which installs some 3rd party tools...

CustomAction Id=InstallFFDShow BinaryKey=ffdshow.exe
ExeCommand=/VERYSILENT /loadinf=quot;ffdshow.infquot;
Execute=deferred Impersonate=no HideTarget=no /
CustomAction Id=UninstallFFDShow Property=FFDSHOWUNINSTALLPATH
Execute=deferred  ExeCommand=/VERYSILENT Impersonate=no
HideTarget=no /

InstallExecuteSequence
  Custom Action=InstallFFDShow After=InstallFiles![CDATA[
$ProductComponent  2 ]]/Custom
  Custom Action=UninstallFFDShow
Before=InstallFinalizeFFDSHOWUNINSTALLPATH AND ![CDATA[
$ProductComponent = 2 ]]/Custom
/InstallExecuteSequence


This works well, on install it runs the ffdshow.exe, and on uninstall it
runs the ffdshow uninstaller (FFDSHOWUNINSTALLPATH is an exe located via
the registry).

My question is:

How do I get the UninstallFFDShow to run during rollback?
Currently, if there is an exception causing a failure to commit (such as
is simulated by the FailInstallFromCommitCustomAction.msm), there is
nothing to run the ffdshow uninstaller.

What do I put in to do this?

I tried adding another Custom tag, which ran After=RemoveFiles, but
this did nothing...

Can anyone give me an example?

Thanks

Adam

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Merge Module doesnt remove all files

2009-01-12 Thread Adam Langley
Hi,

I have created a simple merge module using WiX and have a simple problem. 
Probably an obvious solution as well.

Files that are specified within the TARGETDIR directory are correctly removed 
upon uninstall, however, under that folder I have:

Directory Id=CommonFilesFolder

..which contains some folders and files, these are not being removed upon 
uninstall. Why is that, and how can I get them to be removed (remembering that 
they need to 
Be reference counted so they aren't uninstalled if they already existed)...
This folder is essential because I need to put some shared files into 
c:\program files\common files\ (AKA CommonFilesFolder).

Thanks!

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Merge Module doesnt remove all files

2009-01-12 Thread Adam Langley
Thanks Rob,

Just curious, I couldn't find any documentation on this - in a wix MSI, 
features contain components, and that defines which components are actually 
installed.
In a WiX Merge, there is no concept of a 'feature', so what _is_ included? ALL 
defined components?

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 


-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Tuesday, 13 January 2009 1:52 p.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module doesnt remove all files

Verbose log file should show you the Components being uninstalled.  That's the 
place to start.

-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com] 
Sent: Monday, January 12, 2009 16:21
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Merge Module doesnt remove all files

Hi,

I have created a simple merge module using WiX and have a simple problem. 
Probably an obvious solution as well.

Files that are specified within the TARGETDIR directory are correctly removed 
upon uninstall, however, under that folder I have:

Directory Id=CommonFilesFolder

..which contains some folders and files, these are not being removed upon 
uninstall. Why is that, and how can I get them to be removed (remembering that 
they need to 
Be reference counted so they aren't uninstalled if they already existed)...
This folder is essential because I need to put some shared files into 
c:\program files\common files\ (AKA CommonFilesFolder).

Thanks!

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] creating a merge module which outputs files to a directory passed from the setup project.

2009-01-06 Thread Adam Langley
I have created a merge module which needs to use a directory created by the 
parent installer.

The goal is that the merge module will place its output into a folder of a 
specific ID declared by the parent MSI.
I cannot just use fragments because this merge module needs to be used from 
installshield.

Can someone explain how I can reference (from my merge module wix) a directory 
declared in the parent MSI (which obviously doesn't exist yet, at compile time 
of the msm).

I was hoping something like DirectoryRef was available which deferred its 
resolution until runtime, but that doesn't be the case.

Help, anyone?

Thanks

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
 
 


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Limited User Account, first-run problem

2008-07-09 Thread Adam Langley
Hi guys,

I have a question that will probably have a simple and obvious answer...
I have built a WiX MSI, where registry keys are installed under HKCU,
and the application is installed with the administrator account - it is
required to run under minimal user privileges.
When the 'underprivileged user' starts the application for the first
time - Windows Installer must obviously create the HKCU keys for that
user.
What I don't understand, is that Windows Installer expects to find the
MSI in the same location as when it was originally installed - network
drive, USB memory etc.
This is obviously a problem, when the user does not have access to any
of those resources.

It was my understanding that the MSI is copied to some system folder, so
that Repairs and Changes can be made from Add/Remove programs without
needing the original MSI. Why isn't this copy of the MSI also used for
setting up the new user?

Thanks in advance!

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] optionally removing AppData folders created by application, during uninstall

2008-06-26 Thread Adam Langley
Hi guys,

 

I have been battling with this problem for a while.

I have a .Net application which saves temporary data into
AppData\Roaming\Bookmarks.

This folder should not HAVE to be installed by the MSI as the app will
create it when needed (but I've gotten to the stage of experimentation
where it seems to be easier if it is created by the MSI - the installer
seems to not want to remove folders it didn't create, no matter what I
do).

I want this folder (and all its contents) to be removed at uninstall if
REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that
lets the user selected during uninstall whether or not to delete these
temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the
folder (or its contents), allowing any later installations to pick up
these files...

 

My WiX looks something like this:

 

Property Id=REMOVEBOOKMARKS Value=0/

 

Directory Id=AppDataFolder

Directory Id=MyApp Name=MyApp

  Component Id=RemoveAppData
Guid=8C857E65-5EA2-4b0e-BCDA-334F030B1E4A

ConditionREMOVEBOOKMARKS = 1/Condition

 

RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\1

  RegistryValue Value=MyApp Type=string KeyPath=yes
/

/RegistryKey

 

CreateFolder /

RemoveFolder Id=RemoveAppData On=uninstall /

RemoveFile Id=RemoveAppDataFiles Name=*
On=uninstall/

  /Component

  Directory Id=Bookmarks Name=Bookmarks

Component Id=AddAppDataBookmarks
Guid=3494B400-3193-4226-878C-2A4EB1B86456 Permanent=yes 

  ConditionNOT Installed/Condition

 

  RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3

RegistryValue Value=MyApp Type=string KeyPath=yes
/

  /RegistryKey

 

  

  CreateFolder /

/Component

Component Id=RemoveAppDataBookmarks
Guid=3494B400-3193-4226-878C-2A4EB1B86455

  ConditionInstalled AND REMOVEBOOKMARKS = 1/Condition

 

  RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3

RegistryValue Value=MyApp Type=string KeyPath=yes
/

  /RegistryKey

 

  !--CreateFolder /--

  RemoveFolder Id=RemoveAppDataBookmarks On=uninstall/

  RemoveFile Id=RemoveAppDataBookmarksFiles Name=*
On=uninstall/

/Component

  /Directory

/Directory

  /Directory

 

The Bookrmarks folder is the one I want to stay behind if
REMOVEBOOKMARKS=0.

It seems, no matter what I do, I can't get it to work. If I specify
Permanent on the AddAppDataBookmarks component, the NOTHING will
remove it.

If I DONT specify it, then no matter what I put in the component
conditions, it will ALWAYS be removed...

 

How do I set up this sort of behaviour?

 

Thank you in advance...

 

Adam Langley

Senior Developer

Tel: +64 9 486 9010

-
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] optionally removing AppData folders createdby application, during uninstall

2008-06-26 Thread Adam Langley
Sure. Its pretty simple - just create your dialog, copy WixUI_Mondo (or one of 
the other UI sequences if you want), and insert your button publications...
Compare my XML below with WixUI_Mondo.wxs and you'll see what I've changed (and 
inserted)...

Adam Langley
Senior Developer


Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
  Fragment
UI Id=UI_Mondo
  TextStyle Id=WixUI_Font_Normal FaceName=Tahoma Size=8 /
  TextStyle Id=WixUI_Font_Bigger FaceName=Tahoma Size=12 /
  TextStyle Id=WixUI_Font_Title FaceName=Tahoma Size=9 Bold=yes /

  Property Id=DefaultUIFont Value=WixUI_Font_Normal /
  Property Id=WixUI_Mode Value=Mondo /

  DialogRef Id=ErrorDlg /
  DialogRef Id=FatalError /
  DialogRef Id=FilesInUse /
  DialogRef Id=MsiRMFilesInUse /
  DialogRef Id=PrepareDlg /
  DialogRef Id=ProgressDlg /
  DialogRef Id=ResumeDlg /
  DialogRef Id=UserExit /

  Publish Dialog=ExitDialog Control=Finish Event=EndDialog 
Value=Return Order=9991/Publish

  Publish Dialog=WelcomeDlg Control=Next Event=NewDialog 
Value=LicenseAgreementDlg1/Publish

  Publish Dialog=LicenseAgreementDlg Control=Back Event=NewDialog 
Value=WelcomeDlg1/Publish
  Publish Dialog=LicenseAgreementDlg Control=Next Event=NewDialog 
Value=SetupTypeDlg Order=2LicenseAccepted = 1/Publish

  Publish Dialog=SetupTypeDlg Control=Back Event=NewDialog 
Value=LicenseAgreementDlg1/Publish
  Publish Dialog=SetupTypeDlg Control=TypicalButton Event=NewDialog 
Value=VerifyReadyDlg1/Publish
  Publish Dialog=SetupTypeDlg Control=CustomButton Event=NewDialog 
Value=CustomizeDlg1/Publish
  Publish Dialog=SetupTypeDlg Control=CompleteButton Event=NewDialog 
Value=VerifyReadyDlg1/Publish

  Publish Dialog=CustomizeDlg Control=Back Event=NewDialog 
Value=MaintenanceTypeDlg Order=1WixUI_InstallMode = Change/Publish
  Publish Dialog=CustomizeDlg Control=Back Event=NewDialog 
Value=SetupTypeDlg Order=2WixUI_InstallMode = InstallCustom/Publish
  Publish Dialog=CustomizeDlg Control=Next Event=NewDialog 
Value=VerifyReadyDlg1/Publish

  Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog 
Value=CustomizeDlg Order=1WixUI_InstallMode = InstallCustom/Publish
  Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog 
Value=SetupTypeDlg Order=2WixUI_InstallMode = InstallTypical OR 
WixUI_InstallMode = InstallComplete/Publish
  Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog 
Value=CustomizeDlg Order=3WixUI_InstallMode = Change/Publish
  Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog 
Value=RemoveBookmarksDlg Order=4WixUI_InstallMode = Repair OR 
WixUI_InstallMode = Remove/Publish

  Publish Dialog=MaintenanceWelcomeDlg Control=Next Event=NewDialog 
Value=MaintenanceTypeDlg1/Publish

  Publish Dialog=MaintenanceTypeDlg Control=ChangeButton 
Event=NewDialog Value=CustomizeDlg1/Publish
  Publish Dialog=MaintenanceTypeDlg Control=RepairButton 
Event=NewDialog Value=RemoveBookmarksDlg1/Publish
  Publish Dialog=MaintenanceTypeDlg Control=RemoveButton 
Event=NewDialog Value=RemoveBookmarksDlg1/Publish
  Publish Dialog=MaintenanceTypeDlg Control=Back Event=NewDialog 
Value=MaintenanceWelcomeDlg1/Publish

  Publish Dialog=RemoveBookmarksDlg Control=Back Event=NewDialog 
Value=MaintenanceTypeDlg1/Publish
  Publish Dialog=RemoveBookmarksDlg Control=Next Event=NewDialog 
Value=VerifyReadyDlg1/Publish
/UI

UIRef Id=WixUI_Common /
  /Fragment
/Wix 
 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Dunn
Sent: Friday, 27 June 2008 5:14 p.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] optionally removing AppData folders createdby 
application, during uninstall


I second this question.  I am in the same boat.

Adam,
Do you use the WixUI or some custom UI?/Would you be able to post your code for 
the UI on uninstall?

 Date: Fri, 27 Jun 2008 16:10:48 +1200
 From: [EMAIL PROTECTED]
 To: WiX-users@lists.sourceforge.net
 Subject: [WiX-users] optionally removing AppData folders created by   
 application, during uninstall
 
 Hi guys,
 
  
 
 I have been battling with this problem for a while.
 
 I have a .Net application which saves temporary data into
 AppData\Roaming\Bookmarks.
 
 This folder should not HAVE to be installed by the MSI as the app will
 create it when needed (but I've gotten to the stage of experimentation
 where it seems to be easier if it is created by the MSI - the installer
 seems to not want to remove folders it didn't create, no matter what I
 do).
 
 I want this folder (and all its contents) to be removed at uninstall if
 REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that
 lets the user selected during uninstall whether or not to delete these
 temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the
 folder (or its contents

Re: [WiX-users] possible bug

2007-12-12 Thread Adam Langley
Hi Bob,

The only registry entries are as following (*snip*)

Action 13:22:14: InstallInitialize. 
Action start 13:22:14: InstallInitialize.
Action ended 13:22:15: InstallInitialize. Return value 1.
Action 13:22:15: ProcessComponents. Updating component registration
Action start 13:22:15: ProcessComponents.
Action 13:22:15: GenerateScript. Generating script operations for action:
GenerateScript: Updating component registration
Action ended 13:22:15: ProcessComponents. Return value 1.
Action 13:22:15: MsiUnpublishAssemblies. Unpublishing assembly information
Action start 13:22:15: MsiUnpublishAssemblies.
Action ended 13:22:15: MsiUnpublishAssemblies. Return value 1.
Action 13:22:15: UnpublishFeatures. Unpublishing Product Features
Action start 13:22:15: UnpublishFeatures.
Action ended 13:22:15: UnpublishFeatures. Return value 1.
Action 13:22:15: RemoveRegistryValues. Removing system registry values
Action start 13:22:15: RemoveRegistryValues.
Action ended 13:22:15: RemoveRegistryValues. Return value 1.
Action 13:22:15: RemoveFiles. Removing files
Action start 13:22:15: RemoveFiles.
Action ended 13:22:15: RemoveFiles. Return value 0.
Action 13:22:15: InstallFiles. Copying new files
Action start 13:22:15: InstallFiles.
Action ended 13:22:15: InstallFiles. Return value 1.
Action 13:22:15: WriteRegistryValues. Writing system registry values
Action start 13:22:15: WriteRegistryValues.
Action ended 13:22:15: WriteRegistryValues. Return value 1.
Action 13:22:15: RegisterUser. Registering user
Action start 13:22:15: RegisterUser.
Action ended 13:22:15: RegisterUser. Return value 1.
Action 13:22:15: RegisterProduct. Registering product
Action start 13:22:15: RegisterProduct.
RegisterProduct: Registering product
Action ended 13:22:15: RegisterProduct. Return value 1.

And, my MSI is installing a VS Package, so there are several registry
modifications needed, none of which are showing up in the log...

Adam Langley

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

www.seconag.com

From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 12 December 2007 5:43 p.m.
To: Adam Langley
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] possible bug

Adam Langley wrote: 
If I configure the File to place the dll in the GAC (vital/MSIL), because
the file is no longer placed within the enclosing directory, the registry
key is no longer created either.
 
Should this really behave this way? Took me a while to find out what was
going on, and I could only resolve it by either no putting the DLLs in the
GAC, or by putting the registry keys and files in separate Component
elements (of which I did the latter).

Maybe. Does a verbose log show the registry entries at all?

-- 
sig://boB
http://joyofsetup.com/


-
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://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] possible bug

2007-12-11 Thread Adam Langley
Hi guys,

 

I was wondering if the following behaviour is a bug or not (before I posted
it to bug-track)...

 

I have an MSI which places a single DLL on the filesystem, and some registry
keys, both within the same 'directory' element, and within the same
'component' element.

 

Ie (pseudo-xml)

 

Directory

Component

File Source=MyAssembly.dll/

Registry/

/Component

/Directory

 

This works correctly, placing the file on the filesystem, and creating the
registry key.

 

HOWEVER:

If I configure the File to place the dll in the GAC (vital/MSIL), because
the file is no longer placed within the enclosing directory, the registry
key is no longer created either.

 

Should this really behave this way? Took me a while to find out what was
going on, and I could only resolve it by either no putting the DLLs in the
GAC, or by putting the registry keys and files in separate Component
elements (of which I did the latter).

 

Thanks!

 

Adam Langley

 

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

 http://www.seconag.com www.seconag.com

 

-
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] Problem with WiX custom UI

2007-12-10 Thread Adam Langley
Try running the MSI with

msiexec.exe /l* setup.log /i MySetup.msi

Then take a look at the log file, it should give you some clues as to whats
going wrong.

Adam Langley

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

www.seconag.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anidil
Sent: Monday, 10 December 2007 10:02 p.m.
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with WiX custom UI


I'm trying to create a custom UI library customizing installDir sequence,
changing the line 

Property Id=WixUI_InstallDirDlg_Next Value=VerifyReadyDlg /

to Property Id=WixUI_InstallDirDlg_Next Value=ProgressDlg / so that i
can directly get the progress dialog without waiting for the verifyReadyDlg.

But when i run the built MSI, it errors out after the installDirDlg screen
saying that the installer encountered an unexpected error and with error
code 2856.

Any help? can i not drop the verifyreadyDlg?
-- 
View this message in context:
http://www.nabble.com/Problem-with-WiX-custom-UI-tp14249305p14249305.html
Sent from the wix-users mailing list archive at Nabble.com.


-
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


-
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] show progress text for custom action

2007-12-04 Thread Adam Langley
Thanks Stefan,

I tried using that, and the Progress Text in the dialog shows Removing Backup 
Files during the execution of my slow custom action, it never renders my 
text...
Heres what I have:

CustomAction Id='DEVENV_SETUP'
Property='DEVENV8'
ExeCommand='/setup'
Return='check'
Execute='commit'
Impersonate='no'
/

UI
ProgressText Action=DEVENV_SETUPConfiguring Visual 
Studio... (this may take a few minutes)/ProgressText
/UI

InstallExecuteSequence
Custom Action=DEVENV_SETUP After=InstallFiles 
1/Custom
/InstallExecuteSequence

My CA is definitely executing, I can see its process start and chew away at 15% 
CPU for 3-4 minutes, but the progress text just stays on Removing Backup 
Files...

Thanks

 - Adam Langley

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

www.seconag.com

-Original Message-
From: Stefan Pavlik [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 4 December 2007 8:26 p.m.
To: Adam Langley
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] show progress text for custom action

Hi Adam...

You should use the ProgressText element

ProgressText Action=YourCustomActionDescription of the custom
action/ProgressText

Of course you can also use the $(loc.LocalizedDescription) notation
for the description (in conjunction with .wxl files)

Regards

Stefan

Adam Langley wrote:
 Hi guys,
 
  
 
 I have a custom action which calls a batch file during installation, and
 it takes a couple of minutes to execute.
 
 How can I have the progress-text display “Executing real slow batch file
 now...this may take a while.” (or something (c; )?
 
 Is there a declarative way of describing this?
 
  
 
 Thanks
 
  
 
 -  Adam Langley
 
  
 
 Secon NZ Ltd.*
 *A1/400 Rosedale Road
 Albany
 North Shore 0632
 New Zealand
 
 Tel.  +64 (0)9 414 4071
 Fax. +64 (0)9 414 4072
 
 www.seconag.com http://www.seconag.com
 
  
 
 
 
 
 -
 SF.Net email is sponsored by: The Future of Linux Business White Paper
 from Novell.  From the desktop to the data center, Linux is going
 mainstream.  Let it simplify your IT future.
 http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
 
 
 
 
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

-- 
Stefan Pavlik | [EMAIL PROTECTED]
Whitestein Technologies s.r.o. | www.whitestein.com
Panenska 28 | 811 03 Bratislava | Slovak Republic
Main +421 2 5443-5502 | Direct +421 2 5930-0735


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] show progress text for custom action

2007-12-04 Thread Adam Langley
Thanks Daryn, that completely fixed my problem, cheers for the clear
explanation aswell!
Im always stumbling around exactly when I want to execute my custom actions.
Is there a diagram somewhere listing all the install sequence execute events
(InstallInitialize, InstallFinalize, etc etc) - in their executed order,
explaining what they're doing?
Also, if my CA uses Properties, at what point are the properties evaluated
and assigned? For example, if I have a deferred CA, which gets passed the
installation folder, its possible the CA gets queued before the property has
been assigned (I've seen this before trying to use the Quiet Execute
Action)...

Thanks

Regards, Adam Langley

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

www.seconag.com


-Original Message-
From: Daryn Mitchell [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 5 December 2007 11:29 a.m.
To: 'Adam Langley'; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] show progress text for custom action

Adam Langley wrote:
 ...
 the Progress Text in the dialog shows Removing Backup Files 
 during the execution of my slow custom action, it never 
 renders my text
 ...
CustomAction ... Execute='commit' ... /


My guess: You should make your action be deferred instead of commit.

a) Wix ProgressText maps to Windows Installer ActionText table (Wix.chm)

b) Action text is only displayed for actions that run within the
installation script. Therefore, action text is only displayed for actions
that are sequenced between the InstallInitialize and InstallFinalize
actions (Windows Installer docs for ActionText Table)

c) Your action is a Commit CA. Commit custom actions run after
InstallFinalize is finished. (Windows Installer docs for Commit Custom
Actions).

Therefore I figure the progress is not showing because you've made it a
Commit action.

Your symptom may have been useful because it raises the question, why is
your CA a commit action, rather than deferred?
 - The purpose of commit actions is to remove any backup information that
had been created by a custom action. (Installsite,
http://www.installsite.org/pages/en/isnews/200108/index.htm)
 - That's exactly what you saw the WiX UI choose for the progress text
during the commit phase, Removing Backup Files.

So... would it be more appropriate for your CA to be a deferred action
instead? If so, then you'll have solved your progress text too.

Daryn.





-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] show progress text for custom action

2007-12-03 Thread Adam Langley
Hi guys,

 

I have a custom action which calls a batch file during installation, and it
takes a couple of minutes to execute. 

How can I have the progress-text display Executing real slow batch file
now...this may take a while. (or something (c; )?

Is there a declarative way of describing this?

 

Thanks

 

-  Adam Langley

 

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

 http://www.seconag.com www.seconag.com

 

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] special characters in Wix Product Name

2007-11-13 Thread Adam Langley
Hi guys,

 

I am building a Wix package, and my product name has a special character in
it (Latin U with diaeresis – Ü) I have tried both the actual character, and
its entity equivalent (#0220;), but Windows Installer is always unable to
render the character when the package starts up...

 

Untitled.gif

 

Can anyone point out what this is happening? Surely Windows Installer can
render this character?

Thanks

 

-  Adam Langley 

 

 

Ps: sorry about the image – compressed it as much as I could (c;

image001.gif-
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] multiple language inside of a wix MSI

2007-09-27 Thread Adam Langley
Is it possible to have a language dropdown selection as the first page in
the MSI wizard, which changes the locale used for the UI?

I have played with localizing MSIs but this all seems to be auto-detected,
and non-modifiable after the MSI has begun executing.

 

Thanks

 

-  Adam Langley

 

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

 http://www.seconag.com www.seconag.com

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
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] creating INF files

2007-09-10 Thread Adam Langley
Hi Guys,

 

A question with a simple answer I'm sure.

What is the format for creating an INF file to prepopulate the public
properties (theres a mouthful) of an MSI package?

And, does the MSI automatically look for INF files with the same name as the
currently executing MSI? I do I need to start the MSI on the command line
and pass it the INF as an argument.

I just want to set the default property value for different environments by
having several different INF files for a single MSI package.

 

Thanks!

-  Adam Langley

 

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

 http://www.seconag.com www.seconag.com

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
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] Creating a folder with permissions of a new user

2007-09-03 Thread Adam Langley
I am writing an installer where I need to create a folder, and install a
windows service - each to have permissions of a new User that I create
during the install.

However, it appears during the sanity checking period of the install. The
CreateFolder element fails because the user does not yet exist.

Can anyone help?

This is a sample of my XML

 

!-this is outside the component --

util:Group Id=UsersGroup Name=Users /

 

!-this is all inside of the component --

util:User Id=MyUser CreateUser=yes CanNotChangePassword=yes
Name=MyUser Password=myuser RemoveOnUninstall=yes
PasswordNeverExpires=yes Domain=[MachineName] 

  util:GroupRef Id=UsersGroup /

/util:User

 

 

CreateFolder Directory='MYPDFFOLDER'

  Permission User='MyUser' CreateFile='yes' Read='yes'
WriteExtendedAttributes='yes'/

/CreateFolder

 

Thanks!

 

-  Adam Langley

 

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

 http://www.seconag.com www.seconag.com

 

-
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] dependent features

2007-08-30 Thread Adam Langley
I have a deployment project which is deploying 3 websites, and some
assemblies into the GAC.
2 of the websites require the GAC assemblies, 1 does not.
How do I configure these 4 features so that if either (or both) of the 2
websites that needs the GAC feature is chosen for installation, then the UI
forces the user to select the GAC feature aswell? But if only the website
that doesn't need the GAC assemblies is chosen, the GAC feature is allowed
to be disabled.
Is there a standard way to approach this type of 'inter-feature
dependencies'?

Thanks

 - Adam Langley


-
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] automatic uninstallation of previous version

2007-08-01 Thread Adam Langley
Hi guys,

 

Can anyone tell me if there is a simple XML element I can add to my WXS file
to automatically uninstall previous versions of a product, before executing
the install procedure?

I would like the user not to have to go to 'add/remove programs'...

 

Thanks

 

-  Adam

 

Secon NZ Ltd.
A1/400 Rosedale Road
Albany
North Shore 0632
New Zealand

Tel.  +64 (0)9 414 4071
Fax. +64 (0)9 414 4072

 http://www.seconag.com www.seconag.com

 

-
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