[WiX-users] perUser vs perMachine and elevation (best practices?)

[Rune Moberg]

A potential customer informs us that they require installers to be
able to run without elevation.

I see two problems with this approach:
#1: Every user of a given PC will have to install the app separately
#2: ...so my potential "malware" will run no matter what, as long as
one of these users are logged in (i.e.: what is the point of the
requirement?)

(I am probably missing something)

The app in question attempts to share the same printer configuration
among all the users of a given PC. So we store the printer
configuration under %allusersprofile%. The installer will set write
permissions for that folder so that our users can freely modify this.
(not ideal, but the alternative seemed worse)

So, has anyone written a 'best practices' document on this topic? More
specifically I'd like to learn how to transform a perMachine setup
into a perUser setup (setting ALLUSERS="" was not enough).

I just realized I haven't tried to run a perSeat installer as admin
(and set ALLUSERS=1) -- would that be enough to ensure that shortcuts
are made available for all users?

-- 
Rune

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Too many CA:s (LGTH0179)

[Asker Brodersen]

Thanks David, Pally, Chris, for your feedback!

I've decided revert to my old workflow where I generate the required xml-files 
on build and then copy them to the target machine during install. I'll continue 
to harvest heat output manually.  No CA:s nor self-registration involved 
anymore!

P.S.
Pally, uninstalling the application would trigger the CA:s to unregister the 
dlls. I think that would have worked in most cases - but now I don't have to 
find out.
I agree that self-registration should be avoided, but that is actually the 
recommended practice by ESRI Inc. according to the ArcGIS SDK documentation!

/Asker


-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: den 6 april 2011 17:54
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

" the installer doesn't  need to know about the xml files or about COM 
registration of the dlls"

Really? So what happens when the install fails & it has to rollback or the 
super unlikely event that someone wants/needs to uninstall your application (or 
you force an uninstall during a Major Upgrade)?

Microsoft themselves warn very strongly against self reg 
http://msdn.microsoft.com/en-us/library/bb204770.aspx#no_selfreg & 
http://msdn.microsoft.com/en-us/library/aa371608.aspx
as does the WiX tutorial http://www.tramontana.co.hu/wix/lesson6.php#6.1
Hell even Symantec give a good account of why it's a very bad idea 
http://www.symantec.com/connect/blogs/resons-avoiding-self-registration

Also our glorious benefactor Rob Mensching on Custom Actions -> 
http://robmensching.com/blog/posts/2007/8/17/Zataoca-Custom-actions-are-generally-an-admission-of-failure
 which definitely applies here.

Palbinder Sandher
Software Deployment Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the ** Integrated 
Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered 
Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email 
Disclaimer

-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: 06 April 2011 15:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

Self registration is not usually a good idea, feel free to search the list for 
"selfreg is evil" to see many discussions as to why.

You could also use heat in your build process to make sure the components are 
up to date.

If you do want to proceed though I would write a set of CAs that accept a list 
of files to register. You could create a custom table to list the files as 
input to the CAs.


-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se]
Sent: 06 April 2011 13:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

The ESRIRegasm utility being called generates a registration database (xml
file) for a dll as well as calls RegAsm. It's required for extending the ArcGIS 
environment.
Currently I have in place a system where the build msbuild script calls this 
utility so the xml files are generated. These files are then part of the 
installation. This works, but as soon as a public interface is changed in a dll 
I need to remember to manually run heat and update the installer. Adding or 
removing dlls also means adding or removing the corresponding xml file to the 
installer.

Running the ESRIRegasm utility on the dlls after installation takes care of all 
registration, the installer doesn't  need to know about the xml files or about 
COM registration of the dlls,  and the only time I need to revisit the 
installer is when I  want to add or remove a dll. This is what I want to 
accomplish, and it works as long as I don't have too many dlls to fill up the 
available sequence numbers after MsiUnpublishAssemblies. But I do...

/Asker


-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: den 6 april 2011 11:30
To: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

What is special about your registration that means you can't just heat them, 
your code implies it's just regasm?



-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se]
Sent: 06 April 2011 06:41
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Too many CA:s (LGTH0179)

Hi,
During installation/uninstallation we need a special registration of our dll:s. 
This lead to four CA:s being scheduled for each dll:





  $Meldis.Search.dll>2

  $Meldis.Search.dll>2

  $Meldis.Search.dll=2

  $Meldis.Search.dll=2<
/Custom>



But as I have close to a hundred dll:s, this results in the LGHT0179 error for 
MsiUnpublishAssemblies, I presume there simply isn't room in the sequence table 
for all of them.

How do I work around this problem?

Thanks,
Asker

--

Re: [WiX-users] GAC File Update

[Wilson, Phil]

AFAIK all major upgrade element syntax versions allow Schedule to say where you 
want it, "afterInstallExecute" being the one I mentioned below and the 3rd 
bullet here

http://msdn.microsoft.com/en-us/library/aa371197(v=vs.85).aspx which says it 
can be sequenced...

"Between the InstallExecute action, or the InstallExecuteAgain action, and the 
InstallFinalize action. Generally the last three actions are scheduled right 
after one another: InstallExecute, RemoveExistingProducts, and InstallFinalize. 
In this case the updated files are installed first and then the old files are 
removed. However, if the removal of the old application fails, then the 
installer rolls back both the removal of the old application and the install of 
the new application."

Phil Wilson 


-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] 
Sent: Wednesday, April 06, 2011 3:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] GAC File Update

I was also under the impression that FileVersion did *not* contribute to the 
naming attributes for a cached assembly. That is the reason I asked.

Phil, you seem to be suggesting that we can also get good behavior (as it 
relates to assembly versioning/naming) if we schedule RemoveExistingProducts 
just before InstallFinalize. Did I understand you correctly? Where does the 
MajorUpgrade element schedule RemoveExistingProducts?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@invensys.com]
> Sent: Wednesday, April 06, 2011 2:30 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] GAC File Update
> 
> On the rollback point, you still get rollback when RemoveExistingProdcts is
> after InstallFinalize, but probably not the rollback you'd like because it's
> outside of the transacted part of the operation. So the new product installs,
> transaction finishes, then the uninstall of the old product starts. If that 
> fails it
> rolls back too - back to being installed again. Now you have both products
> installed on the system and a big mess on your hands. A better detour is to
> have a sequence InstallExecute, RemoveExistingProducts, InstallFinalize at
> the end because it still does the ref counting "detour" but is inside the
> transaction, so in the event of a failure to uninstall it rolls you back to 
> having
> only the original product on the system.
> 
> The GAC issue is related to assembly identity (its naming attributes) and I
> don't believe file version matters in this particular case (it's not a 
> standard
> naming attribute) and note that the kb article mentions changing
> AssemblyVersion as a detour, not file version. Caveat: I haven't tested
> whether changing File Version solves the problem, I just suspect it may not.
> 
> That bug: Internally, "early" in the install Windows decides that the incoming
> assembly in the new MSI file is "identical" (the naming attributes) to the one
> that's already installed and decides not to install the new one.  It doesn't
> bother to re-evaluate that decision even when RemoveExistingProducts
> removes it. Changing AssemblyVersion makes it different, changing strong
> name should, changing FileVersion "might", dunno. Has that been tested?
> Jacques maybe?
> 
> 
> Phil Wilson
> 
> -Original Message-
> From: Jacques Eloff [mailto:repst...@gmail.com]
> Sent: Wednesday, April 06, 2011 11:40 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] GAC File Update
> 
> The scheduling just depends on whether you want to perform a full
> uninstall/reinstall and whether or not you want rollback support. Scheduling
> after InstallInitialize does a full uninstall without rollback support - but 
> others
> can correct me.
> 
> The important thing is having the file version set. Also, by default, the
> MsiAssembly table won't have the file version information, only the
> assembly version, so you need to invoke light with the -fv switch to add this
> information
> 
> On Wed, Apr 6, 2011 at 10:35 AM, Castro, Edwin G. (Hillsboro) <
> edwin.cas...@fiserv.com> wrote:
> 
> > > Also, take a look at http://support.microsoft.com/kb/905238
> > >
> > > If the assembly version remains the same, but the assembly file
> > > version changes, you will need to schedule RemoveExistingProducts
> > > after InstallIntialize
> >
> > The linked article contradicts the recommendation above to schedule
> > RemoveExistingProducts after InstallInitialize:
> >
> > Use a Windows Installer table-authoring tool to change the sequencing
> > of the RemoveExistingProducts action in the InstallExecuteSequence
> > table to occur after the InstallFinalize action. For example, use the
> > Orca.exe database table editor for creating or ed

Re: [WiX-users] GAC File Update

[Castro, Edwin G. (Hillsboro)]

I was also under the impression that FileVersion did *not* contribute to the 
naming attributes for a cached assembly. That is the reason I asked.

Phil, you seem to be suggesting that we can also get good behavior (as it 
relates to assembly versioning/naming) if we schedule RemoveExistingProducts 
just before InstallFinalize. Did I understand you correctly? Where does the 
MajorUpgrade element schedule RemoveExistingProducts?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@invensys.com]
> Sent: Wednesday, April 06, 2011 2:30 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] GAC File Update
> 
> On the rollback point, you still get rollback when RemoveExistingProdcts is
> after InstallFinalize, but probably not the rollback you'd like because it's
> outside of the transacted part of the operation. So the new product installs,
> transaction finishes, then the uninstall of the old product starts. If that 
> fails it
> rolls back too - back to being installed again. Now you have both products
> installed on the system and a big mess on your hands. A better detour is to
> have a sequence InstallExecute, RemoveExistingProducts, InstallFinalize at
> the end because it still does the ref counting "detour" but is inside the
> transaction, so in the event of a failure to uninstall it rolls you back to 
> having
> only the original product on the system.
> 
> The GAC issue is related to assembly identity (its naming attributes) and I
> don't believe file version matters in this particular case (it's not a 
> standard
> naming attribute) and note that the kb article mentions changing
> AssemblyVersion as a detour, not file version. Caveat: I haven't tested
> whether changing File Version solves the problem, I just suspect it may not.
> 
> That bug: Internally, "early" in the install Windows decides that the incoming
> assembly in the new MSI file is "identical" (the naming attributes) to the one
> that's already installed and decides not to install the new one.  It doesn't
> bother to re-evaluate that decision even when RemoveExistingProducts
> removes it. Changing AssemblyVersion makes it different, changing strong
> name should, changing FileVersion "might", dunno. Has that been tested?
> Jacques maybe?
> 
> 
> Phil Wilson
> 
> -Original Message-
> From: Jacques Eloff [mailto:repst...@gmail.com]
> Sent: Wednesday, April 06, 2011 11:40 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] GAC File Update
> 
> The scheduling just depends on whether you want to perform a full
> uninstall/reinstall and whether or not you want rollback support. Scheduling
> after InstallInitialize does a full uninstall without rollback support - but 
> others
> can correct me.
> 
> The important thing is having the file version set. Also, by default, the
> MsiAssembly table won't have the file version information, only the
> assembly version, so you need to invoke light with the -fv switch to add this
> information
> 
> On Wed, Apr 6, 2011 at 10:35 AM, Castro, Edwin G. (Hillsboro) <
> edwin.cas...@fiserv.com> wrote:
> 
> > > Also, take a look at http://support.microsoft.com/kb/905238
> > >
> > > If the assembly version remains the same, but the assembly file
> > > version changes, you will need to schedule RemoveExistingProducts
> > > after InstallIntialize
> >
> > The linked article contradicts the recommendation above to schedule
> > RemoveExistingProducts after InstallInitialize:
> >
> > Use a Windows Installer table-authoring tool to change the sequencing
> > of the RemoveExistingProducts action in the InstallExecuteSequence
> > table to occur after the InstallFinalize action. For example, use the
> > Orca.exe database table editor for creating or editing Windows Installer
> packages.
> >
> > After reading the article I understand why it recommends scheduling
> > after InstallFinalize. I do not understand why scheduling after
> > InstallInitialize accomplishes the same result. Can somebody explain?
> >
> > Edwin G. Castro
> > Software Developer - Staff
> > Digital Channels
> > Fiserv
> > Office: 503-746-0643
> > Fax: 503-617-0291
> > www.fiserv.com
> > P Please consider the environment before printing this e-mail
> >
> > --
> > 
> >  Xperia(TM) PLAY
> > It's a major breakthrough. An authentic gaming smartphone on the
> > nation's most reliable network.
> > And it wants your games.
> > http://p.sf.net/sfu/verizon-sfdev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> -

Re: [WiX-users] GAC File Update

[Wilson, Phil]

On the rollback point, you still get rollback when RemoveExistingProdcts is 
after InstallFinalize, but probably not the rollback you'd like because it's 
outside of the transacted part of the operation. So the new product installs, 
transaction finishes, then the uninstall of the old product starts. If that 
fails it rolls back too - back to being installed again. Now you have both 
products installed on the system and a big mess on your hands. A better detour 
is to have a sequence InstallExecute, RemoveExistingProducts, InstallFinalize 
at the end because it still does the ref counting "detour" but is inside the 
transaction, so in the event of a failure to uninstall it rolls you back to 
having only the original product on the system. 

The GAC issue is related to assembly identity (its naming attributes) and I 
don't believe file version matters in this particular case (it's not a standard 
naming attribute) and note that the kb article mentions changing 
AssemblyVersion as a detour, not file version. Caveat: I haven't tested whether 
changing File Version solves the problem, I just suspect it may not. 

That bug: Internally, "early" in the install Windows decides that the incoming 
assembly in the new MSI file is "identical" (the naming attributes) to the one 
that's already installed and decides not to install the new one.  It doesn't 
bother to re-evaluate that decision even when RemoveExistingProducts removes 
it. Changing AssemblyVersion makes it different, changing strong name should, 
changing FileVersion "might", dunno. Has that been tested? Jacques maybe? 


Phil Wilson 

-Original Message-
From: Jacques Eloff [mailto:repst...@gmail.com] 
Sent: Wednesday, April 06, 2011 11:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] GAC File Update

The scheduling just depends on whether you want to perform a full
uninstall/reinstall and whether or not you want rollback support. Scheduling
after InstallInitialize does a full uninstall without rollback support - but
others can correct me.

The important thing is having the file version set. Also, by default, the
MsiAssembly table won't have the file version information, only the assembly
version, so you need to invoke light with the -fv switch to add this
information

On Wed, Apr 6, 2011 at 10:35 AM, Castro, Edwin G. (Hillsboro) <
edwin.cas...@fiserv.com> wrote:

> > Also, take a look at http://support.microsoft.com/kb/905238
> >
> > If the assembly version remains the same, but the assembly file version
> > changes, you will need to schedule RemoveExistingProducts after
> > InstallIntialize
>
> The linked article contradicts the recommendation above to schedule
> RemoveExistingProducts after InstallInitialize:
>
> Use a Windows Installer table-authoring tool to change the sequencing of
> the RemoveExistingProducts action in the InstallExecuteSequence table to
> occur after the InstallFinalize action. For example, use the Orca.exe
> database table editor for creating or editing Windows Installer packages.
>
> After reading the article I understand why it recommends scheduling after
> InstallFinalize. I do not understand why scheduling after InstallInitialize
> accomplishes the same result. Can somebody explain?
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> Please consider the environment before printing this e-mail
>
> --
>  Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at 3rd Floor, 40 Grosvenor Pl

Re: [WiX-users] GAC File Update

[CoolBreeze]

Thanks for the responses guys. I'm looking over my setup more and I'll check
out that link.

On Wed, Apr 6, 2011 at 5:51 AM, David Watson  wrote:

> If you are following the major upgrade rules
> (http://wix.sourceforge.net/manual-wix3/major_upgrade.htm) your 1.1.0.0
> dll
> should be upgraded to 1.1.0.1. You should note that the component code of
> this dll should not have changed.  If it's not create a log and see what's
> happening.
>
> As to your need to leave an old dll unchanged I would add a new component
> for
> the 1.2.0.0 and leave the old one in your msi.
>
> Dave
>
>
> -Original Message-
> From: CoolBreeze [mailto:coolbreeze...@googlemail.com]
> Sent: 06 April 2011 02:25
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] GAC File Update
>
> I have the following scenario that I'd like to know if Wix is able to
> handle. I have an assembly called bizobjects.dll with a version of 1.1.0.0
> installed into the GAC, somewhere in configuring my setup I have an issue
> of
> each upgrade to say 1.1.0.1 and so forth is getting installed and 1.1.0.0
> is
> not being replaced with the new version. A second issue is that if I have a
> new version that is now 1.2.0.0, I need to be able to install 1.2.0.0 and
> not have 1.1.0.1 uninstalled, because there are still some applications
> that
> rely on that particular version.
>
> Referring to the first problem, when I have a new version and want it to
> replace the previous version I just give my Setup a new Product ID and
> increment the version number, the Update ID is not being changed, so I
> thought that would uninstall the previous version and replace it with the
> new version.
>
> Can someone please guide me on how to resolve these problems if they are
> resolvable?
>
> Thanks.
>
> -
> -
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> SDL PLC confidential, all rights reserved.
> If you are not the intended recipient of this mail SDL requests and
> requires that you delete it without acting upon or copying any of its
> contents, and we further request that you advise us.
> SDL PLC is a public limited company registered in England and Wales.
>  Registered number: 02675207.
> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
> 7DY, UK.
>
>
>
> --
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] GAC File Update

[Jacques Eloff]

The scheduling just depends on whether you want to perform a full
uninstall/reinstall and whether or not you want rollback support. Scheduling
after InstallInitialize does a full uninstall without rollback support - but
others can correct me.

The important thing is having the file version set. Also, by default, the
MsiAssembly table won't have the file version information, only the assembly
version, so you need to invoke light with the -fv switch to add this
information

On Wed, Apr 6, 2011 at 10:35 AM, Castro, Edwin G. (Hillsboro) <
edwin.cas...@fiserv.com> wrote:

> > Also, take a look at http://support.microsoft.com/kb/905238
> >
> > If the assembly version remains the same, but the assembly file version
> > changes, you will need to schedule RemoveExistingProducts after
> > InstallIntialize
>
> The linked article contradicts the recommendation above to schedule
> RemoveExistingProducts after InstallInitialize:
>
> Use a Windows Installer table-authoring tool to change the sequencing of
> the RemoveExistingProducts action in the InstallExecuteSequence table to
> occur after the InstallFinalize action. For example, use the Orca.exe
> database table editor for creating or editing Windows Installer packages.
>
> After reading the article I understand why it recommends scheduling after
> InstallFinalize. I do not understand why scheduling after InstallInitialize
> accomplishes the same result. Can somebody explain?
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> Please consider the environment before printing this e-mail
>
> --
>  Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users] msi and combo box

[Tobias S]

So if I  understand your requirements correctly you want to have a
combobox just for selecting a language for the license agreement?

That should be possible by adding a combobox e.g. on the first
installation scren and afterwards set a property for the selected
language and use this value for the language of the license agreement.
But to be honest from my point of view I'd recommend to localize the
complete UI and then the license agreement as well. E.g. all the
strings are already included in WiX and you only have to localize
additional ones.

Then build the lanugage transforms and create a bootstrapper to to
select the language. Alternatively you can use the approach to embed
transforms as it is descibed e.g. here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multilanguage-install-td6161866.html

Regards
Tobias


2011/4/6 Thomazeau Michel :
> Hi Guys,
>
>
> I have not found any infomation about using combo box ( the widget where you
> can choose one item in a list ) with WIX.
>
>
> My problem is about dynamic license text localization.
>
>
> I have seen many post about creating multiple msi, one for each languages. I
> have try this, in fact it work fine, all the ui that are produced are well
> localized but this solution does not correspond to my needs, because it
> induce to have one msi for every language (and I want to adress the msi to
> 16 different languages ...).
>
>
> Another problem is that I don't care about the UI button or text
> localization, the only thing I want to be translated is the license text
> that appears in the second or third page of the installer.
>
> And the easiest way to do that, from user point of view, is to have a
> combobox where he can choose his language and that change the license text
> field below.
>
>
>
> Is there any way to do that with WIX?
>
>
> Tanks a lot,
>
>
> M.
> --
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] GAC File Update

[Castro, Edwin G. (Hillsboro)]

> Also, take a look at http://support.microsoft.com/kb/905238
> 
> If the assembly version remains the same, but the assembly file version
> changes, you will need to schedule RemoveExistingProducts after
> InstallIntialize

The linked article contradicts the recommendation above to schedule 
RemoveExistingProducts after InstallInitialize:

Use a Windows Installer table-authoring tool to change the sequencing of the 
RemoveExistingProducts action in the InstallExecuteSequence table to occur 
after the InstallFinalize action. For example, use the Orca.exe database table 
editor for creating or editing Windows Installer packages.

After reading the article I understand why it recommends scheduling after 
InstallFinalize. I do not understand why scheduling after InstallInitialize 
accomplishes the same result. Can somebody explain?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] GAC File Update

[Jacques Eloff]

Also, take a look at http://support.microsoft.com/kb/905238

If the assembly version remains the same, but the assembly file version
changes, you will need to schedule RemoveExistingProducts after
InstallIntialize

Jacques

On Wed, Apr 6, 2011 at 2:51 AM, David Watson  wrote:

> If you are following the major upgrade rules
> (http://wix.sourceforge.net/manual-wix3/major_upgrade.htm) your 1.1.0.0
> dll
> should be upgraded to 1.1.0.1. You should note that the component code of
> this dll should not have changed.  If it's not create a log and see what's
> happening.
>
> As to your need to leave an old dll unchanged I would add a new component
> for
> the 1.2.0.0 and leave the old one in your msi.
>
> Dave
>
>
> -Original Message-
> From: CoolBreeze [mailto:coolbreeze...@googlemail.com]
> Sent: 06 April 2011 02:25
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] GAC File Update
>
> I have the following scenario that I'd like to know if Wix is able to
> handle. I have an assembly called bizobjects.dll with a version of 1.1.0.0
> installed into the GAC, somewhere in configuring my setup I have an issue
> of
> each upgrade to say 1.1.0.1 and so forth is getting installed and 1.1.0.0
> is
> not being replaced with the new version. A second issue is that if I have a
> new version that is now 1.2.0.0, I need to be able to install 1.2.0.0 and
> not have 1.1.0.1 uninstalled, because there are still some applications
> that
> rely on that particular version.
>
> Referring to the first problem, when I have a new version and want it to
> replace the previous version I just give my Setup a new Product ID and
> increment the version number, the Update ID is not being changed, so I
> thought that would uninstall the previous version and replace it with the
> new version.
>
> Can someone please guide me on how to resolve these problems if they are
> resolvable?
>
> Thanks.
>
> -
> -
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> SDL PLC confidential, all rights reserved.
> If you are not the intended recipient of this mail SDL requests and
> requires that you delete it without acting upon or copying any of its
> contents, and we further request that you advise us.
> SDL PLC is a public limited company registered in England and Wales.
>  Registered number: 02675207.
> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
> 7DY, UK.
>
>
>
> --
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Too many CA:s (LGTH0179)

[Christopher Painter]

Amen.   I speak to the horrors of SelfReg.  I can also speak to the pain of 
using Heat to harvest the COM.  That's why I wrote a simple little utility 
called to put a file system watcher on a directory, run heat and display the 
XML 
in an XML editor control.  We then just copy and paste the XML into our real 
WiX, tweak some ID's and move along.

The only real pain we had was people "forgot" that we did that when they 
switched to CLR 4 so we had to go back and change some runtime version 
attributes.

Chris
 
---
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Pally Sandher 
To: General discussion for Windows Installer XML toolset. 

Sent: Wed, April 6, 2011 10:54:27 AM
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

" the installer doesn't  need to know about the xml files or about COM 
registration of the dlls"

Really? So what happens when the install fails & it has to rollback or the 
super 
unlikely event that someone wants/needs to uninstall your application (or you 
force an uninstall during a Major Upgrade)?

Microsoft themselves warn very strongly against self reg 
http://msdn.microsoft.com/en-us/library/bb204770.aspx#no_selfreg & 
http://msdn.microsoft.com/en-us/library/aa371608.aspx
as does the WiX tutorial http://www.tramontana.co.hu/wix/lesson6.php#6.1
Hell even Symantec give a good account of why it's a very bad idea 
http://www.symantec.com/connect/blogs/resons-avoiding-self-registration

Also our glorious benefactor Rob Mensching on Custom Actions -> 
http://robmensching.com/blog/posts/2007/8/17/Zataoca-Custom-actions-are-generally-an-admission-of-failure
 which definitely applies here.

Palbinder Sandher 
Software Deployment Engineer
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer

-Original Message-
From: David Watson [mailto:dwat...@sdl.com] 
Sent: 06 April 2011 15:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

Self registration is not usually a good idea, feel free to search the list
for "selfreg is evil" to see many discussions as to why.

You could also use heat in your build process to make sure the components are
up to date.

If you do want to proceed though I would write a set of CAs that accept a
list of files to register. You could create a custom table to list the files
as input to the CAs.


-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se] 
Sent: 06 April 2011 13:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

The ESRIRegasm utility being called generates a registration database (xml
file) for a dll as well as calls RegAsm. It's required for extending the
ArcGIS environment.
Currently I have in place a system where the build msbuild script calls this
utility so the xml files are generated. These files are then part of the
installation. This works, but as soon as a public interface is changed in a
dll I need to remember to manually run heat and update the installer. Adding
or removing dlls also means adding or removing the corresponding xml file to
the installer.

Running the ESRIRegasm utility on the dlls after installation takes care of
all registration, the installer doesn't  need to know about the xml files or
about COM registration of the dlls,  and the only time I need to revisit the
installer is when I  want to add or remove a dll. This is what I want to
accomplish, and it works as long as I don't have too many dlls to fill up the
available sequence numbers after MsiUnpublishAssemblies. But I do...

/Asker


-Original Message-
From: David Watson [mailto:dwat...@sdl.com] 
Sent: den 6 april 2011 11:30
To: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

What is special about your registration that means you can't just heat them,
your code implies it's just regasm?



-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se]
Sent: 06 April 2011 06:41
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Too many CA:s (LGTH0179)

Hi,
During installation/uninstallation we need a special registration of our
dll:s. This lead to four CA:s being scheduled for each dll:





  $Meldis.Search.dll>2

  $Meldis.Search.dll>2

  $Meldis.Search.dll=2

  $Meldis.Search.dll=2<
/Custom>



But as I have close to a hundred dll:s, this results in the LGHT0179 error
for MsiUnpublishAssemblies, I presume there simply isn't room in the sequence
table for all of them.

How do I work around this problem?

Thanks,
Asker

Re: [WiX-users] Too many CA:s (LGTH0179)

[Pally Sandher]

" the installer doesn't  need to know about the xml files or about COM 
registration of the dlls"

Really? So what happens when the install fails & it has to rollback or the 
super unlikely event that someone wants/needs to uninstall your application (or 
you force an uninstall during a Major Upgrade)?

Microsoft themselves warn very strongly against self reg 
http://msdn.microsoft.com/en-us/library/bb204770.aspx#no_selfreg & 
http://msdn.microsoft.com/en-us/library/aa371608.aspx
as does the WiX tutorial http://www.tramontana.co.hu/wix/lesson6.php#6.1
Hell even Symantec give a good account of why it's a very bad idea 
http://www.symantec.com/connect/blogs/resons-avoiding-self-registration

Also our glorious benefactor Rob Mensching on Custom Actions -> 
http://robmensching.com/blog/posts/2007/8/17/Zataoca-Custom-actions-are-generally-an-admission-of-failure
 which definitely applies here.

Palbinder Sandher 
Software Deployment Engineer
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer

-Original Message-
From: David Watson [mailto:dwat...@sdl.com] 
Sent: 06 April 2011 15:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

Self registration is not usually a good idea, feel free to search the list
for "selfreg is evil" to see many discussions as to why.

You could also use heat in your build process to make sure the components are
up to date.

If you do want to proceed though I would write a set of CAs that accept a
list of files to register. You could create a custom table to list the files
as input to the CAs.


-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se] 
Sent: 06 April 2011 13:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

The ESRIRegasm utility being called generates a registration database (xml
file) for a dll as well as calls RegAsm. It's required for extending the
ArcGIS environment.
Currently I have in place a system where the build msbuild script calls this
utility so the xml files are generated. These files are then part of the
installation. This works, but as soon as a public interface is changed in a
dll I need to remember to manually run heat and update the installer. Adding
or removing dlls also means adding or removing the corresponding xml file to
the installer.

Running the ESRIRegasm utility on the dlls after installation takes care of
all registration, the installer doesn't  need to know about the xml files or
about COM registration of the dlls,  and the only time I need to revisit the
installer is when I  want to add or remove a dll. This is what I want to
accomplish, and it works as long as I don't have too many dlls to fill up the
available sequence numbers after MsiUnpublishAssemblies. But I do...

/Asker


-Original Message-
From: David Watson [mailto:dwat...@sdl.com] 
Sent: den 6 april 2011 11:30
To: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

What is special about your registration that means you can't just heat them,
your code implies it's just regasm?



-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se]
Sent: 06 April 2011 06:41
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Too many CA:s (LGTH0179)

Hi,
During installation/uninstallation we need a special registration of our
dll:s. This lead to four CA:s being scheduled for each dll:





  $Meldis.Search.dll>2

  $Meldis.Search.dll>2

  $Meldis.Search.dll=2

  $Meldis.Search.dll=2<
/Custom>



But as I have close to a hundred dll:s, this results in the LGHT0179 error
for MsiUnpublishAssemblies, I presume there simply isn't room in the sequence
table for all of them.

How do I work around this problem?

Thanks,
Asker

-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming smartphone on the nation's
most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires
that you delete it without acting upon or copying any of its contents, and we
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
7DY, UK.


-
-
Xperia(TM) PLAY
It's a

[WiX-users] [Wix-users] msi and combo box

[Thomazeau Michel]

Hi Guys,


I have not found any infomation about using combo box ( the widget where you
can choose one item in a list ) with WIX.


My problem is about dynamic license text localization.


I have seen many post about creating multiple msi, one for each languages. I
have try this, in fact it work fine, all the ui that are produced are well
localized but this solution does not correspond to my needs, because it
induce to have one msi for every language (and I want to adress the msi to
16 different languages ...).


Another problem is that I don't care about the UI button or text
localization, the only thing I want to be translated is the license text
that appears in the second or third page of the installer.

And the easiest way to do that, from user point of view, is to have a
combobox where he can choose his language and that change the license text
field below.



Is there any way to do that with WIX?


Tanks a lot,


M.
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ICE03 and version number

[Skildum, Mathew]

No you cannot. 

You must use a valid version string for the file versions.  MSI requires this 
to be able to do a version compare when needed.

You can put this information into the Product version file of the file 
assembly, but not into the File Version.

Mat Skildum

-Original Message-
From: Michael Tissington [mailto:michael_tissing...@ciqual.com] 
Sent: Wednesday, April 06, 2011 9:48 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] ICE03 and version number

My understanding is that the 4th position in the version number is not used by 
anything when checking version number.
Upgrade, etc ...

I see some version numbers on products use the 4th position as free formatted.

However when I try to build a package with a number like 1.2.3.123-56-ab-334 I 
get a candle error that it does not conform to n.n.n.n format.

Can I use the version number like this ?

Thanks


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming smartphone on the nation's most 
reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] ICE03 and version number

[Michael Tissington]

My understanding is that the 4th position in the version number is not used
by anything when checking version number.
Upgrade, etc ...

I see some version numbers on products use the 4th position as free
formatted.

However when I try to build a package with a number like 1.2.3.123-56-ab-334
I get a candle error that it does not conform to n.n.n.n format.

Can I use the version number like this ?

Thanks


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Too many CA:s (LGTH0179)

[David Watson]

Self registration is not usually a good idea, feel free to search the list
for "selfreg is evil" to see many discussions as to why.

You could also use heat in your build process to make sure the components are
up to date.

If you do want to proceed though I would write a set of CAs that accept a
list of files to register. You could create a custom table to list the files
as input to the CAs.



-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se] 
Sent: 06 April 2011 13:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

The ESRIRegasm utility being called generates a registration database (xml
file) for a dll as well as calls RegAsm. It's required for extending the
ArcGIS environment.
Currently I have in place a system where the build msbuild script calls this
utility so the xml files are generated. These files are then part of the
installation. This works, but as soon as a public interface is changed in a
dll I need to remember to manually run heat and update the installer. Adding
or removing dlls also means adding or removing the corresponding xml file to
the installer.

Running the ESRIRegasm utility on the dlls after installation takes care of
all registration, the installer doesn't  need to know about the xml files or
about COM registration of the dlls,  and the only time I need to revisit the
installer is when I  want to add or remove a dll. This is what I want to
accomplish, and it works as long as I don't have too many dlls to fill up the
available sequence numbers after MsiUnpublishAssemblies. But I do...

/Asker


-Original Message-
From: David Watson [mailto:dwat...@sdl.com] 
Sent: den 6 april 2011 11:30
To: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

What is special about your registration that means you can't just heat them,
your code implies it's just regasm?



-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se]
Sent: 06 April 2011 06:41
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Too many CA:s (LGTH0179)

Hi,
During installation/uninstallation we need a special registration of our
dll:s. This lead to four CA:s being scheduled for each dll:





  $Meldis.Search.dll>2

  $Meldis.Search.dll>2

  $Meldis.Search.dll=2

  $Meldis.Search.dll=2<
/Custom>



But as I have close to a hundred dll:s, this results in the LGHT0179 error
for MsiUnpublishAssemblies, I presume there simply isn't room in the sequence
table for all of them.

How do I work around this problem?

Thanks,
Asker

-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming smartphone on the nation's
most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires
that you delete it without acting upon or copying any of its contents, and we
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
7DY, UK.


-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming smartphone on the nation's
most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to implement tab control in a Dialog

[Tobias S]

Hmm... MSI still is not able to do so.

The ThmUtil is something completely new in WiX 3.6. I assume it is
used for modelling the Burn Bootstrapper UI ("Schema for describing
Theme files processsed by thmutil" is written in the help). But as it
is very new few information about it and how to use it is available
;-)


2011/4/6 Shal Philipp :
> Up the theme! )
>
> here:
> http://wix.sourceforge.net/releases/3.6.1230.0/history.txt
>
> I have found this string:
> MiCarls: Add ListView & Tab control support to ThmUtil
>
> does it mean that WIX will be able to support implementing tabs into install
> UI? or maybe support already in 3.6.1230.0 version? (nothing in help file of
> 3.6.1230.0 version was found)
>
> --
> View this message in context: 
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-implement-tab-control-in-a-Dialog-tp3291570p6245419.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
> --
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Build a directory structure using foreach?

[Rune Moberg]

On Wed, Apr 6, 2011 at 3:08 PM, Peter Shirtcliffe  wrote:
> Add a generated registry value to each component and set that as the keypath.

Thanks Peter, that did the trick.

-- 
Rune

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Build a directory structure using foreach?

[Peter Shirtcliffe]

Add a generated registry value to each component and set that as the keypath.

-Original Message-
From: Rune Moberg [mailto:jjfl...@gmail.com] 
Sent: 06 April 2011 13:49
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Build a directory structure using foreach?

I would like to set up a directory structure under CommonAppDataFolder
that looks something like this:

OrderImport
  +-  ProviderA
+- Drop
+- History
+- Error
  +- ProviderB
+- Drop
+- History
+- Error

and so on... Not much more than this, but enough that I was very happy
to discover the foreach statement:





  
  


  

  


  
  

  

Which of course fails miserably with an error 39.
"The Component/@Guid attribute's value '*' is not valid for this
component because it does not meet the criteria for having an
automatically generated guid. Components with 0 files cannot use an
automatically generated guid."

I am probably approaching this all wrong.

Suggestions?

-- 
Rune

-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Build a directory structure using foreach?

[Rune Moberg]

I would like to set up a directory structure under CommonAppDataFolder
that looks something like this:

OrderImport
  +-  ProviderA
+- Drop
+- History
+- Error
  +- ProviderB
+- Drop
+- History
+- Error

and so on... Not much more than this, but enough that I was very happy
to discover the foreach statement:





  
  


  

  


  
  

  

Which of course fails miserably with an error 39.
"The Component/@Guid attribute's value '*' is not valid for this
component because it does not meet the criteria for having an
automatically generated guid. Components with 0 files cannot use an
automatically generated guid."

I am probably approaching this all wrong.

Suggestions?

-- 
Rune

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] External UI Samples?

[Matt Siebert]

Thanks Pally, I did look at Sharp Setup earlier today.  From memory it
didn't use DTF (but maybe I'm wrong).  I'm at home now and have just
installed Sharp Setup here but it keeps crashing VS when it generates the
solution.

My current plan is to use Burn from WiX 3.6 to chain .NET and then my
external UI can take over, and I think this will be simpler if I can just
get my head around how I should be using the Installer singleton in my code.

Sharp Setup also seemed fairly complicated when I looked at it earlier.
 Maybe I just didn't take enough time to look at it properly.  I didn't see
any reference to Microsoft.Deployment.WindowsInstaller so I figured it was
using P/Invoke, which isn't too disturbing, but it just seems that using DTF
/ Burn is going to be simpler to maintain.

On Wed, Apr 6, 2011 at 7:24 PM, Pally Sandher wrote:

> Take a look at SharpSetup -> http://sharpsetup.eu/ . It may help point you
> in the right direction.
>
> Palbinder Sandher
> Software Deployment Engineer
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501
>
> http://www.iesve.com
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park, Glasgow
> G20 0SP
> Email Disclaimer
>
> -Original Message-
> From: Matt Siebert [mailto:mlsieb...@gmail.com]
> Sent: 06 April 2011 08:27
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] External UI Samples?
>
> Hi all,
>
> Can anyone point me towards a good example of an external UI using DTF?
>  I've been googling for a while and still can't piece it together.
>
> Do I just create a standard WinForms / WPF app and then reference
> Microsoft.Deployment.WindowsInstaller?  Are there any other references /
> attributes to set?
>
> What's the general workflow for an external UI?  Is it...
>
>1. Call Installer.SetExternalUI() to register my external UI handler
>   2. Call Installer.OpenPackage() to get a Session
>   3. Use the Session to set properties using input gathered from the user
>   4. Call Installer.InstallProduct()
>
> How would I do an uninstall or a repair?
>
> As a side note I was considering using a DTF based embedded UI but after
> experimenting with the sample in the WiX source I decided against this.
>  It's great to be able to fall back to the internal UI when the embedded UI
> doesn't support something, but there is no way to handle the absence of
> .NET
> on the target machine - the embedded UI just fails and the install execute
> sequence starts.  It would be really cool if the entry point in the self
> extracting UI DLL package created by MakeSfxCA was able to detect the
> absence of the target framework and fall back to the internal UI.  Maybe in
> a future release...
>
> Thanks,
> Matt.
>
> --
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Too many CA:s (LGTH0179)

[Asker Brodersen]

The ESRIRegasm utility being called generates a registration database (xml 
file) for a dll as well as calls RegAsm. It's required for extending the ArcGIS 
environment.
Currently I have in place a system where the build msbuild script calls this 
utility so the xml files are generated. These files are then part of the 
installation. This works, but as soon as a public interface is changed in a dll 
I need to remember to manually run heat and update the installer. Adding or 
removing dlls also means adding or removing the corresponding xml file to the 
installer.

Running the ESRIRegasm utility on the dlls after installation takes care of all 
registration, the installer doesn't  need to know about the xml files or about 
COM registration of the dlls,  and the only time I need to revisit the 
installer is when I  want to add or remove a dll. This is what I want to 
accomplish, and it works as long as I don't have too many dlls to fill up the 
available sequence numbers after MsiUnpublishAssemblies. But I do...

/Asker


-Original Message-
From: David Watson [mailto:dwat...@sdl.com] 
Sent: den 6 april 2011 11:30
To: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] Too many CA:s (LGTH0179)

What is special about your registration that means you can't just heat them, 
your code implies it's just regasm?



-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se]
Sent: 06 April 2011 06:41
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Too many CA:s (LGTH0179)

Hi,
During installation/uninstallation we need a special registration of our dll:s. 
This lead to four CA:s being scheduled for each dll:





  $Meldis.Search.dll>2

  $Meldis.Search.dll>2

  $Meldis.Search.dll=2

  $Meldis.Search.dll=2<
/Custom>



But as I have close to a hundred dll:s, this results in the LGHT0179 error for 
MsiUnpublishAssemblies, I presume there simply isn't room in the sequence table 
for all of them.

How do I work around this problem?

Thanks,
Asker

-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming smartphone on the nation's most 
reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming smartphone on the nation's most 
reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Shortcut creation using WIX

[Peter Shirtcliffe]

The Shortcut/@Directory attribute says which Start menu folder the shortcut
will be created in. If you prefer, you can omit it and place the component
containing the shortcut under a [directory or] directoryref to the Start menu
folder where you want it to appear.
Shortcut/@WorkingDirectory is a directory Id. When the shortcut is run, the
current directory for the new process will be set to that location.
As you can see in the sample, Shortcut/@Icon is the Id of an icon element. 
Iconindex is 0 for an ico file. If you specify an exe or dll instead of an
ico file, IconIndex is the index of an icon resource in that file.


-Original Message-
From: Subhasree Ramesh [mailto:subhasree.ram...@live.in] 
Sent: 06 April 2011 12:22
To: WIX Toolkit
Subject: [WiX-users] Shortcut creation using WIX


Hi All,
 
I found the WIX structure for shortcut entry in MSI.
I need some clarity on the attributes, Directory, WorkingDirectory, Icon and
IconIndex.
 
What needs to be the value for Directory and WorkingDirectory, if the
shortcut for App1.msi need to be under
ProgramFilesMenu/StartMenu/Applications?
 
There is an Icon table which holds the Name and Data of icons.
What exactly need to be under this Data attribute?
 
A sample code will be of great help.
 
Thanks in advance.
 
Subhasree 
-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Shortcut creation using WIX

[Subhasree Ramesh]

Hi All,
 
I found the WIX structure for shortcut entry in MSI.
I need some clarity on the attributes, Directory, WorkingDirectory, Icon and 
IconIndex.
 
What needs to be the value for Directory and WorkingDirectory, if the shortcut 
for App1.msi need to be under ProgramFilesMenu/StartMenu/Applications?
 
There is an Icon table which holds the Name and Data of icons.
What exactly need to be under this Data attribute?
 
A sample code will be of great help.
 
Thanks in advance.
 
Subhasree 
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to specify source for a file i component

[Pally Sandher]

Peter Shirtcliffe already pointed you at the tutorial page 
(http://www.tramontana.co.hu/wix/lesson1.php#1.2) which explains this in 
response to your earlier message. I suggest reading it (and the rest of the 
tutorial) as you appear to be struggling with basic fundamentals of Windows 
Installer packaging.

Palbinder Sandher 
Software Deployment Engineer
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer

-Original Message-
From: swapna.rachako...@thomsonreuters.com 
[mailto:swapna.rachako...@thomsonreuters.com] 
Sent: 06 April 2011 11:38
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to specify source for a file i component

 

What should be a path for a 'Source' in a File element,  I have to add
main executable file for an .msi

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Action: Want to call an EXE with some Parameters.

[Pally Sandher]

http://www.tramontana.co.hu/wix/lesson3.php#3.2

Palbinder Sandher 
Software Deployment Engineer
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer

-Original Message-
From: Janda, Martin [mailto:martin.ja...@gft.com] 
Sent: 06 April 2011 11:32
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom Action: Want to call an EXE with some Parameters.

Hi,

The parameters are stored inside a property that is defined in WIX. How can I 
use a static Text and embed the content of a property? I need something like an 
escape sequence.

The call i want to make is, PropertyParameters should be replaced by ist 
content:

"c:\programme\srvany\instsrv.exe @PropertyParameters"

Could you please send me a sample xml how I could define such an custom action?

By the way. Later I want to have the complete call ti instsrv.exe with Path in 
another property.

Mit freundlichen Grüßen
Martin Janda

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to specify source for a file i component

[swapna.rachakonda]

 

What should be a path for a 'Source' in a File element,  I have to add
main executable file for an .msi

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Custom Action: Want to call an EXE with some Parameters.

[Janda, Martin]

Hi,

The parameters are stored inside a property that is defined in WIX. How can I 
use a static Text and embed the content of a property? I need something like an 
escape sequence.

The call i want to make is, PropertyParameters should be replaced by ist 
content:

"c:\programme\srvany\instsrv.exe @PropertyParameters"

Could you please send me a sample xml how I could define such an custom action?

By the way. Later I want to have the complete call ti instsrv.exe with Path in 
another property.

Mit freundlichen Grüßen
Martin Janda

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] What is source dir

[Peter Shirtcliffe]

A. http://www.tramontana.co.hu/wix/lesson1.php#1.2
B. Not sure what you mean. In a source control system ?
C. http://www.tramontana.co.hu/wix/lesson1.php#1.2  again

-Original Message-
From: swapna.rachako...@thomsonreuters.com
[mailto:swapna.rachako...@thomsonreuters.com] 
Sent: 06 April 2011 11:05
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] What is source dir

Could anybody tell me what

 

Mean, where to keep my setup files and how to create .cab folder

 

 

 

-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to implement tab control in a Dialog

[Shal Philipp]

Up the theme! )

here:
http://wix.sourceforge.net/releases/3.6.1230.0/history.txt

I have found this string:
MiCarls: Add ListView & Tab control support to ThmUtil

does it mean that WIX will be able to support implementing tabs into install
UI? or maybe support already in 3.6.1230.0 version? (nothing in help file of
3.6.1230.0 version was found)

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-implement-tab-control-in-a-Dialog-tp3291570p6245419.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] What is source dir

[swapna.rachakonda]

Could anybody tell me what

 

Mean, where to keep my setup files and how to create .cab folder

 

 

 

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] GAC File Update

[David Watson]

If you are following the major upgrade rules
(http://wix.sourceforge.net/manual-wix3/major_upgrade.htm) your 1.1.0.0 dll
should be upgraded to 1.1.0.1. You should note that the component code of
this dll should not have changed.  If it's not create a log and see what's
happening.

As to your need to leave an old dll unchanged I would add a new component for
the 1.2.0.0 and leave the old one in your msi.

Dave


-Original Message-
From: CoolBreeze [mailto:coolbreeze...@googlemail.com] 
Sent: 06 April 2011 02:25
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] GAC File Update

I have the following scenario that I'd like to know if Wix is able to
handle. I have an assembly called bizobjects.dll with a version of 1.1.0.0
installed into the GAC, somewhere in configuring my setup I have an issue of
each upgrade to say 1.1.0.1 and so forth is getting installed and 1.1.0.0 is
not being replaced with the new version. A second issue is that if I have a
new version that is now 1.2.0.0, I need to be able to install 1.2.0.0 and
not have 1.1.0.1 uninstalled, because there are still some applications that
rely on that particular version.

Referring to the first problem, when I have a new version and want it to
replace the previous version I just give my Setup a new Product ID and
increment the version number, the Update ID is not being changed, so I
thought that would uninstall the previous version and replace it with the
new version.

Can someone please guide me on how to resolve these problems if they are
resolvable?

Thanks.
-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Too many CA:s (LGTH0179)

[David Watson]

What is special about your registration that means you can't just heat them,
your code implies it's just regasm?



-Original Message-
From: Asker Brodersen [mailto:asker.broder...@esri.se] 
Sent: 06 April 2011 06:41
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Too many CA:s (LGTH0179)

Hi,
During installation/uninstallation we need a special registration of our
dll:s. This lead to four CA:s being scheduled for each dll:





  $Meldis.Search.dll>2

  $Meldis.Search.dll>2

  $Meldis.Search.dll=2

  $Meldis.Search.dll=2<
/Custom>



But as I have close to a hundred dll:s, this results in the LGHT0179 error
for MsiUnpublishAssemblies, I presume there simply isn't room in the sequence
table for all of them.

How do I work around this problem?

Thanks,
Asker

-
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] External UI Samples?

[Pally Sandher]

Take a look at SharpSetup -> http://sharpsetup.eu/ . It may help point you in 
the right direction.

Palbinder Sandher 
Software Deployment Engineer
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer

-Original Message-
From: Matt Siebert [mailto:mlsieb...@gmail.com] 
Sent: 06 April 2011 08:27
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] External UI Samples?

Hi all,

Can anyone point me towards a good example of an external UI using DTF?
 I've been googling for a while and still can't piece it together.

Do I just create a standard WinForms / WPF app and then reference
Microsoft.Deployment.WindowsInstaller?  Are there any other references /
attributes to set?

What's the general workflow for an external UI?  Is it...

   1. Call Installer.SetExternalUI() to register my external UI handler
   2. Call Installer.OpenPackage() to get a Session
   3. Use the Session to set properties using input gathered from the user
   4. Call Installer.InstallProduct()

How would I do an uninstall or a repair?

As a side note I was considering using a DTF based embedded UI but after
experimenting with the sample in the WiX source I decided against this.
 It's great to be able to fall back to the internal UI when the embedded UI
doesn't support something, but there is no way to handle the absence of .NET
on the target machine - the embedded UI just fails and the install execute
sequence starts.  It would be really cool if the entry point in the self
extracting UI DLL package created by MakeSfxCA was able to detect the
absence of the target framework and fall back to the internal UI.  Maybe in
a future release...

Thanks,
Matt.
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users] How can I kill process when uninstall

[lxy.su...@gmail.com]

Good idea!

Regards!

Sunny

2011/4/6 Rob Hamflett 

> You could run dark on your MSI and copy the dialog out of it.
>
> Rob
>
> On 06/04/2011 08:06, lxy.su...@gmail.com wrote:
> > Thanks Rob!
> >
> > After discussing with our product architecture it's acceptable to have
> this
> > FileInUse dialog though it's weird.
> >
> > I also wander how to add the option into that Dialog because I only refer
> > that Dialog to my wxs but cannot modify the definition.
> >
> > 
> > 
> >  >
> > If that has lots of work to do, I will leave it as it is.
> >
> > Thank all of you for your kindly helps!
> >
> > Sunny
> >
> > 2011/4/1 Rob Hamflett
> >
> >> I'm not sure that this will actually help your situation, but to answer
> >> your question about
> >> suppressing the FilesInUse dialog, add these values to the dialog
> >> definition:
> >> Dialog@Modeless="yes"
> >> Dialog@Hidden="yes"
> >>
> >> Rob
> >>
> >> On 01/04/2011 08:29, sunny wrote:
> >>>
> >>> Yes I am deploying an application with Qt dlls which are put in my
> >> install
> >>> folder.
> >>> When I test with running my application and uninstall, the process is
> >> killed
> >>> and the FilesInUse is triggered. But it indicates to close my "Qt
> >> Assistant"
> >>> which is launched before my test.
> >>>
> >>> I put down the log it says the "Qt Assistant" holds some Qt dll from my
> >>> install folder. That's strange!
> >>>
> >>> Info 1603. The file C:\MyApplicationFolder\phonon4.dll is being held in
> >> use
> >>> by the following process: Name: assistant, Id: 6820, Window Title:
> '(not
> >>> determined yet)'.  Close that application and retry.
> >>> 
> >>>
> >>>
> >>>
> >>> Rob Hamflett wrote:
> 
>  Are you deploying the C runtime, or something similar?  That can
> >> sometimes
>  cause that issue.  If you
>  skip the FilesInUse dialog you'll probably get prompted for a reboot,
>  which is probably more of a pain.
> 
>  Rob
> 
>  On 01/04/2011 06:45, lxy.su...@gmail.com wrote:
> > Thanks for help from Peter, Rob Hamflett and Rob Mensching!
> >
> > I have achieved detecting the process with "WixCloseApplications" and
> > killing the process by "taskkill".
> > But I still have an issue that when I try to uninstall it pops
> > "FileInUse"
> > dialog. But the application it indicates has no relationship with my
> > application which is killed.
> > So I want to disable this dialog to avoid confusing.
> > Could anyone give me a help?
> >
> > Any comment is appreciated!
> >
> >
> > 2011/3/31 Rob Mensching
> >
> >> WiX v3.5 also shipped with the RestartApplication element that
> allows
> >> you
> >> to
> >> add more files to the Restart Manager (which gives the user the
> option
> >> to
> >> shut things down).
> >>
> >> On Thu, Mar 31, 2011 at 2:12 AM, Peter
> >> Shirtcliffe  >>>   wrote:
> >>
> >>> Agreed, it doesn't look like it can kill them forcibly but there is
> >> an
> >>> option
> >>> to set a property when it can't so that the installer can abort or
> >>> prompt
> >>> the
> >>> user if the application doesn't close. It depends on whether the
> user
> >>> is
> >> in
> >>> danger of losing any work if you terminate the process. There is
> >> still
> >> the
> >>> Files In Use dialog as a second line of defence too (although I
> have
> >>> once
> >>> seen a user ignore that and expect an uninstall to work without
> >> rebooting).
> >>>
> >>> -Original Message-
> >>> From: Rob Hamflett [mailto:r...@snsys.com]
> >>> Sent: 31 March 2011 09:59
> >>> To: wix-users@lists.sourceforge.net
> >>> Subject: Re: [WiX-users] [Wix-users] How can I kill process when
> >> uninstall
> >>>
> >>> Can CloseApplication kill processes though?  It doesn't look like
> it
> >>> can.
> >>> If
> >>> you need to forcibly
> >>> kill something you might need a custom action to run taskkill or
> some
> >>> custom
> >>> code that does the job.
> >>>
> >>> Rob
> >>>
> >>> On 31/03/2011 09:45, Peter Shirtcliffe wrote:
>  Look at the CloseApplication element in the util schema in the Wix
>  documentation.
> 
>  -Original Message-
>  From: lxy.su...@gmail.com [mailto:lxy.su...@gmail.com]
>  Sent: 31 March 2011 09:40
>  To: General discussion for Windows Installer XML toolset.
>  Subject: [WiX-users] [Wix-users] How can I kill process when
> >> uninstall
> 
>  Hi all
> 
>  How can I achieve killing the process with the given name  when
> >> uninstall
> >>> my
>  application. Is there something that Wix can support that feature?
> 
>  Thanks!
> 
> 
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> -

Re: [WiX-users] [Wix-users] How can I kill process when uninstall

[Rob Hamflett]

You could run dark on your MSI and copy the dialog out of it.

Rob

On 06/04/2011 08:06, lxy.su...@gmail.com wrote:
> Thanks Rob!
>
> After discussing with our product architecture it's acceptable to have this
> FileInUse dialog though it's weird.
>
> I also wander how to add the option into that Dialog because I only refer
> that Dialog to my wxs but cannot modify the definition.
>
> 
> 
> 
> If that has lots of work to do, I will leave it as it is.
>
> Thank all of you for your kindly helps!
>
> Sunny
>
> 2011/4/1 Rob Hamflett
>
>> I'm not sure that this will actually help your situation, but to answer
>> your question about
>> suppressing the FilesInUse dialog, add these values to the dialog
>> definition:
>> Dialog@Modeless="yes"
>> Dialog@Hidden="yes"
>>
>> Rob
>>
>> On 01/04/2011 08:29, sunny wrote:
>>>
>>> Yes I am deploying an application with Qt dlls which are put in my
>> install
>>> folder.
>>> When I test with running my application and uninstall, the process is
>> killed
>>> and the FilesInUse is triggered. But it indicates to close my "Qt
>> Assistant"
>>> which is launched before my test.
>>>
>>> I put down the log it says the "Qt Assistant" holds some Qt dll from my
>>> install folder. That's strange!
>>>
>>> Info 1603. The file C:\MyApplicationFolder\phonon4.dll is being held in
>> use
>>> by the following process: Name: assistant, Id: 6820, Window Title: '(not
>>> determined yet)'.  Close that application and retry.
>>> 
>>>
>>>
>>>
>>> Rob Hamflett wrote:

 Are you deploying the C runtime, or something similar?  That can
>> sometimes
 cause that issue.  If you
 skip the FilesInUse dialog you'll probably get prompted for a reboot,
 which is probably more of a pain.

 Rob

 On 01/04/2011 06:45, lxy.su...@gmail.com wrote:
> Thanks for help from Peter, Rob Hamflett and Rob Mensching!
>
> I have achieved detecting the process with "WixCloseApplications" and
> killing the process by "taskkill".
> But I still have an issue that when I try to uninstall it pops
> "FileInUse"
> dialog. But the application it indicates has no relationship with my
> application which is killed.
> So I want to disable this dialog to avoid confusing.
> Could anyone give me a help?
>
> Any comment is appreciated!
>
>
> 2011/3/31 Rob Mensching
>
>> WiX v3.5 also shipped with the RestartApplication element that allows
>> you
>> to
>> add more files to the Restart Manager (which gives the user the option
>> to
>> shut things down).
>>
>> On Thu, Mar 31, 2011 at 2:12 AM, Peter
>> Shirtcliffe>>   wrote:
>>
>>> Agreed, it doesn't look like it can kill them forcibly but there is
>> an
>>> option
>>> to set a property when it can't so that the installer can abort or
>>> prompt
>>> the
>>> user if the application doesn't close. It depends on whether the user
>>> is
>> in
>>> danger of losing any work if you terminate the process. There is
>> still
>> the
>>> Files In Use dialog as a second line of defence too (although I have
>>> once
>>> seen a user ignore that and expect an uninstall to work without
>> rebooting).
>>>
>>> -Original Message-
>>> From: Rob Hamflett [mailto:r...@snsys.com]
>>> Sent: 31 March 2011 09:59
>>> To: wix-users@lists.sourceforge.net
>>> Subject: Re: [WiX-users] [Wix-users] How can I kill process when
>> uninstall
>>>
>>> Can CloseApplication kill processes though?  It doesn't look like it
>>> can.
>>> If
>>> you need to forcibly
>>> kill something you might need a custom action to run taskkill or some
>>> custom
>>> code that does the job.
>>>
>>> Rob
>>>
>>> On 31/03/2011 09:45, Peter Shirtcliffe wrote:
 Look at the CloseApplication element in the util schema in the Wix
 documentation.

 -Original Message-
 From: lxy.su...@gmail.com [mailto:lxy.su...@gmail.com]
 Sent: 31 March 2011 09:40
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] [Wix-users] How can I kill process when
>> uninstall

 Hi all

 How can I achieve killing the process with the given name  when
>> uninstall
>>> my
 application. Is there something that Wix can support that feature?

 Thanks!


>>>
>>>
>>>
>>>
>>
>> -
>>> -
>>> Create and publish websites with WebMatrix
>>> Use the most popular FREE web apps or write code yourself;
>>> WebMatrix provides all the features you need to develop and
>>> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>>> ___

[WiX-users] External UI Samples?

[Matt Siebert]

Hi all,

Can anyone point me towards a good example of an external UI using DTF?
 I've been googling for a while and still can't piece it together.

Do I just create a standard WinForms / WPF app and then reference
Microsoft.Deployment.WindowsInstaller?  Are there any other references /
attributes to set?

What's the general workflow for an external UI?  Is it...

   1. Call Installer.SetExternalUI() to register my external UI handler
   2. Call Installer.OpenPackage() to get a Session
   3. Use the Session to set properties using input gathered from the user
   4. Call Installer.InstallProduct()

How would I do an uninstall or a repair?

As a side note I was considering using a DTF based embedded UI but after
experimenting with the sample in the WiX source I decided against this.
 It's great to be able to fall back to the internal UI when the embedded UI
doesn't support something, but there is no way to handle the absence of .NET
on the target machine - the embedded UI just fails and the install execute
sequence starts.  It would be really cool if the entry point in the self
extracting UI DLL package created by MakeSfxCA was able to detect the
absence of the target framework and fall back to the internal UI.  Maybe in
a future release...

Thanks,
Matt.
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users] How can I kill process when uninstall

[lxy.su...@gmail.com]

Thanks Rob!

After discussing with our product architecture it's acceptable to have this
FileInUse dialog though it's weird.

I also wander how to add the option into that Dialog because I only refer
that Dialog to my wxs but cannot modify the definition.





> I'm not sure that this will actually help your situation, but to answer
> your question about
> suppressing the FilesInUse dialog, add these values to the dialog
> definition:
> Dialog@Modeless="yes"
> Dialog@Hidden="yes"
>
> Rob
>
> On 01/04/2011 08:29, sunny wrote:
> >
> > Yes I am deploying an application with Qt dlls which are put in my
> install
> > folder.
> > When I test with running my application and uninstall, the process is
> killed
> > and the FilesInUse is triggered. But it indicates to close my "Qt
> Assistant"
> > which is launched before my test.
> >
> > I put down the log it says the "Qt Assistant" holds some Qt dll from my
> > install folder. That's strange!
> >
> > Info 1603. The file C:\MyApplicationFolder\phonon4.dll is being held in
> use
> > by the following process: Name: assistant, Id: 6820, Window Title: '(not
> > determined yet)'.  Close that application and retry.
> > 
> >
> >
> >
> > Rob Hamflett wrote:
> >>
> >> Are you deploying the C runtime, or something similar?  That can
> sometimes
> >> cause that issue.  If you
> >> skip the FilesInUse dialog you'll probably get prompted for a reboot,
> >> which is probably more of a pain.
> >>
> >> Rob
> >>
> >> On 01/04/2011 06:45, lxy.su...@gmail.com wrote:
> >>> Thanks for help from Peter, Rob Hamflett and Rob Mensching!
> >>>
> >>> I have achieved detecting the process with "WixCloseApplications" and
> >>> killing the process by "taskkill".
> >>> But I still have an issue that when I try to uninstall it pops
> >>> "FileInUse"
> >>> dialog. But the application it indicates has no relationship with my
> >>> application which is killed.
> >>> So I want to disable this dialog to avoid confusing.
> >>> Could anyone give me a help?
> >>>
> >>> Any comment is appreciated!
> >>>
> >>>
> >>> 2011/3/31 Rob Mensching
> >>>
>  WiX v3.5 also shipped with the RestartApplication element that allows
>  you
>  to
>  add more files to the Restart Manager (which gives the user the option
>  to
>  shut things down).
> 
>  On Thu, Mar 31, 2011 at 2:12 AM, Peter
>  Shirtcliffe >> >>>  wrote:
> 
> > Agreed, it doesn't look like it can kill them forcibly but there is
> an
> > option
> > to set a property when it can't so that the installer can abort or
> > prompt
> > the
> > user if the application doesn't close. It depends on whether the user
> > is
>  in
> > danger of losing any work if you terminate the process. There is
> still
>  the
> > Files In Use dialog as a second line of defence too (although I have
> > once
> > seen a user ignore that and expect an uninstall to work without
>  rebooting).
> >
> > -Original Message-
> > From: Rob Hamflett [mailto:r...@snsys.com]
> > Sent: 31 March 2011 09:59
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] [Wix-users] How can I kill process when
>  uninstall
> >
> > Can CloseApplication kill processes though?  It doesn't look like it
> > can.
> >If
> > you need to forcibly
> > kill something you might need a custom action to run taskkill or some
> > custom
> > code that does the job.
> >
> > Rob
> >
> > On 31/03/2011 09:45, Peter Shirtcliffe wrote:
> >> Look at the CloseApplication element in the util schema in the Wix
> >> documentation.
> >>
> >> -Original Message-
> >> From: lxy.su...@gmail.com [mailto:lxy.su...@gmail.com]
> >> Sent: 31 March 2011 09:40
> >> To: General discussion for Windows Installer XML toolset.
> >> Subject: [WiX-users] [Wix-users] How can I kill process when
> uninstall
> >>
> >> Hi all
> >>
> >> How can I achieve killing the process with the given name  when
>  uninstall
> > my
> >> application. Is there something that Wix can support that feature?
> >>
> >> Thanks!
> >>
> >>
> >
> >
> >
> >
> 
> -
> > -
> > Create and publish websites with WebMatrix
> > Use the most popular FREE web apps or write code yourself;
> > WebMatrix provides all the features you need to develop and
> > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > SDL PLC confidential, all rights reserved.
> > If you are not the intended recipient of this mail SDL requests and
> > requires that you delete it