Re: [WiX-users] Uninstall restart issue

[Blair]

It also requires that the service is setup to allow non-elevated privileges 
to stop it.

Event Viewer\Windows Logs\Application
Source: RestartManager

-Original Message- 
From: Joel Budreau
Sent: Tuesday, June 25, 2013 6:22 PM
To: afor...@cmu.edu ; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Uninstall restart issue

Hey Alain,

Take a look at my answer to this problem on stackoverflow -
http://stackoverflow.com/questions/6913332/wix-installer-problem-why-does-restartmanager-mark-service-as-rmcritical-and-no/8147540#8147540

Basically, you can 'lie' about the custom action and mark it as
immediate instead of deferred.  The drawback is that if your install
fails and rollsback, the service you've shut down will still be shut
down.  Up to you whether or not that's an appropriate risk for your
product.

- Joel

On Sat, Jun 15, 2013 at 11:11 AM, Alain Forget  wrote:
> I'm still wrestling with this request to restart on uninstall. To recap, I 
> have an MSI that when I install it, and then try to uninstall it, it 
> usually tells the user that some of the files to be uninstalled are in use 
> and will require a reboot. However, this should not be, because the 
> services that are using the files will stop immediately upon request.
>
> The problem seems to be that the installer is making the determination 
> that the files are in use before even trying to stop services. Looking at 
> the uninstall log, during FileCost, the installer determines that multiple 
> "folder had been blocked by the 1 mask argument (the folder pair's 
> iSwapAttrib member = 0)", which I think means it's in use? Furthermore, at 
> InstallValidate, "RESTART MANAGER: Did detect that a critical application 
> holds file[s] in use, so a reboot will be necessary." Note that both 
> InstallValidate and FileCost come before StopServices (see 
> http://msdn.microsoft.com/en-us/library/aa372038).
>
> It had been suggested that I should stop the services myself with "net 
> stop". So I attempted to do so with this in my .wxs:
>
> 
>  Property="cmdStopClientCommModuleService" Value="net stop [#myService]" />
>  DllEntry="CAQuietExec" Return="check" Impersonate="no" />
>
> 
>   >
>   >
> 
>
> However, candle / light don't allow it:
>
> error LGHT0204 : ICE77: cmdStopMyService is a in-script custom action.  It 
> must be sequenced in between the InstallInitialize action and the 
> InstallFinalize action in the InstallExecuteSequence table
>
> Following Light's recommendation wouldn't solve my problem, because 
> InstallInitialze happens long after the uninstaller has decided that the 
> files are in use.
>
> So I'm completely stumped and would appreciate some suggestions.
>
> Alain
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users 


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Authoring a patch to patch "everything"

[Blair]

An empty PatchFamily is "the" way to have that one PatchFamily cover the
entire product. Your error message is symptomatic of something else.

Do you have a stack trace of that error? Do you have anti-virus software
running on your 'c:\tmp\' folder?

-Original Message-
From: John Daintree [mailto:jo...@dyalog.com] 
Sent: Tuesday, March 01, 2011 4:57 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Authoring a patch to patch "everything"

Hello all (again),

 

I'm attempting to author a patch that patches every file in a package. 

 

To begin with I started with a patch file that only patches some binary,
versioned, components, and that seems to work:

 



http://schemas.microsoft.com/wix/2006/wi";>



 







 



 

  







 

However I want to create a patch that will patch all changed files in the
application. I'm sure I read somewhere (but I can't find the link now), that
if I had no children in the PatchFamily element that it would include all
changes in the patch. However, if I comment out (or remove) the include of
ComponentsToPatch.wxi I get a PYRO error:

 

error PYRO0103 : The system cannot find the file
'c:\tmp\a3pbt24c\patch.msp'.

 

I can probably auto-create a full list of ComponentRefs from the install
package to add to the PatchFamily if necessary, but I thought there'd be a
slicker way.

 

How does one author a patch to patch all files?

 

Thanks,

John.

~ 


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT
data 
generated by your applications, servers and devices whether physical,
virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] light command line, -b option, alternate path

[Blair]

-b tells the binder additional locations where to locate files that are
referenced in the wixobj files (the source locations of File, Binary, and
other related elements), not the wixobj files themselves.

-Original Message-
From: Marc Mirucki (Counterpunch Software LLC)
[mailto:v-mam...@microsoft.com] 
Sent: Tuesday, March 01, 2011 10:52 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] light command line, -b option, alternate path

Not sure what I'm doing wrong here... my wixobj files are in .\obj\release
directory yet light (3.5) doesn't find them with the -b option:

light -b .\obj\release VBA7.wixobj
light.exe : error LGHT0103 : The system cannot find the file 'VBA7.wixobj'
with type 'Source'.

dir .\obj\release\VBA7.wixobj
Volume in drive D is Data
Volume Serial Number is 8802-C60A

02/28/2011  09:10 PM 5,273 VBA7.wixobj
   1 File(s)  5,273 bytes
   0 Dir(s)  159,793,238,016 bytes free

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT
data 
generated by your applications, servers and devices whether physical,
virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] DTF Transaction problem with x64 msi

[Blair]

I know this is a bit late, but for history's sake, here is the link to what
you are seeing (it isn't DTF, it is Windows Installer):

http://blogs.msdn.com/b/heaths/archive/2009/07/03/installation-sequence-rest
rictions-for-multi-package-transactions.aspx

Summary: If you want MSIs if different bitnesses in the same transaction,
they must be in 64-bit-then-32-bit order.

Blair

-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com] 
Sent: Friday, April 01, 2011 1:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DTF Transaction problem with x64 msi

The point here is that you are using a multi package transaction. So
the whole Install Execute transaction can run either as "x86"
transaction or "x64" transaction if there are only "x64" pacakges in
the transaction but not as combined one where x64 packages are treated
as they should (e.g. targeting  'C:\Program Files\' folder). Windows
Installer now seems to make the "x64" packages compatible to x86
packages with the described result.

Read this issues a short time ago, think it was also in this mailing
list but don't find the link anymore.

In general I think as workaround you could separate the logic and use
a second transaction just for installing the x64 packages in your
bootstrapper.

Regards,
Tobias


2011/4/1 Douglas Mendizabal :
> I'm using an external UI to chain several msi files together.  I have an
ExternalUIHandler that is part of a WPF MVVM wizard application.  Most of
the msi files are 32bit ("Intel" platform) but one of them is a 64 bit
("x64" platform, let's call it "my-x64.msi") that contains both 32-bit and
64-bit components.  The wizard app checks the operating system bitness and
then makes a list of the msi files that will be installed, so that the x64
msi is only installed when running on a 64-bit OS.
>
> When I run the my-x64.msi by itself, the 64-bit components are correctly
installed into C:\Program Files\...  and the 32-bit components are installed
into C:\Program Files (x86)\...  However, when my-x64.msi is installed by
the External UI, the Windows Installer service treats it like a 32-bit MSI
and WIN64DUALFOLDERS hoses all components using ProgramFiles64Folder, so I
end up with all components in the C:\Program Files (x86)\... folder.
>
> >From the MSI log when using the External UI:
>
> MSI (s) (9C:00) [16:00:24:038]: WIN64DUALFOLDERS: 'C:\Program Files
(x86)\' will substitute 17 characters in 'C:\Program Files\' folder path.
(mask argument = 0, the folder pair's iSwapAttrib member = 0).
>
> In the External UI, I'm using
>
> var installTransaction = new Transaction("myInstallTransaction",
TransactionAttributes.None);
>
> to start a muti-package transaction.  After that I'm using
>
>                Installer.InstallProcut(pathToMsiString, propertiesString);
>
> for every MSI file, followed by
>
>                installTransaction.Rollback();
>
> if any InstallProduct() call fails or is cancelled, or
>
>                installTransaction.Commit();
>
> if they are all successful.  Am I missing something else here?  Or have I
stumbled upon a bug in DTF?
>
> Thanks,
> Douglas M.
>
>

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


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


--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CodeBase value coming empty on ActiveX MSI installation

[Blair]

Is  in the same Component as
the registry entries you provided below?

Blair

-Original Message-
From: Shashikant Saini [mailto:shashikant.sa...@imail.org] 
Sent: Monday, April 18, 2011 3:31 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CodeBase value coming empty on ActiveX MSI installation

Hi

I am using Wix 3.5 for my Active X set up project which creates an MSI. I am
injecting the ActiveX registry entries into the Product.wxs via heat.exe.

Here is  the example















So Ideally when MSI is installed the codebase should have the value as
file:///C:\Program Files\Intermountain
Healthcare\ePrescribe\Org.Intermountain.RxWriter.Client.ActiveX.dll but the value comes as file:///,
everything works fine with my msi, except this CodeBase value. Please let me
know if you guys have any idea on this. You help will be greatly
appreciated.

Thanks
Shashi

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Difx versions in WiX

[Blair]

>From the history.txt files:

BobArnso: SFFeature:3130590 - Update DifxApp DLLs in DifxApp .wixlibs to 
  version shipped in DDK 7600.16385.1.

Introduced in the following builds:
3.5.2430.0 & 3.6.1230.0

This newer build of DifxApp is not in any 3.0.x build of WiX.

There were some discussions on wix-users before that feature request was
filed discussing issues that were reportedly fixed in the newer DifxApp
builds, so it may be worth your while to upgrade to 3.5.

Blair

-Original Message-
From: Rob Hamflett [mailto:r...@snsys.com] 
Sent: Thursday, April 21, 2011 5:32 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Difx versions in WiX

Is there anywhere that lists what version of Difx is in which versions of
WiX.  I've been having 
some trouble with it lately and have been wondering if there's anything
changed in the newer 
versions of WiX.  Still on 3.0.4805.0 with no real reason to upgrade, but an
improved Difx 
implementation would get me to.

Rob



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Integrity of WiX binaries

[Blair]

Please file a feature request so it doesn't get lost in the email list.

Blair

-Original Message-
From: Alex Ivanoff [mailto:alex.ivan...@shavlik.com] 
Sent: Thursday, April 21, 2011 7:18 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Integrity of WiX binaries

Wanted to ask this question for a long time.


On Apr 21, 2011, at 21:05, Andy Clugston  wrote:

> Ditto. Very interested in this topic as well.
>
> Thanks.
>
> On Thu, Apr 21, 2011 at 8:49 PM,  wrote:
>
>> Hi,
>>
>> Is it possible for WiX binaries and the MSI (eg Wix35.msi) to be
>> digitally signed by the WiX team? Alternatively is it possible for
>> an authoritative team member to post MD5 and SHA-1 hashes of the
>> official binaries and the MSI to this list? My organization now
>> requires integrity validation of all software used in the build
>> process. If the cost of a digital certificate is a consideration,
>> I'm sure many organizations would be willing to donate
>>
>> Thank you
>>
>>
>>
>>

--
>> Fulfilling the Lean Software Promise
>> Lean software platforms are now widely adopted and the benefits have been
>> demonstrated beyond question. Learn why your peers are replacing JEE
>> containers with lightweight application servers - and what you can gain
>> from the move. http://p.sf.net/sfu/vmware-sfemails
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>

--
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been
> demonstrated beyond question. Learn why your peers are replacing JEE
> containers with lightweight application servers - and what you can gain
> from the move. http://p.sf.net/sfu/vmware-sfemails
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CustomAction that needs to figure out the destination path

[Blair]

Depends on when your custom action is scheduled. Can you describe in more
detail what you are trying to achieve?

Blair

-Original Message-
From: Rune Moberg [mailto:jjfl...@gmail.com] 
Sent: Saturday, April 23, 2011 1:18 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] CustomAction that needs to figure out the destination
path

Given a feature or a component (or for that matter a file), what is
the best way for my custom action to determine the destination folder?

Do I have to drill down into the Directory table and build the full
path myself, or is there an easier way?

TIA.

-- 
Rune


--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] When Applying patch, no changes reflected. But in log file, getting succes msg.

[Blair]

For heat, "-ag" uses the "*" value to generate stable component guids. "-gg"
is only useful for running heat once to get a WXS structure that you will
maintain manually (or programmatically but not using heat).

If you have not yet released your MSI and you need to use heat in your
build, use -ag not -gg. If you can reuse the previous component guids you
have a better chance of success (you can still have problems if any files or
other keypaths were removed). 

Blair

-Original Message-
From: Preethi S. [mailto:preet...@amiindia.co.in] 
Sent: Thursday, April 21, 2011 1:55 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] When Applying patch, no changes reflected. But in
log file, getting succes msg.

Let me explain how an msi is created for my project.

We have a batch script that downloads and builds all the source file.
Again another batch script is called that will run the wix scripts(using
heat,candle and light).

So heat.exe will create GUID everytime?? We've used -gg option in
heat.exe..
Referred http://wix.mindcapers.com/wiki/Heat

In that, they stated "heat is considerably less useful after initial
project setup, because there is no way to preserve 
component GUIDs when repeating the process to acquire new files".

But in another website,
http://webcache.googleusercontent.com/search?q=cache:7H3iIlrw0MgJ:markli
nesdavies.blogware.com/blog/_archives/2011/3/14/4771326.html+preserving+
GUID+%2B+heat+%2B+wix&cd=1&hl=en&ct=clnk&gl=in&source=www.google.co.in

Preserving GUID is possible.. If we preserve our GUIDs, will the problem
get solved?

Thank You,
S. Preethi.

-Original Message-
From: Devarajan, Mahesh IN BLR SISL [mailto:d.mah...@siemens.com] 
Sent: Wednesday, April 20, 2011 3:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] When Applying patch, no changes reflected. But
in log file, getting succes msg.

Is the component table shows new component (that is ok)? But if it shows
change in component GUID, or Removed Components then the patch will not
work.

Possible problem:
Make sure that the file fragments are only updated when you create the
second MSI. If you create(not update) the fragment using Heat/Paraffin
it will generate new GUID's.

Solution/Analysis:
The log file will show which component is giving the problem, you can
easily find out what is the difference from the 1st MSI to the 2nd one.
Analyze the log file that will help u.
(or)

If you have any other tools like InstallShield, you can easily compare
the two MSI's and find out the differences.

Take care to follow rules for Patch Creation:
 http://msdn.microsoft.com/en-us/library/aa367850.aspx


With best regards,
Mahesh D


-Original Message-
From: Preethi S. [mailto:preet...@amiindia.co.in]
Sent: Wednesday, April 20, 2011 2:40 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] When Applying patch, no changes reflected. But
in log file, getting succes msg.

Thanks Mahesh.

After creating 2 MSIs I verified it through ORCA. The component GUIDs
are same in the Component table. There is no difference.

But when I viewed a patch over the first MSI(open first MSI in ORCA,
then select Transform-> View Patch), It shows lot of difference in
Component table.

Have any idea?

-Original Message-
From: Devarajan, Mahesh IN BLR SISL [mailto:d.mah...@siemens.com]
Sent: Wednesday, April 20, 2011 11:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] When Applying patch, no changes reflected. But
in log file, getting succes msg.


Please note the following line in your log file.

"MSI (c) (74:7C) [19:40:03:546]: SELMGR: ComponentId
'{C1D08FF3-4507-4371-B362-4D07D21E4339}' is registered to feature
'BCModuleFeature', but is not present in the Component table.  Removal
of components from a feature is not supported!"

You will not be able to remove components/files when you create pathes,
also make sure that both the .msi contains same GUID's for existing
components.



With best regards,
Mahesh D


-Original Message-
From: Preethi S. [mailto:preet...@amiindia.co.in]
Sent: Wednesday, April 20, 2011 11:04 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] When Applying patch, no changes reflected. But in
log file, getting succes msg.

When applying the patch created using WIX, I am getting Success message.
But no updates take place.



My previous product has more than 5000 files. In patch there are 1048
files have been changed. Using ORCA, I can able to see the modified file
names and components.



But after applying patch the modifications are not getting reflected.



Please help me.



Below I pasted my log file.



=== Verbose logging started: 4/19/2011  19:40:01  Build type: SHIP
UNICODE 3.01.4000.2435  Calling process: C:\WINDOWS\system

Re: [WiX-users] Patch install failing on Server 2003 - Error 2920

[Blair]

If my math is still working this late at night, 4608 = 512 + 4096. 4096 =
msidbFileAttributesPatchAdded. That attribute must only be present on a file
that a patch added (i.e. that is not present in the MSI) according to
http://msdn.microsoft.com/library/aa368596.aspx. Which patch is adding that
attribute?

Blair

-Original Message-
From: David Rickard (USA) [mailto:davri...@microsoft.com] 
Sent: Monday, April 18, 2011 4:18 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch install failing on Server 2003 - Error 2920

Ran ICE on the MSI+Patch via Orca:

ICE03   ERROR   Table: PatchPackage Column: PatchId Missing specifications
in _Validation Table (or Old Database)
ICE03   ERROR   Table: PatchPackage Column: Media_ Missing specifications in
_Validation Table (or Old Database)
ICE03   ERROR   Table: MsiPatchHeaders Column: StreamRef Missing
specifications in _Validation Table (or Old Database)
ICE03   ERROR   Table: MsiPatchHeaders Column: Header Missing specifications
in _Validation Table (or Old Database)
ICE03   ERROR   Table: Patch Column: File_ Missing specifications in
_Validation Table (or Old Database)
ICE03   ERROR   Table: Patch Column: Sequence Missing specifications in
_Validation Table (or Old Database)
ICE03   ERROR   Table: Patch Column: PatchSize Missing specifications in
_Validation Table (or Old Database)
ICE03   ERROR   Table: Patch Column: Attributes Missing specifications in
_Validation Table (or Old Database)
ICE03   ERROR   Table: Patch Column: Header Missing specifications in
_Validation Table (or Old Database)
ICE03   ERROR   Table: Patch Column: StreamRef_ Missing specifications in
_Validation Table (or Old Database)
ICE45   ERROR   Row '' in table 'File' has bits set in the
'Attributes' column that are reserved. They must be 0 to ensure
compatibility with future installer versions.
ICE82   WARNING This action PatchFiles has duplicate sequence number 4001 in
the table InstallExecuteSequence

The file's attributes are 4608, which is different from all the other files,
which are 512. Could that be the issue?

-Original Message-
From: David Rickard (USA) [mailto:davri...@microsoft.com] 
Sent: Monday, April 18, 2011 3:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch install failing on Server 2003 - Error 2920

Okay well it's failing with the same error even when I generate a correct
Sequence number for the intermediary patch.

-Original Message-
From: David Rickard (USA) [mailto:davri...@microsoft.com]
Sent: Monday, April 18, 2011 2:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch install failing on Server 2003 - Error 2920

To make it clear, this is in reference to a file that's present in the
original MSI (Sequence 13), patched maybe improperly with Sequence 2 and now
a second patch is trying to update it and failing.

-Original Message-
From: David Rickard (USA) [mailto:davri...@microsoft.com]
Sent: Monday, April 18, 2011 1:50 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Patch install failing on Server 2003 - Error 2920

I'm getting this error when trying to apply a patch on a Windows Server 2003
box:

MSI (s) (D8:EC) [15:46:34:054]: Transforming table Error.
MSI (s) (D8:EC) [15:46:34:054]: Transforming table Error.
MSI (s) (D8:EC) [15:46:34:054]: Note: 1: 2262 2: Error 3: -2147287038 MSI
(s) (D8:EC) [15:46:34:054]: Transforming table Error.
MSI (s) (D8:EC) [15:46:34:054]: Note: 1: 2262 2: Error 3: -2147287038 MSI
(s) (D8:EC) [15:46:34:054]: Transforming table Error.
MSI (s) (D8:EC) [15:46:34:054]: Note: 1: 2262 2: Error 3: -2147287038
DEBUG: Error 2920:  Source directory not specified for file .

Now it seems that this error only occurs on W2k3 and when I'm applying
another patch on top of a previous patch (that happened to update the same
file).

I read up some more and thought it might be because I wasn't setting the
SequenceStart on the patch family. I looked at the patch with Orca and found
that the first one (that preceded the failure) was setting the new file with
a Sequence of 2, which was the same as a different file in the original
install. Now my new patch has SequenceStart set properly (at 1020 right
now), but the install still fails with the same error. Did the previous
patch (with no SequenceStart set) make the file unpatchable on W2k3?





--
Benefiting from Server Virtualization: Beyond Initial Workload Consolidation
-- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___

Re: [WiX-users] old unanswered question regarding to Dialog Close button

[Blair]

I'm curious: what happens if you include but disable the cancel button?

-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com] 
Sent: Wednesday, April 27, 2011 5:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] old unanswered question regarding to Dialog Close
button

hmmm ... just, by accident figured out something interesting. The [X]
seems to correspond with the [Cancel] Button. So when removing the
Cancel button the "Dialog Close / [X]" gets disabled. Unfortunately
this seems not be working for the ExitDialog.


2011/4/27 Tobias S :
> afaik not possible except for modal dialogs. Assume here Tramontana
> shows such one.
>
> By default this is not a possible requirement for Windows Installer.
>
> Regards,
> Tobias
>
>
> 2011/4/27 william lee :
>> Hi,
>> I searched a lot online, but did not hit a result.
>> The question is how the installer make the decision to enable or disable
the
>> dialog X(close) button on top right corner.
>> There is no dialog attribute to control it, but sometimes it just
disabled,
>> for example:
>> http://www.tramontana.co.hu/wix/lesson8.php#8.1
>> The first sample dialog just have X button disabled.
>>
>> I have a requirement that want to disable this X button on the finish
>> install dialog, no idea how to do it.
>> Any one know some internal "undocumented" information? :)
>>
>> thanks,
>> William L.
>>

--
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creatin User Group and add current user into it

[Blair]

Create a Feature Request on SF?

Blair

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Thursday, May 05, 2011 6:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creatin User Group and add current user into it


I'm leary of going out of process like that.  It's really difficult to
handle unexpected errors.  Personally I created a datadriven custom action
for defining groups and then use the built in wixutil extensions to handle
associating users to the groups.    I'm not sure why WiX doesn't handle this
in the first place as the Group element under a Component element would be a
logical extension to the pattern.

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

--- On Thu, 5/5/11, Rahul Ramesh Ekbote  wrote:


From: Rahul Ramesh Ekbote 
Subject: Re: [WiX-users] Creatin User Group and add current user into it
To: "General discussion for Windows Installer XML toolset."

Date: Thursday, May 5, 2011, 4:30 AM


Hey,
Thanks Sudheer. It really helps.


Rahul

-Original Message-
From: Sudheer Kumar Kusuma (Accenture) [mailto:v-kku...@microsoft.com] 
Sent: 03 May 2011 AM 11:01
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creatin User Group and add current user into it

Use NET LOCALGROUP to create localgroups and add users over c# custom action

Thanks,
Sudheer |OEM Build Operations Team

-Original Message-
From: Sharad Patel [mailto:spa...@winscribe.com]
Sent: Monday, May 02, 2011 1:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creatin User Group and add current user into it

Have you tried setting the Impersonate attribute to "no" in your
CustomAction element?

http://wix.sourceforge.net/manual-wix2/wix_xsd_customaction.htm


-Original Message-
From: Rahul Ramesh Ekbote [mailto:rahu...@microsoft.com]
Sent: Tuesday, 3 May 2011 12:06 a.m.
To: chr...@deploymentengineering.com; General discussion for Windows
Installer XML toolset.(wix-users@lists.sourceforge.net)
Subject: Re: [WiX-users] Creatin User Group and add current user into it

Hi Christopher,
I am facing one problem with create group CustomAction. I created custom
action in C# however it is not executing when I am running .msi by double
clicking, however if  I run command prompt with "Run as Administrator" then
it work fines. 
So what I need to do to run .msi as "Run as Administrator".


Thanks,
Rahul

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: 29 April 2011 PM 11:15
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creatin User Group and add current user into it

Correct. I had to write (DTF) custom actions for this functionality.  

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

--- On Fri, 4/29/11, Dick Van den Brink  wrote:


From: Dick Van den Brink 
Subject: Re: [WiX-users] Creatin User Group and add current user into it
To: wix-users@lists.sourceforge.net
Date: Friday, April 29, 2011, 8:18 AM



I think you need a custom action for that. The WiX group element can only
search groups and not create new ones according to the documentation. It can
however add new or existing users to an existing group. 

> From: rahu...@microsoft.com
> To: wix-users@lists.sourceforge.net
> Date: Fri, 29 Apr 2011 13:04:38 +
> Subject: [WiX-users] Creatin User Group and add current user into it
> 
> Hi,
> Is there any simple way in WIX to create user group and add current user
into that group.  Or only option is to create CustomAction in C#.
> Currently I am using WIX 3.6
> 
> Thanks,
> Rahul
> 


--
WhatsUp Gold - Download Free Network Management Software The most intuitive,
comprehensive, and cost-effective network management toolset available
today.  Delivers lowest initial acquisition cost and overall TCO of any
competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
WhatsUp Gold - Download Free Network Management Software The most intuitive,
comprehensive, and cost-effective network management toolset available
today.  Delivers lowest initial acquisition cost and overall TCO of any
competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mai

Re: [WiX-users] 32-Bit < > 64-Bit

[Blair]

Are you using the same UpgradeCode?

Blair

-Original Message-
From: James Robertson [mailto:ja...@osodata.com] 
Sent: Friday, May 06, 2011 4:58 AM
To: WiX
Subject: [WiX-users] 32-Bit < > 64-Bit

Hi,

I have an existing installer for a 32-bit application that has been working
fine for the last year or so.  I am now looking at adding a second installer
(users will download the 32-bit or 64-bit installer, I'm not planning on
having a single installer decide which version to install) based on the same
script that can install a 64-bit version of my application.  I have
something that almost works, but am stuck on a few things.

The current 32-bit installer drops executable files in Program Files (x86)
and some common data files in ProgramData.  These folders are cleaned up as
part of the uninstall procedure as long as they're empty (new files can be
added by the user to the ProgramData folder, and these will remain across
upgrades).  The new 64-bit installer is supposed to drop executable files in
Program Files and the same data files in Program Data.

The existing installer always uninstalls any previous version before
installing the new one (so users can downgrade if I screw up) and I am
trying to make the 64-bit version function in the same way.  Ideally the
installer will treat any existing install 32-bit or 64-bit in the same say
regardless of their actual install paths, I.e., providing the version number
is different, the previously installed version will be uninstalled before
the new version is installed.

>From what I can see, installing and uninstalling a 64-bit version on a
clean machine works.  I am going to go one step further and assume that
upgrading 64-bit to 64-bit also works.

The problems I have are as follows:

1) When I install the 64-bit version when a 32-bit installation is already
present, the 32-bit version isn't uninstalled.  So while the 64-bit version
is installed in Program Files there is no shortcut to it, nor is there any
way to uninstall it (the 32-bit version is still listed in Programs and
Features).

2) When I install the 32-bit version when a 64-bit installation is already
present, the 64-bit version is not correctly removed, but the start menu
shortcut and uninstall link in Programs and Features now reference the
32-bit version.


So, how is this scenario supposed to be implemented?  Are there any decent
tutorials or references on how to implement this upgrade scenario correctly?

The current installer script as it stands can be viewed here:
http://www.osodata.com/stuff/Product.wxs


James


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Property Behavior in Repair vs. Upgrade

[Blair]

Look at ComponentSearch.

Blair

-Original Message-
From: Aaron DeMarre [mailto:adema...@gmail.com] 
Sent: Friday, May 06, 2011 1:38 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Property Behavior in Repair vs. Upgrade

I am wondering if there is a way to get my major upgrade to behave like
repair - where properties are restored.

I have three properties that determine the install location of various
components. I was short sighted and only saved the INSTALLOCATION property
to the registry. Now when doing a major upgrade the reinstall uses the
default paths instead of the paths selected in the previous version of the
product. No shocking news there.

However a repair of the original install will use the paths the user
originally selected. I am wondering where this data is stored, and if it can
be accessed and used by a major upgrade? I was under the assumption this
data was not persisted, but now I am wondering how this is persisted for a
repair operation?

Thanks for any insight with this, I have painted myself into a corner pretty
good this time!

-Aaron

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] error PYRO0001: Could not find file ?

[Blair]

The WIXPDB files only contain the files if they were built using "bound" or
"binary" WIXOUT/WIXLIB files (which you can get using light's (or lit's) -bf
command-line argument). Files that light incorporates directly into an MSI
are never "bound" to the WIXPDB.

Alternately you can write a BinderFileManager (which you place into a
WixExtension you pass to light) where you override the one of the
ResolveFile() methods (use the easiest one that works for your setup).

Blair

-Original Message-
From: Elfe Xu [mailto:elf...@microsoft.com] 
Sent: Monday, May 09, 2011 2:25 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] error PYRO0001: Could not find file ?

Hi all,
I'm following the example
http://wix.sourceforge.net/manual-wix3/wix_patching.htm to create a patch.
Everything works fine on test binaries built on my local computer.
However, I got "error PYRO0001: Could not find file" when I changed to use
released msi file built by team's build machine.

In the patch.proj, I have
\\rel\Archive\Product\DailyBuilds.1.0.1381.0.110412-2317\Rel
ease\Bin\en-us
\\rel\Archive\Product\DailyBuilds.1.0.1383.0.110427-1815\Rel
ease\Bin\en-us>







The build reports error
pyro.exe : error PYRO0001: Could not find file
'C:\Product\161\Atlanta\DailyBui
lds\Sources.binaries.Release\bin\ClientShared.dll'.
  Exception Type: System.IO.FileNotFoundException
  Stack Trace:
 at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
 at System.IO.FileInfo.get_Length()
 at
Microsoft.Tools.WindowsInstallerXml.BinderFileManager.CompareFiles(Stri
  ng targetFile, String updatedFile)
 at Microsoft.Tools.WindowsInstallerXml.Binder.CopyTransformData(Output
out
  put, FileRowCollection allFileRows)
 at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output
output,
  String databaseFile)
 at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output,
String f
  ile)
 at Microsoft.Tools.WindowsInstallerXml.Tools.Pyro.Run(String[] args)

Seems it is looking for some files on the build machine
('C:\Product\161\Atlanta\DailyBuilds\...), but every time we finish the
build, we copy the outputs to share folders like
\\rel\archive\
Isn't the old and new MSIs/wixpdbs contains all the binaries required? Why
it still requires the files on build machine? How could I make it look for
another folder (the shared folder) instead?

Thanks,
-Elfe


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MigrateFeatures with patch

[Blair]

Don't set REPAIR when applying the patch?

The default action when a patch is applied is to apply as few features as
possible based on the changed components. The only way a previously
not-installed feature is automatically added is when it and all of its
components are added by the patch.

A verbose log should tell you why you are getting features set to install
when you apply the patch.

Blair

-Original Message-
From: Christoph Vollmer [mailto:christoph.voll...@emendo.co.nz] 
Sent: Monday, May 09, 2011 4:21 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] MigrateFeatures with patch

Hi,

 

I'm following http://wix.sourceforge.net/manual-wix3/patch_building.htm
to create a patch, but while testing the patch I discovered, that it
didn't remember the feature settings from the original installation. I
found that there is a way via MigrateFeatures on UpgradeVersion, but
this seems to be the other patch process
(http://wix.sourceforge.net/manual-wix3/wix_patching.htm). Is there a
way to achieve my goal with the first approach?

Thanks,

  Christoph

 


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users]

[Blair]

Each byte in a GUID is NOT UNIQUE: there are guid versions, etc. of which
Office and the COM infrastructure make use of certain types of GUID that
most applications don't use to help avoid collisions.

Unless you are following the spec of how to build a GUID, I wouldn't
manufacture them that way.

In fact, your CoPr value would have to be constrained to ensure that you
don't create reserved or otherwise defined elsewhere GUID types.

Blair

-Original Message-
From: Aaron Klor [mailto:aaron.k...@gmail.com] 
Sent: Monday, May 09, 2011 7:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] [Wix-users]

We are considering defining our product codes for our different instances
with a bit more structure than the random GUID generation that is usually
recommended. We are considering this because we have to define a large
number of product code GUIDs for each product AND change them every time we
do a build. There is precedent for this sort of behavior (set by the
Micrsoft Office team, see
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\9014---
000FF1CE),
so we've decided to ask the list in order to hopefully gain some insight as
to whether this is considered "bad form" or if this might be acceptable.


For reference, we were considering something of this form:

{---CoPr-MaMiRvBildIn}

Where the X's are randomly generated GUID bits, but will be the same
throughout our products

The description of the rest of the fields are:

Co:  8-bit company code (human-readable, using A-F)

Pr:   8-bit product code (human-readable, using A-F)

Ma:  Major rev

Mi:   Minor rev

Rv:   Revision

Bild: Build number

In:Instance number


We understand that this significantly reduces the randomness of the GUID
(potentially removing the GU part of GUID), but given the manageability
gains, we feel that it might be worth it. It gives us the ability to easily
generate (and programmatically search for) up to 255 instances, allows for
revisions up to 255.255.255.65535, and can potentially simplify our WiX
authoring.


Obviously, this will cause problems in the case a GUID collision occurs
between our product and someone else's, but we find this highly unlikely
given that there are still 64 random bits in the GUID. I suppose the real
question is: is there something that we're missing? Might this sort of thing
affect things outside the ARP on Windows machines?


Thank you for your help,

Aaron Klor

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users]

[Blair]

And the set of  before the CoPr are not random values either, and you
will need to ensure that they don't conflict with the GUID specifications
either.

Blair

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, May 09, 2011 10:11 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [Wix-users]

Each byte in a GUID is NOT UNIQUE: there are guid versions, etc. of which
Office and the COM infrastructure make use of certain types of GUID that
most applications don't use to help avoid collisions.

Unless you are following the spec of how to build a GUID, I wouldn't
manufacture them that way.

In fact, your CoPr value would have to be constrained to ensure that you
don't create reserved or otherwise defined elsewhere GUID types.

Blair

-Original Message-
From: Aaron Klor [mailto:aaron.k...@gmail.com] 
Sent: Monday, May 09, 2011 7:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] [Wix-users]

We are considering defining our product codes for our different instances
with a bit more structure than the random GUID generation that is usually
recommended. We are considering this because we have to define a large
number of product code GUIDs for each product AND change them every time we
do a build. There is precedent for this sort of behavior (set by the
Micrsoft Office team, see
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\9014---
000FF1CE),
so we've decided to ask the list in order to hopefully gain some insight as
to whether this is considered "bad form" or if this might be acceptable.


For reference, we were considering something of this form:

{---CoPr-MaMiRvBildIn}

Where the X's are randomly generated GUID bits, but will be the same
throughout our products

The description of the rest of the fields are:

Co:  8-bit company code (human-readable, using A-F)

Pr:   8-bit product code (human-readable, using A-F)

Ma:  Major rev

Mi:   Minor rev

Rv:   Revision

Bild: Build number

In:Instance number


We understand that this significantly reduces the randomness of the GUID
(potentially removing the GU part of GUID), but given the manageability
gains, we feel that it might be worth it. It gives us the ability to easily
generate (and programmatically search for) up to 255 instances, allows for
revisions up to 255.255.255.65535, and can potentially simplify our WiX
authoring.


Obviously, this will cause problems in the case a GUID collision occurs
between our product and someone else's, but we find this highly unlikely
given that there are still 64 random bits in the GUID. I suppose the real
question is: is there something that we're missing? Might this sort of thing
affect things outside the ARP on Windows machines?


Thank you for your help,

Aaron Klor

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating patch / AssemblyFileVersion

[Blair]

Windows Installer (and by extension, tools that use/depend on it, such as
MsiMsp.exe/PatchWiz.dll & the WiX toolset) use the published versioning
rules published on MSDN. Those state that when FileVersion (aka
AssemblyFileVersion for those building managed modules/assemblies) exists in
a binary then that version and any language setting similarly set in the
native version resource (which is where AssemblyFileVersion is surfaced) are
the only things used to compare two files. "Unversioned" files are treated
differently, and by default a versioned file always updates a non-versioned
one.

The above is IMHO part of the reason that AssembyFileVersion and
AssemblyVersion are two separate values: if you change the content of the
assembly but require that other assemblies that bind to it will still bind,
you maintain the AssemblyVersion and rev the AssemblyFileVersion.
Conversely, if you change the interface or otherwise require a new binding,
you change both versions.

-Blair

-Original Message-
From: Christoph Vollmer [mailto:christoph.voll...@emendo.co.nz] 
Sent: Monday, May 16, 2011 10:48 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Creating patch / AssemblyFileVersion

Hi,

Is MSIMSP looking only at the AssemblyFileVersion of the files? I get a
patch that does not patching when the AssemblyFileVersion of original
and patched version are the same. Install log says for the most files
that only have new AssemblyVersion:
"MSI (s) (88:3C) [16:44:59:719]: The file represented by File table key
'ASSEMBLY.dll.AAA' has no eligible binary patches"
I did a change in one file to have something obvious. It says:
"...
MSI (s) (88:3C) [16:44:59:750]: Activating binary patch with sequence
10042 for file key EXECUTABLE.exe.
MSI (s) (88:3C) [16:44:59:750]: The file represented by File table key
EXECUTABLE.exe.' will be updated using the last binary patch and the
file on disk (if possible).
MSI (s) (88:3C) [16:44:59:750]: Chain for EXECUTABLE.exe.   starts
with the native source file.
MSI (s) (88:3C) [16:44:59:750]: Activating binary patch with sequence
10042 for file key EXECUTABLE.exe.
MSI (s) (88:3C) [16:44:59:750]: FALLBACK: The file represented by File
table key EXECUTABLE.exe.' will be updated using a chain of baseline
patches.
...
MSI (s) (88:3C) [16:44:59:763]: Baseline: EXECUTABLE.exe. not
touched in this transaction, verification required.
MSI (s) (88:3C) [16:44:59:763]: Baseline: Existing file
EXECUTABLE.exe. matches baseline from patch Native.
MSI (s) (88:3C) [16:44:59:763]: Caching EXECUTABLE.exe. from
C:\Program Files (x86)\COMPANY\ EXECUTABLE.exe for baseline 0
..."
The files does not get changed, although I really made a change to it.
Is there somewhere a thorough explanation how MSIMSP determines the
files to patch?
Thanks,
  Christoph


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] License and custom BA

[Blair]

IANAL and my overarching recommendation is that you consult with an attorney
that knows OSS licenses.

Having said that, here's my take: The license that WiX uses is a copy-left,
such that any change to the WiX sources must be available under the same
license. However, the BA you write isn't part of the WiX toolset (just as
the application you ship isn't part of the WiX toolset), and thus isn't
subject to that same license, but is instead subject to whatever license you
and your client agree to, within the framework established by the license
used by the WiX toolset you already agreed to.

Know that this is solely my opinion and does not bind the WiX toolset,
Microsoft Corporation, or any other party in any way. Talk to your attorney
before you rely on it.

-Blair

-Original Message-
From: Timo Viitaniemi [mailto:timo.viitani...@crosscontrol.com] 
Sent: Wednesday, May 18, 2011 3:31 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] License and custom BA

Hi!

To clarify the issue with myself (and my client). If I create my own BA
based on standard version (WixStdBootstrapperApplication), do I have to
share the code according to WiX license? If yes, in which proportions?
Including the application inside the installer??

BR,
Timo


--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Votive: Reference Properties

[Blair]

The project reference does two things:
1) It generates WiX preprocessor (candle) variables relating/referencing the
project:
http://wix.sourceforge.net/manual-wix3/votive_project_references.htm
2) If you set Harvest to True, it uses the Project Harvester (the "project"
argument to heat) to generate authoring during the build that is
incorporated into your product via the "". The DirectoryId is passed to the Heat tool via the -directoryid
argument and the "Project Output Groups" contains values that can be used
with the -pog argument. See http://wix.sourceforge.net/manual-wix3/heat.htm
for details on heat.

-Blair

-Original Message-
From: Andreas [mailto:andreassand...@gmx.net] 
Sent: Tuesday, May 24, 2011 10:22 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Votive: Reference Properties

Hello,

I hope I am here at the right place for this question.

I added a WiX project to a Visual Studio solution. Then I added a 
reference to the C# project in the same solution. In the properties of 
this reference I can see

- DirectoryId: INSTALLLOCATION
- Harvest: False
- Project Output Groups: BinariesContentSatellites

1) Can I harvest all files in the output directory of the C# project?
2) How do I add a reference to a 3rd party control, that is referenced 
in the C# project?
3) Where can I read about this reference thingy?

--
Andy



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installer with variable registry key

[Blair]

All three can be done, yet I do not recommend #3 at all (just don't do it).
Use Windows Installer properties to implement #1 would best meet your goals.
If you don't put any condition on the custom action you use to generate your
properties, it will run every time (install, remove, repair, upgrade,
everything). Make sure your custom action is an immediate custom action so
that it can set the properties. Know that immediate custom actions are not
normally elevated, so hopefully you can read Excel's registry key without
requiring elevation.

-Blair

-Original Message-
From: Miles Waller [mailto:miles.wal...@gmail.com] 
Sent: Thursday, May 26, 2011 6:53 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Installer with variable registry key

Hi,

I'm writing an installer for an excel addin.  In order to register the
addin, with excel, I need to add an entry under a registry key.  The entries
are named OPEN, OPEN2, OPEN3 ... sequentially for each addin that is
registered.

Because many addins could have been installed by the user before the
installer runs, and also the user could remove some other addin (which
causes excel to rewrite the registry entries so they are still sequential
with no gaps), then go to uninstall my addin, the names of the entries in
the registry need to be determined at install time, which I will do in a
custom action.

What's the cleanest way to do this, to ensure uninstall and rollback all
work properly?  I considered the following:

 1. run an immediate action which examines the registry and sets a property
with the entry name that will be used; this property can then be used by a
normal registry action within wix;
 2. run an immediate action which examines the registry and inserts rows in
the "registry" table so that when the install actually runs, it will insert
the correct key;
 3. run a deferred action that does all the checking and adds the registry
entries in one place.

I was aiming to do as little as possible in the custom action, and keep as
much in the xml as possible, but it does seem to be an uphill struggle...!

Last of all, in the uninstall sequence, do immediate actions get to run (and
if so, when) or would 1 or 2 above not work simply because they never get
fired.

Thanks,

Miles

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setup for client/server application

[Blair]

WiX's  element can copy arbitrary files to arbitrary directories.
You can reference the installation MSI via the OriginalDatabase Windows
Installer property.

-Blair

-Original Message-
From: Michael Stoll [mailto:unwicht...@mistoll.de] 
Sent: Thursday, May 26, 2011 5:23 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Setup for client/server application

I'm using WIX 3.6 with burn for deploying a client/server application. 
On the server there's a file share for the client setup files. Thus the 
server setup routine should copy the setup files for the client to this 
file share.
Is there a best practice for solving such a setup scenario?
Currently there are two msi packages. One for the client and one for the 
server. The server contains the client package as file. But I'd like to 
have a single setup file, which allows me to select if it should install 
the client or the server. So the file would have to copy itself to the 
client setup share. Any thoughts on this problem?



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Unable to execute SQL script from patch msp

[Blair]

Explain "not included in the patch", because I have three very different
ideas that you could be referring to.

1) Is this based on opening the MSP file in Orca?
2) Was there an error when applying the patch to an already installed
product?
3) Are you referring to running SQL against the MSP file itself?

-Blair

-Original Message-
From: Nangai [mailto:thangananga...@iinterchange.com] 
Sent: Thursday, May 26, 2011 5:04 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Unable to execute SQL script from patch msp

Hi,

I am using Wix 3.5.2519.0 to create patch. I am unable to execute SQL script
from patch. I am adding reference to the binaty stream of SQL file in patch.
But the binary is not included in the patch.

Thanks in advance.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unable-to-exec
ute-SQL-script-from-patch-msp-tp6406736p6406736.html
Sent from the wix-users mailing list archive at Nabble.com.


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] IUSR

[Blair]

What does a verbose log say? If you are not certain as to the value of your
IUSR_USERNAME property, it will be hard to verify that what account was
given write access to your file.

-Blair

-Original Message-
From: gapearce [mailto:mr_gapea...@yahoo.com] 
Sent: Wednesday, May 25, 2011 12:42 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] IUSR

I'm trying to set permissions on a file like this, using WiX 3.5:

  

  
  
  
  

  

And after install I don't see any explicit permissions for [IUSR_USERNAME],
(which should resolve to NT_AUTHORITY/IUSR on my Windows 7 box, I think). 
Network Service and administrators and Users are there, correctly.

What Am I doing wrong here?

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/IUSR-tp6404206
p6404206.html
Sent from the wix-users mailing list archive at Nabble.com.


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How do i change the default permissions of a certificate installed by wix.

[Blair]

There is not current code in WiX to set arbitrary permissions on
certificates installed via WiX.

If someone can dig up the APIs used to set permissions on certificates, that
could be added 

-Blair

-Original Message-
From: Will Gross [mailto:mastermind...@gmail.com] 
Sent: Wednesday, May 25, 2011 8:59 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How do i change the default permissions of a
certificate installed by wix.

Related to my post yesterday, it is clear i'm getting the keyset does not
exist exception due to the permissions set by wix.  So my question is, is
there a way to set a certificate with predefined permissions somewhere in
.wxs file somewhere? (or elsewhere)

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Votive: Reference Properties

[Blair]

Heat "out-of-the-box" does not currently gather project's dependencies. That
is currently a manual task. There was a recent thread on this email list
discussing the difficulties with automatically gathering
dependencies/references.

-Blair

-Original Message-
From: Andreas [mailto:andreassand...@gmx.net] 
Sent: Friday, May 27, 2011 10:54 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Votive: Reference Properties

Hello Aaron,

I assume this is an answer to the question (3). Thanks for the reference to
http://wix.sourceforge.net/manual-wix3/votive_project_references.htm

But I didn't ask for a reference from the WiX project to any other 
project in the Visual Studio solution. What I need is the installation 
of a 3rd party windows forms control, that is used in the windows forms 
application. When building the installer for the application I want to 
gather the the referenced assemblies and add them to the installer. How 
can this achieved?

--
Andy


Am 26.05.2011 13:26, schrieb Aaron Klor:
> Do a google search for "wix project references" make sure you are directed
> to the appropriate version of the wix doc (wix 3, for example), then
> bookmark it. I have referred to that page many times.
> On May 26, 2011 3:10 AM, "news.gmane.com"  wrote:
>> Does anybody has a suggestion?
>>
>>
>> "Andreas"  wrote in message
>> news:irgpfi$7pn$1...@dough.gmane.org...
>>> Hello,
>>>
>>> I hope I am here at the right place for this question.
>>>
>>> I added a WiX project to a Visual Studio solution. Then I added a
>>> reference to the C# project in the same solution. In the properties of
>>> this reference I can see
>>>
>>> - DirectoryId: INSTALLLOCATION
>>> - Harvest: False
>>> - Project Output Groups: BinariesContentSatellites
>>>
>>> 1) Can I harvest all files in the output directory of the C# project?
>>> 2) How do I add a reference to a 3rd party control, that is referenced
>>> in the C# project?
>>> 3) Where can I read about this reference thingy?
>>>
>>> --
>>> Andy
>>>



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How do i change the default permissions of a certificate installed by wix.

[Blair]

You need to create a "Pull Request" from your fork.

-Original Message-
From: Michael Stoll [mailto:unwicht...@mistoll.de] 
Sent: Monday, May 30, 2011 11:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How do i change the default permissions of a
certificate installed by wix.

Just added it. 
(http://wixcontrib.codeplex.com/SourceControl/network/Forks/mistoll/WixIssEx
tension)

Michael

Am 28.05.2011 02:38, schrieb Blair Murri:
> It's not dead, it just hasn't been updated in a very long time.
>
> Go ahead and add it there and I will poke Rob/Bob to review it.
>
> -Blair
>
>> Date: Fri, 27 May 2011 11:01:02 +0200
>> From: unwicht...@mistoll.de
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] How do i change the default permissions of a
certificate installed by wix.
>>
>> I've written a wix extensions, which is able to install certificates and
>> set permissons. I'd be pleased to share this extension "as is". Is there
>> a common place where extensions can be shared, like
>> http://wixcontrib.codeplex.com/, which seems to be dead.
>>
>> Michael
>>
>> Am 27.05.2011 07:09, schrieb Blair:
>>> There is not current code in WiX to set arbitrary permissions on
>>> certificates installed via WiX.
>>>
>>> If someone can dig up the APIs used to set permissions on certificates,
that
>>> could be added
>>>
>>> -Blair
>>>
>>> -Original Message-
>>> From: Will Gross [mailto:mastermind...@gmail.com]
>>> Sent: Wednesday, May 25, 2011 8:59 AM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: [WiX-users] How do i change the default permissions of a
>>> certificate installed by wix.
>>>
>>> Related to my post yesterday, it is clear i'm getting the keyset does
not
>>> exist exception due to the permissions set by wix. So my question is, is
>>> there a way to set a certificate with predefined permissions somewhere
in
>>> .wxs file somewhere? (or elsewhere)
>>>

>>> --
>>> vRanger cuts backup time in half-while increasing security.
>>> With the market-leading solution for virtual backup and recovery,
>>> you get blazing-fast, flexible, and affordable data protection.
>>> Download your free trial now.
>>> http://p.sf.net/sfu/quest-d2dcopy1
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>>

--
>>> vRanger cuts backup time in half-while increasing security.
>>> With the market-leading solution for virtual backup and recovery,
>>> you get blazing-fast, flexible, and affordable data protection.
>>> Download your free trial now.
>>> http://p.sf.net/sfu/quest-d2dcopy1
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>
>>

--
>> vRanger cuts backup time in half-while increasing security.
>> With the market-leading solution for virtual backup and recovery,
>> you get blazing-fast, flexible, and affordable data protection.
>> Download your free trial now.
>> http://p.sf.net/sfu/quest-d2dcopy1
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>   
>

--
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing

Re: [WiX-users] upgrade install errors

[Blair]

Case matters in ALL properties. The only place in conditions where case does
not matter are the keywords (e.g. NOT/AND/OR can be any case).

The last number is ignored when used in the Upgrade table (where the
comparison is made with the ProductVersion value), but that table is
completely ignored when using small updates/minor upgrades (such as when
using MSP) unless you use your own custom action to parse that table (in
which case you can do whatever you want). No other version number parts are
ignored (file versions always use all four parts).

When using MSPs you can use sequencing, which uses all four numbers (none
are ignored) of the patch sequence number, to achieve upgrading and prevent
downgrading.

Blair

-Original Message-
From: Justin Hull [mailto:justin.h...@assetpoint.com] 
Sent: Tuesday, November 15, 2011 12:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] upgrade install errors

Perhaps a final question.  Does Upper Case lower case matter when using
internal properties.  For example:
Installed vs INSTALLED
UILevel vs UILEVEL

I ask because a condition I set up to get around an INI write I wrote as
UILEVEL > 3 and it still tried to execute the component on a /passive
upgrade.  I found that I could use NOT Installed to detect if something was
installed before, but does that work for an Upgrade.  I installed 8200, I
want to upgrade to 8201 with an msp.  The company version numbers are in the
form x.x.x.x (eg 8.2.0.0).  The upgrade is numbered 8.2.0.1, but from what
I've read it seems the installer ignores the last number.

Justin Hull


Office: 864-679-3500 (3413)



-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Tuesday, November 15, 2011 9:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] upgrade install errors

UILevel
http://msdn.microsoft.com/en-us/library/aa372096%28v=VS.85%29.aspx

Don't forget that in passive mode, the InstallUISequence doesn't run. If
there's anything in there setting the properties, it may need repeating in
or moving to the execute sequence. Or set a default when the property is
blank.

During installation, you should "persist" the property values and during
repair and other maintenance modes, reread them, if you aren't already.

-Original Message-
From: Justin Hull [mailto:justin.h...@assetpoint.com]
Sent: 15 November 2011 13:48
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] upgrade install errors

I believe I discovered the issue.  In the project I have a section that
writes to an INI file details gathered in a normal install (see below).

When I perform a full install or on upgrade I select a modify action, the
upgrade works fine.  However, when I run the msiexec in /passive, I get this
error.  What I see happening is that the WIX "code" has a variable for
section name.  In passive mode the one condition that is not checking for
blanks allows for the component to be processed yet the section name is
blank.  I figure a no no in MSI.

What I would like to do is alter the condition to determine if I am running
in /passive or below (silent) and not execute those components.  If anyone
knows of a property that I can check please let me know.  I believe I can
check MsiSetInternalUI.  If successful I will post my solution, but I am
open to other options.
---








DBTYPE=1 AND INSTALLMODE <>
"Repair"














-
-
Justin Hull


Office: 864-679-3500 (3413)



-Original Message-
From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
Sent: Monday, November 14, 2011 8:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] upgrade install errors

The MSI documentation says that error 2109 mean "Section missing for .ini
action"
http://msdn.microsoft.com/en-us/library/aa372835(v=VS.85).aspx

There is probably a note higher up in the log that can tell you more detail
or at least the exact step

-Original Message-
From: Justin Hull [mailto:justin.h...@assetpoint.com]

Re: [WiX-users] Getting error on writing INI section using addline

[Blair]

You will notice if you follow the WiX documentation that the IniFile element
writes rows into the IniFile table. If you check the MSDN documentation you
will find that the RemoveIniValuesAction removes data from the ini files
when the associated components are removed. Thus, you need to have the
properties you reference in your IniFile elements have the same values
during uninstallation as they had during the previous installation.

So, in your case, you will need to preserve the values of DATABASE_DISPLAY1
& DATABASE_DISPLAY2 and restore those before RemoveIniValues (I would
recommend restoring them sometime before InstallInitialize).

When components are not transitive, component conditions are only evaluated
when the feature containing the component is added/installed. When all
features containing that component are removed, the component is removed
(the condition isn't evaluated at that point). In a major upgrade, if the
component doesn't exist in the upgrading product, it will also be removed
(without respect to any component conditions). If you made the components
transitive, then the components would be evaluated every single transaction,
and would possibly be installed if the condition is true and uninstalled if
the condition is false, so component conditions WILL NOT HELP YOUR SCENARIO.
You need to preserve/restore the values of the referenced properties for
your UI-less maintenance transactions to work.

I believe Peter Shirtcliffe already mentioned preserving/restoring those
properties in your previous topic.

Blair

-Original Message-
From: justin hull [mailto:justin.h...@assetpoint.com] 
Sent: Tuesday, November 15, 2011 2:48 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Getting error on writing INI section using addline

I am posting this as a different topic for I got the answers I needed from
the other post regarding basic msp stuff.  I've narrowed down the specific
problem I am having with my upgrade.

The project (Attached) has a section that writes UI data (from a custom
window) to an INI file.








(DBTYPE = 2 AND (DATABASE_NAME
<> "" AND DATABASE_NAME <> " " ) ) AND UILevel >
3












When the install is run as a full UI install the custom window appears, data
is entered, the ini file is written to and all is well.

When an upgrade is created (or I try an full install in passive mode) and
run in /passive I get a 2109 error on this component.  The error states:

MSI (s) (08:34) [17:02:57:968]: Product: TabWare Xi 8.201 -- The installer
has encountered an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2109. The arguments
are: , , 

What seems to be happening is that since there is no user input, the "code"
that attempts to create a section with user data fails.  If I run the
upgrade with a UI it will work, but then the uninstall fails.  Hard code
something and it may work, but that is not a reasonable option.

I already altered the condition to test for UILevel and that did not work, I
still get the error.  I wonder if installer tries to resolve the section
name before testing the condition?  Time constraints and skill effect me
trying to write a custom action at this time.

What I am trying to do is understand why my condition wont work and is there
an internal property value I can use that will allow the installer to skip
over these components.  I got everything else to work, but this condition. 
(I inherited this project, starting from zero knowledge last month).  I
included the project and the log file.  I hate to be a bother, but time
constraints were placed that limit my options.  Any help is greatly
appreciated.

Justin

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n6998261/
TabWareXi8201_ini.wxs
TabWareXi8201_ini.wxs 

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n6998261/
install8201.log
install8201.log 


--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Getting-error-
on-writing-INI-section-using-addline-tp6998261p6998261.html
Sent from the wix-users mailing list archive at Nabble.com.


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_

Re: [WiX-users] Enable/disable "Next" button

[Blair]

 element?

-Original Message-
From: AxiomaticImpact [mailto:ke...@legendary-immersion.com] 
Sent: Tuesday, November 15, 2011 2:11 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Enable/disable "Next" button



--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Enable-disable
-Next-button-tp6998152p6998152.html
Sent from the wix-users mailing list archive at Nabble.com.

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] util:RemoveFolderEx with condition?

[Blair]

The only clean ways I am coming up with involve various schemes to force the
component containing that RemoveFolderEx element to remain "installed" (and
presumably orphaned) when the product containing it is removed. Does anyone
else want to weigh in with ideas on that theme?

Blair

-Original Message-
From: thomas.debo...@rohde-schwarz.com
[mailto:thomas.debo...@rohde-schwarz.com] 
Sent: Tuesday, November 15, 2011 7:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] util:RemoveFolderEx with condition?

Hi,

I'm just working on a task where I have to cleanup a folder where the
application will create files and folders during runtime.

There for I've added a RemoveFolderEx element.  This works fine so far, but for
one folder the user should be able to set in a dialog if this folder should
be deleted or not.
For this I set a property based on a checkbox.

Now I can't find a way how to set a condition based on my property to the
RemoveFolderEx element.

Is it possible or do I work into the wrong way?

Cheers,
  Thomas

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Getting error on writing INI section using addline

[Blair]

>From the point of view of the installation sequence, user input from custom
forms and command line are the same thing.

Blair


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem with file association and harvesting files

[Blair]

Add a transform to heat's commandline that adds the Verb.

-Original Message-
From: Peter Bulyaki [mailto:peter.buly...@gmail.com] 
Sent: Monday, November 21, 2011 8:27 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Problem with file association and harvesting files

Hi,

I have a project in which all files are harvested recursively from a single
source folder. I would also like to add a file association to this project
as below:











The problem with this is that the file referenced as $(env.MAIN_EXECUTABLE)
has already been harvested by heat, and there is already a File element
pointing to it. So I get the following error:

error LGHT0204: ICE30: The target file '.' is installed in
'[ProgramFilesFolder]\\\bin\' by two different components on an LFN
system: 'FileAssociation' and 'cmpEC461 517D65363F29020E8A217A316F4'. This
breaks component reference counting.

Is there any other way to tell the Verb element which file we are talking
about?

Peter

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity, and more. Splunk takes this data and makes sense of it.
IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] add reference to C++ project

[Blair]

Daniel,

How many WXS files cause VS2010/MSBuild to croak? I haven't seen that.

Blair



--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] questions about upgrading to a stable wix version

[Blair]

The only versions I have seen released are 2.0, 3.0, 3.5, and the Beta of 3.6.

1) DifxApi
I don't see Difx in 2.0 (I thought it was in there, it may be, I'm just not 
seeing it, but 2.0 is quite old and not supported any longer). The version in 
3.0 and the later 3.x releases is different, there was a discussion about some 
of the differences at the time it was updated (would have been about a year ago 
if memory serves).

2) WYSIWYG
WiX/Votive doesn't have WYSIWYG for MSI dialog creation. There are some third 
parties that have done this. IIRC, Rob M blogged about some of them a couple of 
times (search his blog for WYSIWYG). I'm sure the team would appreciate one 
contributed if anyone is ambitious enough to write one. There are enough 
deficiencies in Windows Installer's GUI that I usually recommend either 
external UI via bootstrapers (such as Burn) or embedded UI (which has other 
deficiencies) as workarounds.

3) Orca validation
"Full MSI Validation Suite" is the highest degree of validation for MSI files. 
The "Logo" validation suites are subsets of "Full". Also, AFAIK the latest 
version of Orca is 5.0.7069.0 from Windows SDK 7.1.

4) SelectionTree
The feature selection tree is part of Windows Installer/MSI and that behavior 
is not customizable.

5) Errors in MSI logs
Errors surface in MSI logs at the point where you find the translated 
equivalent of "Return value 3". From that point, backtrack in the log up to the 
cause of the error. 
(http://msdn.microsoft.com/library/windows/desktop/aa369778.aspx)

6) Mutually exclusive (opposite) conditions
My best advice is a pattern:
= 2) Or 
(VersionNT = 502 And ServicePackLevel >= 1) Or (VersionNT >= 600)) And Not 
EXISTINGPRODUCTS"?>

  $(var.MyEnableCondition)
  NOT ($(var.MyEnableCondition))


7) Stable release
Right now 3.5 was RTM about 9 months ago, and 3.6 was declared Beta almost a 
month ago.

Your welcome,
Blair

-Original Message-
From: Calin Iaru [mailto:ca...@dolphinics.no] 
Sent: Thursday, November 17, 2011 3:11 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] questions about upgrading to a stable wix version

Hi,

  We’ve been compiling with 2.4 for a long time we are considering upgrading to 
the latest 3.6 version. I would appreciate if you could answer these questions:

1) 3.6 plays nice with DifxApi. The SW stack contains drivers that have to be 
installed and upgraded. I have custom actions that are triggered before and 
after installing drivers and everything has to be smooth. Ideally, it should 
offer the possibility to Force Repair when installing the drivers, something 
that 2.4 cannot.

2) 3.6 comes with a graphical editor for dialogs. I would like a WYSIWYG editor 
that can generate the proper WXS syntax. With 2.4, I use a bitmap as a white 
background and then have to cut it around checkboxes.

3) This q is not related to WIX, only to MSI: I am using Orca to validate the 
database. I looked at the version – the file is as recent as 2009 - and I would 
like to know if there are new ICEs or cub files that can be executed against 
the MSI. The highest validation is for Windows Vista Logo – is this the most 
severe level?

4) The SelectionTree control looks legacy. I would like an ST that just checks 
and unchecks without asking “Install from Source”, “Always install from Source” 
from a drop-down menu.

5) Sometimes, the logs taken after installing MSI /l*xv log.txt contain error 
messages like this:
SELECT `Message` FROM `Error` WHERE `Error` = 1707 However, the precise source 
is not known. I would like a stack or a more granular context around this 
error. And some errors can be ignored because the installation does not fail.
Regarding the request for a richer context around error messages, I expect that 
this is a feature offered by the OS. If 3.6 can do anything about it, then even 
better!

6) Certain conditions need both the true and false cases. I would like to have 
only the true case specified, and WIX generate the rest for me.














1



7) What is the most stable version and when is the next stable version 
scheduled for release? I assume that there are no problems writing WIX code and 
compiling MSIs for XP to 7.

Thank you for taking the time to answer these questions.

Calin
--
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security threats, 
fraudulent activity, and more. Splunk takes this data and makes sense of it. IT 
sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
All the data continuously generated in

Re: [WiX-users] Wix bug #1908338 regression in WiX 3.6?

[Blair]

I would say that your use of  is unrelated to the
"Unresolved reference" error, except for the following: The "Undefined
preprocessor" error comes from candle, and the "Unresolved reference" error
comes from light, and since candle runs before light, that error stops the
build before the other error could ever surface.

Are you harvesting your C# projects from your WiX project? How are you
"handcrafting" your references? What settings/properties have you set wrt
your harvesting?

That is where I would start my investigation.

Blair

-Original Message-
From: David P. Romig, Sr. [mailto:d...@tcsc.com] 
Sent: Thursday, November 24, 2011 7:17 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix bug #1908338 regression in WiX 3.6?

Bob,

Thanks for your reply, but the problem is not related to the DDK or C++
projects.  The DDK and C++ project setup is handled separately through
hand-crafted references in their respective .wks files.  Under WiX 3.5 this
project built successfully using the same .wxs and .wixproj files.

With WiX 3.6, when the element is 'False' or
omitted, an IDE build or command line solution build raises the error
"Unresolved reference to symbol 'WixComponentGroup:.Binaries' in section 'Fragment:'. D:\Projects\
trunk\src\app\Deployment\WixSetup\.wxs" for each of the
dozen C# modules referenced in the .wixproj file.

When the element is 'True', an IDE build or
command line solution build raises the error "Undefined preprocessor
variable '$(var.SolutionDir)'.
D:\Projects\trunk\src\app\Deployment\WixSetup\PrinterManager.wxs"
PrinterManager.wxs is the only project file containing a reference to the
$(var.SolutionDir) variable.

Could this be an issue in the wix2010.targets file?

Thanks,
Dave

Date: Wed, 23 Nov 2011 22:56:44 -0500

From: Bob Arnson 

Subject: Re: [WiX-users] Wix bug #1908338 regression in WiX 3.6?

To: wix-users@lists.sourceforge.net

Message-ID: <4ecdc07c.2070...@joyofsetup.com>

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 

On 23-Nov-11 18:31, David P. Romig, Sr. wrote:

> After installing WiX 3.6 beta, I'm receiving the error as described in

> bug report 1908338.  Is this a regression?

 

That bug is about what happens when the values aren't defined (i.e., 

CNDL0150).

 

 

> The solution contains 12 C# projects, a DDK project in C and a couple

> C++ projects in addition to the WiX project.  The build environment is

> Visual Studio 2010 version 10.0.31118.1 SP1Rel.

 

How is your C project built? WiX only supports project reference 

variables for MSBuild projects, so a Makefile project wrapping a DDK 

dirs/sources project won't work.

 

-- 

sig://boB

http://joyofsetup.com/

--

The WiX-devs archive lists failure to resolve "$(var.SolutionDir)" as bug
1908338.

After installing WiX 3.6 beta, I'm receiving the error as described in bug
report 1908338.  Is this a regression?

Light raised the error "LGHT0094: Unresolved reference to symbol
'WixComponentGroup:Utilities.IO.Binaries' in section 'Fragment:'" for each
ComponentGroupRef and the warning "  C:\Program Files
(x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets(1226,5): warning :
Solution properties are only available during IDE builds or when building
the solution file from the command line. To turn off this warning set
false
in your .wixproj file.
[D:\Projects\trunk\src\app\Deployment\WixSetup\WixSetup.wixproj]".

So in the initial PropertyGroup of the wixproj file I added the element
definition "False".
While this resolved the LGHT0094 error, the WiX project now fails to build
with the error "error CNDL0150: Undefined preprocessor variable
'$(var.SolutionDir)'."

The solution contains 12 C# projects, a DDK project in C and a couple
C++ projects in addition to the WiX project.  The build environment is
Visual Studio 2010 version 10.0.31118.1 SP1Rel.  

How can I use the project references and variables as listed in the
documentation?

Regards,
Dave

 


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity, and more. Splunk takes this data and makes sense of it.
IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activi

Re: [WiX-users] CreateFolder is not creating required directory structure ...

[Blair]

Marcus,

A couple general comments, then some specifics.

1) Whenever unexpected things happen, redo the transaction generating a
verbose log. In your case, you need to look at the values for each of your
directories AND look at the log spew related to the CreateFolders action
(both where it is scheduled and where it is executed).

2) Generally you don't need to both reference a built-in UI fragment AND
copy that modified fragment.

3) You place some directories under ProgramFilesFolder and others under
AppDataFolder. Some of those directories you create have their paths
overridden by properties being set, and others don't. I suspect you ARE
creating those directories, just not where you think you are. Please review
your entire directory tree.

Blair


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CreateFolder is not creating required directory structure ...

[Blair]

The WiX documentation itself has a page on logging:
 How To Guides\Others\Get a log of your installation for debugging

The online version of that page is here:
http://wix.sourceforge.net/manual-wix3/get_a_log.htm

It is instructive to read the logs sequentially as it allows you to see the
flow that the engine takes and the timing of the setting of different
values/properties.

When I looked at your source code, here is the hierarchy I saw (shown as
identifier\name of folder under parent):

TARGETDIR\SourceDir - Required "root" of the hierarchy
ProgramFilesFolder - Initial path is set by MSI - does not use its
parent
OneSpatial\1Spatial
INSTALLDIR\dam
ComDir\com
ConfigDir\config
ExeDir\exe
AppDataFolder - Initial path is set by MSI - does not use its parent
OneSpatialAppData\1Spatial
GOTH_DATAROOT\data
GOTH_DAM\dam
GOTH_DAM_LOG\log
GOTH_LIC\lic
GOTH_ODBD_SORT\sort
GOTH_OBDB_ROOT\odbd
GOTH_ODBD_CONFIG\config
GOTH_ODBD_DEFAULT\default
GOTH_ODBD_HISTORY\history
GOTH_ODBD_LOCK\lock
GOTH_ODBD_OBJIDX\objidx
GOTH_ODBD_OBJECT\reg

Directory identifier values are session properties. If those properties
exist before the CostFinalize, the corresponding values are used for those
directories. Properties are then created for each directory to reflect each
of their paths, so that they can be used in other tables or CAs and/or
verified in CAs/logs.

Assuming that NO properties are passed on either the installation
command-line or via the build system, and assuming a 32-bit Windows 7
"standard" installation (AppDataFolder is in a different location on XP and
downlevel), this is my quick determination of where I expect your MSI to
place each of the above directories when the product was not previously
installed and no properties are passed in via the command line nor changed
by the UI:

TARGETDIR = root folder of hard drive with the largest free space at time of
installation
ProgramFilesFolder = C:\Program Files\
OneSpatial = C:\Program Files\1Spatial\
INSTALLDIR = C:\Program Files\1Spatial\dam\
ComDir = C:\Program Files\1Spatial\dam\com\
ConfigDir = C:\Program Files\1Spatial\dam\config\
ExeDir = C:\Program Files\1Spatial\dam\exe\
AppDataFolder = C:\Users\\AppData\Roaming\
OneSpatialAppData =
C:\Users\\AppData\Roaming\1Spatial\
GOTH_DATAROOT = $(env.SystemDrive)\1Spatial\data\
GOTH_DAM = $(env.SystemDrive)\1Spatial\data\dam\
GOTH_DAM_LOG = $(env.SystemDrive)\1Spatial\data\dam\log\
GOTH_LIC = $(env.SystemDrive)\1Spatial\data\lic\
GOTH_ODBD_SORT = $(env.SystemDrive)\1Spatial\data\sort\
GOTH_OBDB_ROOT = $(env.SystemDrive)\1Spatial\data\odbd\
GOTH_ODBD_CONFIG = $(env.SystemDrive)\1Spatial\data\odbd\config\
GOTH_ODBD_DEFAULT = $(env.SystemDrive)\1Spatial\data\odbd\default\
GOTH_ODBD_HISTORY = $(env.SystemDrive)\1Spatial\data\odbd\history\
GOTH_ODBD_LOCK = $(env.SystemDrive)\1Spatial\data\odbd\lock\
GOTH_ODBD_OBJIDX = $(env.SystemDrive)\1Spatial\data\odbd\objidx\
GOTH_ODBD_OBJECT = $(env.SystemDrive)\1Spatial\data\odbd\reg\

*NOTE: $(env.SystemDrive) is the root folder of the system drive of the
system building the MSI file, NOT the system installing the MSI. While most
Windows 7 installations use a system drive value of C:\, that is by no means
universal and is NOT required on any version of Windows as far as I know.
The corresponding MSI property would be [WindowsVolume], which already
contains the backslash, if you need the corresponding path on the system you
are installing on.

Note that all identifier names that are in all CAPS can be placed anywhere
by whomever installs your MSI, (parent/sibling relationships do not have to
be honored), so if there are any required sibling relationships, the
corresponding identifiers should not have been made public (all CAPS).

Compare the above expected values with the values found in the verbose log,
and investigate where/how those values are set. Also, check the action
states of all components containing CreateFolder elements.

Blair

-Original Message-
From: mat_macwilliam [mailto:marcus.macwill...@1spatial.com] 
Sent: Wednesday, November 30, 2011 2:18 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CreateFolder is not creating required directory
structure ...

Blair,

I am a complete novice to this. The person who originally wrote our XML is
no longer at the company.
How do I get complete logging information out of the MSI when it is run?

Incide

Re: [WiX-users] How to use Burn to install new and minor upgrade

[Blair]

If you are strictly following the component rules, consider that during
Major Upgrades with late scheduling of RemoveExistingProducts the following
scenarios hold:

- Upgraded components will be installed without removal of the obsoleted
version of those components.
- Unchanged components will be ignored/left alone by the upgrade.
- IIRC, if you don't explicitly change any directory paths, already existing
components will preserve their directories.
- You can retrieve any already existing component's directory and set one of
your directories to that location, thus preserving your customer's previous
choices
- You can still offer a different set of dialogs during upgrades than during
initial installs.

One technique I have seen is to install a service EXE that simply loads a
DLL containing the service implementation. You update the DLL as needed
between builds, and simply ship the same EXE binary in all builds. That way,
you can update the code of the service while not having to reinstall the
service on each upgrade.

-Blair

-Original Message-
From: Michael Janulaitis [mailto:wix-u...@cornerbowl.com] 
Sent: Wednesday, November 23, 2011 11:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to use Burn to install new and minor upgrade

I've been at this for a few days now and it seems there is no way to create
a bootstrapper that correctly launches msiexec for new installs and minor
upgrades.  Everyone seems to say not to use minor upgrades and instead do a
major upgrade (then this wouldn't be a problem) but that is realistically
not a user friendly option.  First my installs install windows services
which typically require domain admin credentials.  Next many of my customers
install to non-standard folders.  So if I force a major upgrade then the
users have to reset both the windows service credentials and possible keep
re-pointing to their non-standard install directory.  Installs are released
weekly...not an option.  So is my only solution InstallShield?  It seems so.
Please someone prove me wrong.  
Someone has to have tackled this problem.



--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity, and more. Splunk takes this data and makes sense of it.
IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Is major update supposed to duplicate the add/remove programs entry?

[Blair]

To be a major upgrade the RemoveExistingProducts action must be
scheduled/run.

-Original Message-
From: Robert Lee [mailto:genrobert...@gmail.com] 
Sent: Wednesday, November 30, 2011 3:12 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Is major update supposed to duplicate the add/remove
programs entry?

I would like to develop an installer so that it would NOT force the user to
uninstall the application manually prior to installing new version. Just
running the new msi should update everything automatically.
As far as I understood the wix book, in order to achieve that, I should set
product ID in the markup to "*", keep the upgrade code, and increase version
number. But when I run the new msi, a new entry is added to add/remove
programs. How to prevent that?

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity, and more. Splunk takes this data and makes sense of it.
IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditions in merge modules

[Blair]

WiX exposes (for the most part) all of the power of native Windows
Installer. LaunchConditions are exposed by the Condition elements under the
Product and Fragment elements and result in entries into the LaunchCondition
table (http://msdn.microsoft.com/library/aa369752.aspx) which is processed
by the built-in LaunchConditions action
(http://msdn.microsoft.com/library/aa369751.aspx).

According to http://msdn.microsoft.com/library/aa369823.aspx merge modules
can't supply LaunchCondition table rows. However, they can supply what are
known as Type 19 custom actions.

In WiX, type 19 custom actions are created by supplying the Id and Error
attribute values to the CustomAction element, and then scheduling that
action with one or two instances (usually two, one under the
InstallIUSequence element and the other under the InstallExecuteSequence
element) of the Custom element.

-Original Message-
From: Ken Halprin [mailto:khalp...@autosoln.com] 
Sent: Wednesday, December 09, 2009 11:58 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Conditions in merge modules

To get a feel for how wix works, I created an installer project which
produces an .msi file. It includes conditions at the Product level (are
those launch conditions?) that check for os version and .net version,
exiting the install if the condition is not met.  I'll convert that project
into a merge module project and would like to do the same checks. Would I
need to put the condition checks on each feature to be installed?



-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, December 09, 2009 12:38 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Conditions in merge modules

Are you talking about LaunchConditions, Feature conditions, or Component
conditions?

You can't "isolate" your merge module parts in a final MSI very easily, but
you should be able to condition any/all of your components and/or custom
actions your merge module contributes.

-Original Message-
From: Ken Halprin [mailto:khalp...@autosoln.com] 
Sent: Wednesday, December 09, 2009 10:08 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditions in merge modules

I'm creating a merge module for inclusion in another company's msi package.
It does not appear to be possible to put conditions (such as checking
operating system version or .net installed version) in the merge module.
How is that generally handled?

 

Thanks.


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to specify files in Installer package

[Blair]

Two ideas that come to mind: One is to use msbuild to call heat (or some
other system that can calculate a list of files given an exclusion pattern)
and the other is to write an extension to heat.

-Original Message-
From: Markus Gaugusch [mailto:w...@gaugusch.at] 
Sent: Wednesday, December 09, 2009 12:56 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to specify files in Installer package

Hi Blair!

Those directories contain many files and I don't want to specify them by
hand. 
And if I want to ignore .svn directories, I'm fully out of luck.
Additionally, I tried to split up my project into several trees like that:
- framework\bin (common binary files, xml schema, ...)
- framework\config (common config files)
- frameworkexe\bin (common executables)
- project\bin (project specific xml files, config files ...)
- project\config (project specific configuration files)
- projectexe\bin (project specific exe files)

They should all go into ...\bin and ...\config on the destination machine.
Unfortunately, the "bin" and "config" directories would conflict when I run 
light.exe because they have the same name and heat generates the same
component 
id for both of them (which is ok because they are he same directory on the 
destination machine). If I could tell heat to use an existing reference for 
some directories and create the others, it might also work, but I think this
is 
not a clean solution.

So, if I want to use heat.exe, I need to use a single tree of source files
or 
split my project into parts that have no common directories at all (which
does 
not meet my requirements).

To solve my problems I can only imagine to use a single source tree for the 
installer package and tell heat to ignore certain files and take all others.
Or 
do you have a better idea?

Thanks!
Markus

On Dec 9, Blair  wrote:

>  Can you call heat per-file instead of per-dir for those directories?
>
>  -Original Message-
>  From: Markus Gaugusch [mailto:w...@gaugusch.at]
>  Sent: Wednesday, December 09, 2009 1:47 AM
>  To: wix-users@lists.sourceforge.net
>  Subject: [WiX-users] How to specify files in Installer package
>
>  Hi,
>
>  I'm using WIX3 and try to make an installer package for our software.
>  The software contains lots of files and folders, and some of them have to
>  be treated specially (one for installing a Windows Service, several
config
>  files which should be preserved).
>
>  Now I'm using heat to generate the list of files for my package, but I
>  don't want to edit the generated content in order to specify my service
or
>  config files.
>  At the moment I remove those files from heat generated code and have them
>  in another file. But this is a manual and error-prone process.
>
>  I'd like to tell heat to ignore some files and generate the wxs file for
>  everything else. This is especially interesting because I'm using
>  subversion and I can't checkout the files for my installer packages in
the
>  usual way, because heat would include the .svn directories.
>
>  I've added a tracker entry, but there was no reaction yet.
>
https://sourceforge.net/tracker/?func=detail&aid=2900555&group_id=105970&ati
>  d=642717
>
>  Comments?
>
>  thanks,
>  Markus


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Patching problems with alternate directories

[Blair]

The location that the components you are patching are already installed.

Could you share a log that shows it not working in that circumstance?

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Wednesday, December 09, 2009 1:55 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


When you refer to the "currently installed location", are you referring to
the location that my product installs to by default or the location selected
by the user.  If the latter, then the patch should be installing to that
location.


Blair-2 wrote:
> 
> Are your patches MSP files performing either small updates or minor
> upgrades? If so, the patch application won't let you patch anywhere other
> than the currently installed location since the keypath of the components
> can't be changed without a major upgrade.
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Wednesday, December 02, 2009 1:12 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Patching problems with alternate directories
> 
> 
> I've been having an issue with my WiX patch which I haven't been able to
> find
> any information for.  The company I work for wants to give users the
> freedom
> to install our product in a directory of their choice.  We've given the
> installer a default directory which can be changed at install time by the
> user.  This has worked fine up until attempting to patch the package.  I
> successfully made a patch which patches the package without problem if
> it's
> installed to the default location, however if users choose to install the
> product in an alternate location and then patch the patch fails because
> it's
> still trying to change files on the default location.  Any ideas on how I
> can dynamically set up the patch install location based on where the user
> installs our product?  Thanks in advance.
> 
> Big Jim.
> -- 
> View this message in context:
>
http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p
> 4102386.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
>

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

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

-- 
View this message in context:
http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p
4142265.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] multiple entries in add remove programs.

[Blair]

The intent is:
 - A major update is an update that "replaces" all previous versions of a
product. It never requires (usually) the previous version to be installed.
 - A minor update is an identical copy of an original with some "minor"
changes. You can't really remove anything in the "replacement package" from
the already installed package (without involving major breaking things).

The only way to have the "upgrade" contain only new stuff that combines with
older stuff is to make an MSP and send it out.

OnlyDetect should be 'no' and your upgrade package must have everything it
needs by itself (it must not depend on the previous package ever having been
installed).

-Original Message-
From: Giora keinan [mailto:grkei...@gmail.com] 
Sent: Thursday, December 10, 2009 1:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] multiple entries in add remove programs.

Hello Again
The Allusers were not the same. I set them both to Allusers = 1.

I received the following results:

In Major Update:
- in case that the OnlyDetect='yes' :
   There are two entries in the Add Remove Programs
- in case that the OnlyDetect='no' :
   There are is one entry in the Add Remove Programs
   But all the files of the original installation are deleted. (only 
the two components that are part of the upgrade are installed).

In Minor Update:
No change - the upgrade works, there is one entry in the Add remove 
programs, the problem is that when I remove the program, only the 
upgrade is removed.
 
In the Minor mode I tried to debug using a log file and the 
MSIENFORCEUPGRADECOMPONENTROULES=1.
its stops the installation with error 2771. Looking at the log file the 
msiexec is looking for a component that is part of the original 
installation but not part of the upgrade.

I am using the same feature name in both setup and upgrade.

Thanks
Giora

 



Wilson, Phil wrote:
> Assuming you did all that, and corrected the OnlyDetect value, then all I
can think of now is that the Allusers value is not the same between the old
version and the newer one. 
>
> If you install and take an MSI log:
>
> Msiexec /I  /l*v 
>
> What does the log say, looking at all the FindRelatedProducts data? 
>
> Phil Wilson 
>
> -Original Message-
> From: Giora keinan [mailto:grkei...@gmail.com] 
> Sent: Wednesday, December 09, 2009 6:43 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] multiple entries in add remove programs.
>
> Hello All
> After playing two more days I made no progress.
> I tried all the advises I got, including rewriting the wxs file 
> following the example in Neil Sleightholm's blog.
>
> I got the same two results:
> Major upgrade: (Using '*') every thing works but I got two entries in 
> the Add Remove Programs. One for the original installation and one for 
> the Upgrade.
> Minor Upgrade. (using the original component and product key).  I have 
> only one Entry in the Add Remove Program but when I Uninstall this entry 
> only the components that are part of the upgrade are removed.
>
> I tried every combination of Keys automatic GUID and msiexec command 
> line argument (including running directly the Upgrade.msi).
>
> The application should be upgrade frequently, so we can't have an entry 
> for each upgrade.
>
> Thanks
> Giora
>
>
>
> Neil Sleightholm wrote:
>   
>> Goira, your Product/@UpgradeCode doesn't match Upgrade/@Id that is why
>> you get the duplicate. Take a look at my sample again you will see I use
>>  to stop this happening.
>>
>> Neil
>>
>> -Original Message-
>> From: Giora keinan [mailto:grkei...@gmail.com] 
>> Sent: 07 December 2009 09:35
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] multiple entries in add remove programs.
>>
>> Hello
>> Thanks Sascha, Asker and Neil.
>> I tried your ideas and still have no idea what is the problem
>> I am using only 3 digits version (trying to upgrade 1.0.7 to 1.0.8)
>>
>> following in my upgrade code, maybe you will found what is the problem:
>>
>> 
>>
>> 
>>
>> 
>>   > UpgradeCode='2638A59D-5047-4E78-87A6-A665B98FA131'
>>Language='1033' Codepage='1252' Version='$(var.Version)' 
>> Manufacturer='Gakay'>
>>
>>
>>   >   Description="CapCake $(var.Version) Updater"
>>   Comments='CapsCake is a  trademark of Gakay.' Manufacturer='Gakay'
>>   InstallerVersion='100' Languages='1033' Compressed='yes' 
>> SummaryCodepage='1252' />
>>
>> 
>>   > Root='HKLM' Key='Software\Gakay\CapsCake' Name='InstallDir' />
>> 
>>
>>
>>   > Property="OLDERVERSIONBEINGUPGRADED"
>> Minimum="1.0.0" IncludeMinimum="yes"
>> Maximum="$(var.Version)"
>> IncludeMaximum="no" />
>>   > Minimum="$(var.Version)" IncludeMinimum="no" />
>>
>>
>>
>> 
>> 
>>
>>
>> 
>> 
>>
>> 
>>   
>>   
>>
>> 
>>   > Source='CapsCake.exe' KeyPath='yes

Re: [WiX-users] install previous version when service major upgrade fails

[Blair]

You will increase your success rate by doing these things:
 - Get rid of your self-registration and use the built-in Windows platform
support for services (the Service* elements in WiX).
* the above will require that you perform all your registration using
Registry entries, etc. in the MSI itself instead of using the stuff only
intended for developers debugging their code builds (self-registration)
without doing the smart thing which is remote debugging using a virtual
image.
  - Move RemoveExistingProducts to either right before or right after
InstallFinalize.

With the way you have your installation authored your previous version
should be reinstalled when the removal is rolled back. Your new package
shouldn't care if this is an upgrade or a fresh install since you currently
"remove-before-install" your upgrade.

-Original Message-
From: Adriana Rodean [mailto:adrya1...@gmail.com] 
Sent: Thursday, December 10, 2009 3:41 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] install previous version when service major upgrade
fails

Hi,

I have the following scenario.
- MSI installs a service.
- MSI makes MAJOR upgrade to this installed service (uninstalls old
version and installs new version)
- During the major upgrade if it fails, it makes rollback and the
service uninstalls completely.
Is it possible to tell MSI that if service major upgrade fails,
uninstall the upgrade and install the previous version of the service?
And how?

This is my code:



























  
  OLDFOUND
  

  $OPGatewayComponent>2
  $OPGatewayComponent=2

  $OPGatewayComponent>2
  $OPGatewayComponent>2

  $OPGatewayComponent=2
  $OPGatewayComponent=2

  $OPGatewayComponent>2
  $OPGatewayComponent>2

  $OPGatewayComponent>2
  $OPGatewayComponent>2
  $OPGatewayComponent>2
  $OPGatewayComponent>2
  $OPGatewayComponent>2
  $OPGatewayComponent>2

  SELFFOUND
  NEWERFOUND




Another question. How can i make rollback action (RunCmdRollback) not
to execute on failed upgrade, only on failed new install?

Thank you very much,
Adriana


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Patching problems with alternate directories

[Blair]

What does the log say about the component statuses?

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Thursday, December 10, 2009 6:27 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


Hey Blair-2, I'd be happy to share a log of the installation but
unfortunately I'm doing this for a company and I'm not allowed to post the
information for a log.  I've studied the logs myself during patching and it
looks like it doesn't recognize that the install path is different from
C:\Program Files\Appname\etc.  What it ends up outputting is a list of the
files being installed by the patch but each one specifies To be installed;
Won't patch; No existing file.

If you're interested in a particular portion of the log file I might be able
to show you by replacing the product and path information with fictional
data so you could see what might be the problem without my violating my
company's policies.

Thank for all your help so far!


Blair-2 wrote:
> 
> The location that the components you are patching are already installed.
> 
> Could you share a log that shows it not working in that circumstance?
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Wednesday, December 09, 2009 1:55 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
> 
> 
> When you refer to the "currently installed location", are you referring to
> the location that my product installs to by default or the location
> selected
> by the user.  If the latter, then the patch should be installing to that
> location.
> 
> 
> Blair-2 wrote:
>> 
>> Are your patches MSP files performing either small updates or minor
>> upgrades? If so, the patch application won't let you patch anywhere other
>> than the currently installed location since the keypath of the components
>> can't be changed without a major upgrade.
>> 
>> -Original Message-
>> From: XorPtr [mailto:reaper4...@gmail.com] 
>> Sent: Wednesday, December 02, 2009 1:12 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] Patching problems with alternate directories
>> 
>> 
>> I've been having an issue with my WiX patch which I haven't been able to
>> find
>> any information for.  The company I work for wants to give users the
>> freedom
>> to install our product in a directory of their choice.  We've given the
>> installer a default directory which can be changed at install time by the
>> user.  This has worked fine up until attempting to patch the package.  I
>> successfully made a patch which patches the package without problem if
>> it's
>> installed to the default location, however if users choose to install the
>> product in an alternate location and then patch the patch fails because
>> it's
>> still trying to change files on the default location.  Any ideas on how I
>> can dynamically set up the patch install location based on where the user
>> installs our product?  Thanks in advance.
>> 
>> Big Jim.
>> -- 
>> View this message in context:
>>
>
http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p
>> 4102386.html
>> Sent from the wix-users mailing list archive at Nabble.com.
>> 
>>
>

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

> --
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing. 
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>> 
>> 
> 
> -- 
> View this message in context:
>
http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p
> 4142265.html
> Sent from the wix-users mailing list archive at Nabble.com.
>

Re: [WiX-users] Patching problems with alternate directories

[Blair]

Thomas brings up a good point. How is your "default" directory actually set
in your authoring?

-Original Message-
From: Thomas Svare [mailto:thomas_sv...@symantec.com] 
Sent: Thursday, December 10, 2009 10:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching problems with alternate directories

Hello,

You just open the msi with Orca then choose Transform->View Patch and
navigate to the msp and select OK and you'll see the changes in Orca.

Since repairs and uninstalls are showing the problem it sounds like some
property is getting set by the UI that isn't being re-set during
patch/repair/uninstall.

Thanks,
Tom

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Thursday, December 10, 2009 12:59 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


I definitely reviewed the tables for both my installer msi as well as my
patch msp while trying to figure out this problem.  I've never heard of
applying a patch using orca before though, I took at look but didn't see
an
obvious way of doing this.  Could you let me know how to use orca to
apply
the patch?  Also the issue extends beyond patching to include repairs
and
uninstalls so I think the problem runs deeper than just how the patch is
applied.


Thomas Svare wrote:
> 
> Hello,
> 
> You may have already tried this but sometimes opening the msi and
> applying the patch with Orca can point out things that are buried in a
> verbose log like removing a component from a feature during a patch
etc.
> 
> Thanks,
> Tom
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Thursday, December 10, 2009 12:00 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
> 
> 
> All of the components are listed as:
> 
> Installed: Local; Request: Local; Action: Local.
> 
> 
> Blair-2 wrote:
>> 
>> What does the log say about the component statuses?
>> 
>> -Original Message-
>> From: XorPtr [mailto:reaper4...@gmail.com] 
>> Sent: Thursday, December 10, 2009 6:27 AM
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] Patching problems with alternate directories
>> 
>> 
>> Hey Blair-2, I'd be happy to share a log of the installation but
>> unfortunately I'm doing this for a company and I'm not allowed to
post
> the
>> information for a log.  I've studied the logs myself during patching
> and
>> it
>> looks like it doesn't recognize that the install path is different
> from
>> C:\Program Files\Appname\etc.  What it ends up outputting is a list
of
> the
>> files being installed by the patch but each one specifies To be
> installed;
>> Won't patch; No existing file.
>> 
>> If you're interested in a particular portion of the log file I might
> be
>> able
>> to show you by replacing the product and path information with
> fictional
>> data so you could see what might be the problem without my violating
> my
>> company's policies.
>> 
>> Thank for all your help so far!
>> 
>> 
>> Blair-2 wrote:
>>> 
>>> The location that the components you are patching are already
> installed.
>>> 
>>> Could you share a log that shows it not working in that
circumstance?
>>> 
>>> -Original Message-
>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>> Sent: Wednesday, December 09, 2009 1:55 PM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: Re: [WiX-users] Patching problems with alternate
directories
>>> 
>>> 
>>> When you refer to the "currently installed location", are you
> referring
>>> to
>>> the location that my product installs to by default or the location
>>> selected
>>> by the user.  If the latter, then the patch should be installing to
> that
>>> location.
>>> 
>>> 
>>> Blair-2 wrote:
>>>> 
>>>> Are your patches MSP files performing either small updates or minor
>>>> upgrades? If so, the patch application won't let you patch anywhere
>>>> other
>>>> than the currently installed location since the keypath of the
>>>> components
>>>> can't be changed without a major upgrade.
>>>> 
>>>> -Original Message-
>>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>>> Sent: Wednesday, December 02, 2009 1:12 PM
>>>> To: wix-users@lists.sourceforge

Re: [WiX-users] Adding Files Using Patch

[Blair]

If the file didn't exist in the baseline image there really shouldn't be a
difference for that file by merely  adding the delta switch.

Is this something where you can share the wixmst file with me?

-Original Message-
From: nearnick [mailto:n...@nearglobal.com] 
Sent: Thursday, December 10, 2009 10:08 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Adding Files Using Patch


I cannot for the life of me work out how to add files when using a delta
patch. It works easily enough without the delta flag even when not creating
a new component for the new files (just adding them to an exisiting one).
However with the delta patch i always get 

"Info 1334. The file 'SampleFile' cannot be installed because the file
cannot be found in cabinet file 'RTM.cab'. This could indicate a network
error, an error reading from the CD-ROM, or a problem with this
package."

I am adding the files within a new component and updating the major version
number of the product. 
I am building using wixpdbs.
I am running msiexec with "REINSTALL=ALL REINSTALLMODE=amus REBOOT=Supress
/qb /p"

I tried doing it in two patches, first non-delta just adding the files and
then second doing the delta on everything else but still got the same error.

What else can I do to make this work? This must be a very common operation
isn't it?
-- 
View this message in context:
http://n2.nabble.com/Adding-Files-Using-Patch-tp4146882p4146882.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Finding on APRNOMODIFY .. is this right ?

[Blair]

Copy WixUI_InstallDir.wxs from the sources to your project, remove the
offending property, and refer to your copy instead of the one in the
extension.

Later, address the maintenance mode dialog sequence to ensure it works for
you.

-Original Message-
From: Robert Hermann [mailto:rob.herm...@nicewareintl.com] 
Sent: Friday, December 11, 2009 4:59 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Finding on APRNOMODIFY .. is this right ?

I've been working on an installer that uses custom dialogs and some
standard dialogs.
Once installed, I want the app to have the Change button under add
remove programs.   

I understand that I need to use
0
In order to do this (change button appear).

What I have found is once I have 
  

In my install script  (.wxs file) 

I get the compile error  

Error 1  The primary key 'ARPNOMODIFY' is duplicated in
table 'Property'.  Please remove one of the entries or rename a part of
the primary key to avoid the collision.
DatabaseandBackendInstallScript.wxs571   1  

I did some more digging on the WixUI_InstallDir.wxs and found that it
sets the property 'ARPNOMODIFY' to 1.  

Why ?

I want to use this standard dialog as It allows me to change the path of
the install directory. I also want the Change button to display in Add
Remove Programs.   Do I need to override this standard install directory
dialog in some way so that I can set   APRNOMODIFY to 0   and yet have
all the benefits of that dialog.  


Rob








--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] util:User, util:Group controlling sequencing...

[Blair]

None of those actions should ever occur during the UI sequence. The UI
sequence is intended exclusively for gathering information from the user to
guide the installation.

Every action that changes the machine's state is to be performed from
deferred actions which by definition run in the execute sequence between
InstallInitialize and InstallFinalize. In that space there is plenty of room
to create the account, add it to an existing group, alter config files,
start services, run scripts, etc. all in the right order.

In the UI sequence you can gather what the username and the group will be
(unless you already know one or both of those) so you can setup the data
that the deferred actions will consume.

The "default" order that those actions are performed (with their associated
sequence numbers and relative to selected built-in actions) is as follows
(based on the 3.0 RTM build):

MoveFiles sequence="3800"
ConfigureUsers Before="InstallFiles" - Creates users and adds them to groups
InstallFiles sequence="4000"
InstallSqlData After="InstallFiles" - Runs SQL Scripts
PatchFiles sequence="4090" - added automatically when building MSP files,
should not normally be in MSI files.
DuplicateFiles sequence="4210"
SchedXmlConfig After="DuplicateFiles" - Runs XmlConfig and XmlFile elements
InstallServices sequence="5800"
SchedServiceConfig After="InstallServices" - Runs util:ConfigureService
MsiConfigureServices sequence="5850" - Runs Windows Installer's
ConfigureService
StartServices sequence="5900"

Most of the time, that sequence should meet almost every need (I can't
conceive of any more than minor changes to the above sequence). To change
the sequencing, just place whichever of the following elements you wish to
alter inside of an  element and set an appropriate
value to either the Before, After, or Sequence attributes (not all elements
can accept any of the three, check the WiX help file for which elements
allow what):


VersionNT > 400

NOT SKIPINSTALLSQLDATA AND VersionNT
> 400


VersionNT > 400
VersionNT
NOT REMOVE~="ALL" AND VersionNT >
400
"VersionNT>=600"
VersionNT

-Blair

-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com] 
Sent: Monday, December 14, 2009 9:50 AM
To: WiX Users
Subject: [WiX-users] util:User, util:Group controlling sequencing...

We'd like to use WiX's util:User and util:Group (and util:GroupRef) to
create an account and add it to an existing group.  How is it possible
to control when these actions are invoked?  Ex.  We need the user
account created before config files are modified to use the user name,
services are started, sql scripts run, etc.

Is it possible for the user account to get created during the
UISequence?  Added to the security group during the UISequence?
-- 
Tony


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Tutorial: a minor issue in the Patchwork section

[Blair]

At the bottom of each page, the author's name is a hyperlink that opens a
partially populated email message to compose (assuming your email client and
your computer's browser are both setup for that). Here is that hyperlink:
mailto:d...@tramontana.co.hu?subject=wixtutorial

-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net] 
Sent: Thursday, December 17, 2009 11:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WiX Tutorial: a minor issue in the Patchwork section

Hello WiX community,

I noticed a minor issue in the Patchwork section of the WiX tutorial. I
don't know the place to register the issues for this, but I know that
the author is reading this list ;)

Here (http://www.tramontana.co.hu/wix/lesson4.php#4.3) the tutorial
says: " A PatchFamily tag encompasses the items to be patched. Its
DiskId has to be larger than any Media/@Id found in the installation
packages and ..."

But PatchFamily element doesn't have DiskId attribute. It is a
Patch/Media element and the attribute is called just 'Id'. Well, it is
clear what is meant here, but the people new to WiX and patching might
get confused. 

:)

Thanks, 

-- Yan



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


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

Re: [WiX-users] How Do I Verify Group Membership?

[Blair]

I agree that this is a reasonably good method to deal with the per-user 
configuration that inevitably ends up falling on the setup developers to 
supply. The one thing to keep in mind is how to trigger that "last part of 
install" for the non-installing users (assuming your installation is 
per-machine).

-Original Message-
From: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
Sent: Monday, December 14, 2009 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How Do I Verify Group Membership?

We do the same thing. +1 to Sascha's comments. 

Phil Wilson 

-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] 
Sent: Thursday, December 10, 2009 7:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How Do I Verify Group Membership?

One thing to consider with this type of requirement, is how to define
the scope of "installation"

Many setup developers consider "install" as a much narrower scope than
those who are defining the requirements. Leveraging a configuration
utility on MSI setup completion (via a bootstrapper or the "finish"
button) is still part of the "install" process from a users point of
view.

For example, our installation comes in two flavours...

For retail customers, we provide an interactive installation that
doesn't try to gather any config date, they step through the UI,
install the software and on pressing the "Finish" button we launch a
separate configuration utility.

For corporate customers, we provide a tool to set installation
parameters, then using the Windows Installer API we create an MST
file. The MSI provided to corporate customers doesn't provide any UI,
so the application checks on first run to ensure it's configured
properly and only requires post-install steps as a fallback option for
when information wasn't provided pre-install.

HTH.

Sascha

On Thu, Dec 10, 2009 at 1:46 PM, Castro, Edwin G. (Hillsboro)
 wrote:
> Enter Requirement X: There should be no post-install configuration.
>
> I tell you, these requirement peoples just love to get in the way! ;-)
>
> BTW: I completely agree with you. I'm just pointing out that sometimes we get 
> forced to implement ugly requirements. I have to choose my battles. This one 
> is relatively minor so I don't complain so much.
>
> Edwin G. Castro
> Software Developer - Staff
> Electronic Banking Services
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> Please consider the environment before printing this e-mail
>
>
>> -Original Message-
>> From: Richard [mailto:legal...@xmission.com]
>> Sent: Wednesday, December 09, 2009 6:19 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] How Do I Verify Group Membership?
>>
>>
>>   I don't think I would try to cram this into the installer.
>> If the installer isn't going to change the group membership, then it
>> shouldn't be gathering the information to query the group membeship.
>>
>> Do it after installation time with a standalone configuration
>> utility.  That way they can change which domain user/group they use
>> at any time.
>> --
>> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
>> download
>>  > pipeline/>
>>
>>   Legalize Adulthood! 
>>
>> ---
>> ---
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
> --
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
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 per

Re: [WiX-users] question about upgrades

[Blair]

If the ProductCode you are attempting to install is already installed, it is
no longer a major upgrade and is a maintenance mode transaction (see small
update & minor upgrade, as well as repair and removal). Your ProductCode
must not be installed in order to perform an installation transaction (both
major upgrade and fresh install).

-Original Message-
From: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
Sent: Tuesday, December 15, 2009 9:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] question about upgrades

Maintenance mode means that the product is already installed, as defined by
the ProductCode guid and the PackageCode guid. 

Phil Wilson 

-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com] 
Sent: Tuesday, December 15, 2009 9:18 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] question about upgrades

Hi All,

 

I have an install (v 3.0.5419.0) which performs a major upgrade, and
completely uninstalls the previous version before installing the newer
one, when a previous version is detected.  We support multiple side by
side instances of our application, and as such, target a specific
instance for upgrade by setting the property from the upgrade table to
the appropriate product code based on the instance the user selected
from a custom bootstrapper.  All of this has been working correctly
until yesterday.

 

I now have an issue where when I execute my install and choose to
upgrade a specific instance it is failing to do so.  My bootstrapper is
passing in all the same values in the command line to Windows Installer
that it was before, but FindRelatedProducts is not executing for some
reason.  From the verbose log:

 

MSI (c) (DC:98) [09:10:52:732]: Doing action: FindRelatedProducts

Action 9:10:52: FindRelatedProducts. Searching for related applications

Action start 9:10:52: FindRelatedProducts.

MSI (c) (DC:98) [09:10:52:733]: Skipping FindRelatedProducts action: not
run in maintenance mode

Action ended 9:10:52: FindRelatedProducts. Return value 0.

 

So basically, the FindRelatedProducts action is not being executed, and
obviously the RemoveExistingProducts action will also not be executed.
What does it mean "not run in maintenance mode", and how do I make it
work correctly so that it will run FindRelatedProducts action as I want?

 

Thanks in advance for your help,

 

Amy

 

Amy Rosewater VanMatre

SPECTRUM Human Resource Systems Corporation

707 17th Street Suite 3800

Denver CO, 80202

303.592.3403

arosewa...@spectrumhr.com

 


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



*** 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
Portland House, Bressenden Place, London, SW1E 5BF (Registered number
166023). For a list of European legal entities within the Invensys Group,
please go to
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77
. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be
subject to the terms of any agreements between Invensys (and/or its
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
affiliates).




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


--
This SF.Net email is s

Re: [WiX-users] util:User, util:Group controlling sequencing...

[Blair]

If in your authoring you associate the created user with a specific
component AND you use so-called "late" scheduling of RemoveExistingProducts
you will get what you want (because the component will remain during the
entire upgrade). If you change the user data and need to "recreate" it to
effect a change then you will need to have your component's keypath's
"versioning" reflect the state of that user (so it will "recreate" the user
using the new information only when the keypath is made "newer").

If you absolutely must use so-called "early" scheduling of
RemoveExistingProducts then you will lose the ability to service the user
account (you won't easily be able to reliably "recreate" the user using the
newer definition). To do that, you will need to condition the custom
action(s) that schedule the user-and-group operations to not run in both the
install and uninstall phases of major upgrades. That is a heavy hammer,
however: all user and group operations will be "frozen" in your entire MSI.

Anything else will likely be fragile. The first is the recommended route. If
you already follow the component rules, you should be able to use the that
first method.

-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com] 
Sent: Tuesday, December 15, 2009 7:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] util:User, util:Group controlling sequencing...

Couple more questions...

What if we want the user created on install, removed during uninstall,
but NOT removed during the "uninstall" that occurs during major
upgrade?  Do we create two components with a  component one
with RemoveOnUninstall="yes" and the other with RemoveOnUninstall="no"
and use a condition (where?) to select the correct component during
the correct scenario?

The add user to group mechanism seems fine, but the issue I see with
the create user function being performed as a deferred action is that
the end user feed back is horrible. What if we are given an invalid
name, Password complexity, etc.  All the user gets to see is a "error
creating user account -2234234342".  And rollback starts.

Whereas if we were to create the user during the UI sequence, we can
show the user the crazy error and dump them back on the account dialog
asking them to verify the information they provided.


This isn't as much of an issue for the group membership function as we
can only add the user to existing groups.  So, a simple type-o won't
fail the install.

On Mon, Dec 14, 2009 at 4:11 PM, Blair  wrote:
> None of those actions should ever occur during the UI sequence. The UI
> sequence is intended exclusively for gathering information from the user
to
> guide the installation.


-- 
Tony


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


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

Re: [WiX-users] Question on updating GAC assemblies

[Blair]

Also, Daniel, to attempt to help you answer your question as to the difference 
in behavior caused by the addition of the InstallExecute and the placement of 
MsiProvideAssembly, it helps to understand the following about Windows 
Installer:

Everything you see in any sequence table you should consider as running 
"immediate" (that is what allows the built-in actions to access the database 
and session values). Usually everything between InstallInitialize and 
InstallFinalize should eventually be "writing to the script" (which means 
either they are marked as some sort of deferred or attempt to "do" (or call) an 
action that is marked as deferred). There are three actions that will run/flush 
the script: InstallExecute, InstallExecuteAgain, and InstallFinalize. Whenever 
any of these are hit, Windows Installer runs the script that has built up via 
the previous actions. However, with the exception of InstallFinalize, they 
don't run any action marked as a "commit" action. That means that commit 
actions are ever only run once.

Keep the above in mind while reviewing the docs on the built-in actions on 
MSDN. As an example, it is as if the built-in RemoveFiles action where really 
two "custom actions", one immediate (that you actually sequence) and one 
deferred (that you never see the definition of) that the immediate action 
"calls" to cause it to be written into the script. This means that using 
InstallExecute (and InstallExecuteAgain) allows you to "change" the dynamic 
caused by the timelag between when code can access the database and session 
variables and when it can change the system.

That is also the pattern used by most of the WiX custom actions (an immediate 
custom action that you schedule, and a deferred action that the immediate 
action just calls).

-Original Message-
From: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
Sent: Tuesday, December 15, 2009 10:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question on updating GAC assemblies

If you're doing a minor upgrade and want to replace the assembly in the GAC 
then ensuring there is an incremented FileVersion in the MsiAssemblyName table 
is the way to do it, without changing any other assembly name attributes.

A major upgrade where RemoveExistingProducts is sequenced near "the end" 
follows file replacement rules because new files are installed (and guid ref 
counted) on top of existing files, and then ref counted down when the older 
product is uninstalled. That's why file overwrite rules matter in some major 
and all minor upgrades, and why Aaron's blog article is relevant. 

So keep everything the same, use FileVersion in MsiAssemblyName as in Aaron's 
blog, and do an in-place replacement of the assembly. A minor upgrade will not 
remove an assembly from the GAC. That's why you're seeing what you're seeing. 
Component rules have to be followed, so you can't remove a component from a 
minor upgrade, and if you change an assembly naming attribute it will look like 
you're installing another and you'll see both there in the GAC. The answer is 
not to fiddle with sequences until it works. If you want to change assembly 
naming attributes, give it a new component guid and do a major upgrade. If you 
want an in-place minor upgrade replace use FileVersion. 

Welcome to GAC hell. If you can avoid the GAC, then do! 

Phil Wilson 



-Original Message-
From: daniel.roberts...@repab.se [mailto:daniel.roberts...@repab.se] 
Sent: Tuesday, December 15, 2009 2:39 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Question on updating GAC assemblies

Thanks for the reply. I've read that article but it's not quite the situation I 
have. We are not doing an major upgrade (not that I'm sure if that’s making any 
difference) and I don't want to do an in-place upgrade. 

From what I have read it's recommended to change the strong name. 
http://msdn.microsoft.com/en-us/library/aa372360(VS.85).aspx

Actually I found out that when installing and upgrading one of our other 
products, which is much smaller in size but still uses the same core-files in 
the GAC, it all runs smoothly and the GAC get's correctly updated. And when 
searching the log files I found tsome differences in the install process 

Specifically, in the first product one Merge Module (MSM) had added 
InstallExecute action to the InstallExecuteSequcence which wasn't the case in 
the second, smaller, product. So inte the smaller product all the actions were 
carried out during InstallFinalize and it all looked good afterwards. 
Searching for references to the DLL in the larger product gives that the 
ComponentRegister and AssemblyCopy is carried out during InstallExecute, but 
the MsiPublishAssembly were scheduled afterwards so that it was carried out 
during InstallFinalize

When I moved the MsiPublishAssembly to just before InstallExecute, then it 
solved the problem also with the first product. So that's fine. 

Bu

Re: [WiX-users] Expanding an env var at install time when writing to the registry

[Blair]

After CostFinalize [#fileid] is the full path to your File with Id of
"fileid" during installation without any "%" characters in it. Also,
[directoryname] is the "\"-appended full path to the Directory with the Id
of "directoryname". So you can use both of these patterns in creating your
registry entries.

Otherwise, use [%env-var].

-Original Message-
From: Markus Gaugusch [mailto:w...@gaugusch.at] 
Sent: Tuesday, December 15, 2009 10:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Expanding an env var at install time when writing
to the registry

On Dec 15, Bruce Cran  wrote:

> I've written an installer with WiX 3.5 which installs a Winsock
> provider, netsh helper and a kernel driver.  After doing some
> restructuring I started getting a warning about installing a
> non-permanant component into system32, so I'm now trying to change the
> installation location to be under %ProgramFiles%\Product .
> However, I need to create a registry entry which points to the new
> location so that netsh can find it, and it seems that netsh doesn't
> understand REG_EXPAND_SZ types.  Is there a way to write a string to a
> REG_SZ type during installation which already has the
> environment variables expanded, or would I need to write a custom
> action?

Hi Bruce,
I did this the following (hopefully correct) way:






You can use [MY_ENV_PROPERTY] to write the correct registry string.

regards,
Markus


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


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

Re: [WiX-users] UI Custom Action displays dialog behing MSI

[Blair]

The problem isn't so much with MessageBox specifically as it is with UI in
general: Windows Installer doesn't support custom UI all that well. The
"built-in" support for what you are trying to do is called either "embedded
UI" or "external UI", not showing dialogs from your immediate custom
actions, since Windows Installer doesn't make all of the UI information
available to custom actions.

You can use MsiProcessMessage to send information from your custom action to
your embedded/external UI. What you can't do is easily send information back
in order to set properties, etc., so you will have to implement information
flow going that way yourself (some sort of IPC, perhaps?).

-Original Message-
From: Tobi Ha [mailto:tob...@gmx.net] 
Sent: Wednesday, December 16, 2009 1:50 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] UI Custom Action displays dialog behing MSI

Hello,
thanks for the advice, but the messagebox was just an example for a more
complex dialog that would be displayed at this moment.

For example:
- LoadLibrary to get a handle
- Call ShowMyC++dialog with the handle.

The main idea is to show a dialog during installation that is also used
later in the programm and so not implement it twice.
The problem is not to show this dialog, but that it is "hidden" behind the
normal MSI GUI.

Best regards,
Tobias


Date: Tue, 15 Dec 2009 10:19:02 -0700
From: Richard 
Subject: Re: [WiX-users] UI Custom Action displays dialog behing MSI
 UI
To: wix-users@lists.sourceforge.net
Message-ID: 

Use MsiProcessMessage to display message boxes, not MessageBox.

-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 

  Legalize Adulthood! 



 Original-Nachricht 
Datum: Tue, 15 Dec 2009 14:32:21 +0100
Von: "Tobi Ha" 
An: wix-users@lists.sourceforge.net
Betreff: UI Custom Action displays dialog behing MSI UI

Hello,

I have a WiX installation that shows within a custom action a dialog from a
dll that is installed during this installation. It all works fine, except
that the dialogs appears behind the normal MSI UI.

Here a short example how my custom action looks like (instead of message
box, a real UI appears)

UINT __stdcall MessageBoxAction (MSIHANDLE hInstall) 
{
Beep(500,2000);

LPCTSTR lpszText = L"A message box text";
LPCTSTR lpszCaption = L"A message box title";
UINT nType = MB_OK; 
MessageBox(NULL,lpszText,lpszCaption,nType);

return ERROR_SUCCESS;
}

Is there a way to display the own UI in foreground?

Cheers,
Tobias

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


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


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

Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin

[Blair]

Why does your installer require admin to run? Are you bootstrapping things
in addition to your MSI?

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Wednesday, December 16, 2009 11:08 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to launch application as Standard User while the
installer ran as Admin

Our installer needs Admin right to run. So a "Standard user" has to run the
installer "run as Admin". On the final page of the installer, we have a
"Launch application" option. So the user can check that option and launch
the application. Our application will ask a license key. The user inputs the
license key. But the key will be saved in "C:\Documents and
Settings\Administrator\Application Data" folder. Then the user exits the
application. And run the application again by using the normal "Standard
user" privilege. Then the application will ask the license key again,
because the license key wasn't saved in the right folder such as
"C:\Documents and Settings\JoeSmith\Application Data".

How to resolve this problem? 

I'm thinking two options:
1. The user can "run as admin". But the application will be launched by
using "Standard user". This way, the license key input by the user will be
saved in the correct spot, namely, the users setting folder like
"C:\Documents and Settings\JoeSmith\Application Data". But how to do it?
2. If there is a way that the installer can detect this installation was
from "run as admin", then set a property. Then in the final page's launch
application option, we'll check this property. If it's set then we disable
the "launch application" option. This will stop the user "running the
application as admin" - they don't need to input license key two times. Is
there a way to detect if the installation "run as admin"?

By the way, we're using the code example from Wix.chm "How To: Run the
Installed Application After Setup" section.

Thanks in advance.
/Brian


  __
Make your browsing faster, safer, and easier with the new Internet ExplorerR
8. Optimized for Yahoo! Get it Now for Free! at
http://downloads.yahoo.com/ca/internetexplorer/

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


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

Re: [WiX-users] Service uninstall fails in Win 7 from Control Panel

[Blair]

Sometimes Windows Installer will send you install messages what, when AND'd
with INSTALLMESSAGE_TYPEMASK, are not something you recognize. If you return
an error (-1) you just failed your transaction and if you return any other
non-zero value you just bypassed whatever it was attempting (which is bad,
since you don't know what it was attempting). Your default case in your
switch statement should always be to return zero.

-Original Message-
From: Adriana Rodean [mailto:adrya1...@gmail.com] 
Sent: Friday, December 18, 2009 9:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Service uninstall fails in Win 7 from Control Panel

Hi,

Yes i have an EmbeddedUI and in that EmbeddedUI i set a property to
suppress "file in use" message and let it continue uninstall (stop
service, uninstall, remove service).
File is in use because service is started...
What can i do? It seems that setting the property from UI doesn't work in
Win7.
Will it work if i stop the service with a CA ? And after what to set
the CA so uninstall can work?

Thanks,
Adriana

On Fri, Dec 18, 2009 at 19:31, Wilson, Phil 
wrote:
> Have you got an embedded UI handler? The log seems to be saying that you
have, and that Windows sent it a INSTALLMESSAGE_RMFILESINUSE message, and
got an error result, an invalid return value.
>
> Phil Wilson
>
> -Original Message-
> From: Adriana Rodean [mailto:adrya1...@gmail.com]
> Sent: Thursday, December 17, 2009 9:48 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Service uninstall fails in Win 7 from Control
Panel
>
> I attached the logo of this issue, maybe will be more helpful...
>
> MSI (s) (E0:C8) [15:17:20:828]: Doing action: InstallValidate
> MSI (s) (E0:C8) [15:17:20:828]: Note: 1: 2205 2:  3: ActionText
> MSI (s) (E0:C8) [15:17:20:839]: PROPERTY CHANGE: Deleting
> MsiRestartManagerSessionKey property. Its current value is
> '6a7f084665b313448b68c9b2d8f30a10'.
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: Dialog
> MSI (s) (E0:C8) [15:17:20:840]: Feature: MyFeature; Installed: Local;
>  Request: Absent;   Action: Absent
> MSI (s) (E0:C8) [15:17:20:840]: Component: MyComponent; Installed:
> Local;   Request: Absent;   Action: Absent
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: Registry
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: BindImage
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: ProgId
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: PublishComponent
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: SelfReg
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: Extension
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: Font
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: Shortcut
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: Class
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: Icon
> MSI (s) (E0:C8) [15:17:20:840]: Note: 1: 2205 2:  3: TypeLib
> MSI (s) (E0:C8) [15:17:20:841]: Note: 1: 2205 2:  3: _RemoveFilePath
> MSI (s) (E0:C8) [15:17:20:846]: PROPERTY CHANGE: Modifying
> CostingComplete property. Its current value is '0'. Its new value:
> '1'.
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: Registry
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: BindImage
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: ProgId
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: PublishComponent
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: SelfReg
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: Extension
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: Font
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: Shortcut
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: Class
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: Icon
> MSI (s) (E0:C8) [15:17:20:847]: Note: 1: 2205 2:  3: TypeLib
> MSI (s) (E0:C8) [15:17:20:848]: Note: 1: 2727 2:
> MSI (s) (E0:C8) [15:17:20:920]: RESTART MANAGER: Will attempt to shut
> down and restart applications in no UI modes.
> MSI (s) (E0:28) [15:17:20:922]: EEUI - Invalid return value 4 for
> message type 419430400.
> MSI (s) (E0:28) [15:17:20:922]: EEUI - Embedded UI Handler returned
> ERROR_INSTALL_FAILURE
> MSI (s) (E0:C8) [15:17:21:016]: Note: 1: 1725
> MSI (s) (E0:C8) [15:17:21:016]: Product: MyProduct -- Removal failed.
>
>
> On Thu, Dec 17, 2009 at 19:34, Adriana Rodean  wrote:
>> Hi,
>>
>> I tried to uninstall my service from Control Panel on a Win 7 machine
>> with UAC on, and it fails right after "Install validation. Validating
>> install..."
>> When i uninstall from the bootstrapper which executes the msi with
>> REMOVE="ALL" it uninstalls successfully.
>> On an XP machine works successfully both ways of uninstall.
>>
>> Here is my code:
>>
>>  > Source="..\..\..\..\.OPGateway.OPGatewayService\bin\Release\"
>> KeyPath="yes" />
>>          > Description='OnPremises Gateway service.' DisplayName='OnPremises
>> Gateway' Name='OPGatewayService'
>>  ErrorControl='normal'

Re: [WiX-users] Registering 32- and 64-bit versions of COM InProc Server

[Blair]

You need two components, one marked 32-bit and the other 64-bit. Each will
write to the appropriate areas of the system. Yes, you will have some
duplicate information shared in both components, but each will refer to the
appropriate binary and each should be under the appropriate directory.

-Original Message-
From: Quinton Tormanen [mailto:quint...@deltacompsys.com] 
Sent: Friday, December 18, 2009 9:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Registering 32- and 64-bit versions of COM InProc
Server

I apologize if this has been asked and answered before. I couldn't find
anything on it on the WiX archive or anywhere else on the web after much
hair pulling. Any knowledge that can be imparted would be appreciated.

On 64-bit OSes I need to install both a 32-bit and 64-bit version of my
Inproc COM server. Here is what my existing WiX source looks like for
installing and registering the 32-bit COM server:

  

  


  

  

  

  

  

  

So, I need to add this 64-bit version for 64-bit builds:
 


How do I get it in there? Notice that both the x86 and x64 versions
share the same TypeLib, AppId, and CLSID. In terms of registering, all I
need to do is get the installer to add the InprocServer32 to the
non-WOW6432Node version of the CLSID node, so I was toying with
something like this under the INSTALLDIR Directory element:

  

  

  

  

  

However, it seems wrong to have that much duplicate information. Also, I
expect that I should change the directory to "ProgramFilesFolder64",
although I'm not sure if it's OK to have both the 32-bit and 64-bit
components in my install directory.

Anyone know the correct way to do this?

Quinton Tormanen
Software Engineer
Delta Computer Systems, Inc.
http://www.deltamotion.com



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


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

Re: [WiX-users] Override UI control property in wxs file

[Blair]

Currently you copy the dialog's sources into your code and change the values
you want. Refer to the help, blogs, this list, and tutorials to see how.

-Original Message-
From: Petr Pokorný [mailto:ppoko...@intermap.com] 
Sent: Friday, December 18, 2009 3:06 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Override UI control property in wxs file

Hi

I am wondering if there is a way to override a property of a control
without a need to define the custom dialog.

For example do something like this in my wxs file:


 


To override build-in


  
  
 ...
 
 ...

In InstallDirDlg.wxs

Thanks, Petr

*
PRIVILEGE AND CONFIDENTIALITY NOTICE:

The information in this email is intended for the named recipients only.
It may contain privileged and confidential information.  If you have
received this communication in error, any use, copying or dissemination
of its contents is strictly prohibited.  Please erase all copies of the
message along with any included attachments and notify Intermap
Technologies or the sender immediately by telephone at the number
indicated on this page.

*

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


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

Re: [WiX-users] WiX, InstallShield and combining multiple MSIs

[Blair]

What you don't mention are the following:

Which of the 21 MSIs are written in WiX (as opposed to InstallShield) and
how many (of each) are written in older versions of each of those two
toolsets.

Will you be supplying your own UI binary (a bootstrapper) or will you be
attempting to combine the various UIs of each of those 21 MSIs (using
Windows Installer UI)?

How complicated is the UI of any of those 21 MSIs?

-Original Message-
From: Carter, Patrick [mailto:patrick.car...@stryker.com] 
Sent: Monday, December 21, 2009 5:47 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX, InstallShield and combining multiple MSIs



I have a question regarding WiX and the referenced installation tools.  I am
not a Windows Installer expert (I am not even sure if you could call my
skill level a newbie!), but I have been tasked with a project and I need to
get up to speed fast.

The question is likely very easy:

I have an installation that requires several prerequisites (.NET 3.5 SP1,
Microsoft WSE 3.0, 64-bit OS, etc...)

The previous development team (almost all of who are gone) built 21 MSI
files for each "Feature" each MSI having multiple "components"

This currently gives us a night mare for version control, patches, etc...

I have been tasked with building a CD-based "install" that check the
pre-reqs (this I can do) and get all these MSI's into one install so they
can be selected and de-selected as "features".

What is the fastest and most reliable way to do that (assuming the original
expertise from the guy who wrote the WiX script that builds the MSI's is
gone)?

Thanks for any help pointing me in the right direction.  I have the latest
Wix toolset, Visual Studio 2005 and 2008 and InstallShield 2010 as my tools.


Patrick Carter



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


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

Re: [WiX-users] Allow Multiple Package Versions to Coexist, But Always Install Over Same Version?

[Blair]

You would need to calculate a guid using your version number to use as your
ProductCode (such that the same version number always generates the same
guid and different version numbers generate different guids).

Either a hash-based guid generator or a V1-style guid, I would think.

-Original Message-
From: Haw Bin Chai [mailto:haw-bin.c...@tradeweb.com] 
Sent: Monday, December 21, 2009 3:11 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Allow Multiple Package Versions to Coexist, But Always
Install Over Same Version?

Hi all,

New WiX user here. I'm creating an installer for a win32 side-by-side
assembly. I'm like to fulfill the following requirements, and I haven't
been able to find a solution:

- Allow multiple installations to coexist, so long as their major or
minor
  version numbers are different.
- Installing the same version should always overwrite an existing
  installation of the same version (i.e. even if the contents are
  different)
- Never allow multiple entries for the same version to appear in
Add/Remove
  Programs.
- Avoid having to update Product or Package Id's manually - either
set them
  once, or have them be auto-generated.

I've been playing around with using "*" for Product / Package Id's, as
well as with the  element, but I have not been able to achieve
the desired effect. Is what I want possible?


Haw-Bin

---

The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying,
distribution or any action taken or omitted to be taken in reliance on it,
is
prohibited and may be unlawful.

Tradeweb reserves the right to monitor and review the content of all
messages sent
to or from this e-mail address. Messages sent to or from this e-mail address
may
be stored on the Tradeweb e-mail system.


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


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

Re: [WiX-users] Conditional installation of a feature

[Blair]

Back to your original authoring:

CostFinalize is run twice in any given installation with UI: during
InstallUISequence and during InstallExecuteSequence. Is MYPROPERTY marked as
secure? If it isn't, it will be 0 (the default) during
InstallExecuteSequence (not whatever you set it as during
InstallUISequence).

-Original Message-
From: Sudripta Nandy [mailto:sudrip...@sarangsoft.co.in] 
Sent: Monday, December 21, 2009 10:40 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Conditional installation of a feature

I have tried that but, it doesn't work. It seems that the MSI evaluates the 
feature condition during CostFinalize. As CostFinalize takes place before my

UI sequence, so any property change has no effect on the install behavior. 
So, looking at other similar references, I took a different approach. I set 
my feature's default install level as '1' (i.e. to be installed). In the UI 
control, I am removing the feature depending on the property value:







But curiously, if I do so, my installation starts failing. If I comment out 
the 'Remove' event statement above, it installs fine. But, it installs the 
feature too, that I don't want to install (as I have that feature's level 
set to 1).

I am not sure why the '
To: "'General discussion for Windows Installer XML toolset.'" 

Sent: Monday, December 21, 2009 8:47 PM
Subject: Re: [WiX-users] Conditional installation of a feature


> Do not use 0 and 1 as values as 0 is recognizes as "uninitialized".
> Have you tried strings like "yes" and "no"?
>
> Best regards,
> Sebastian Brand
>
> Deployment consultant
> E-Mail: sebast...@instyler.com
> Blog: www.sebastianbrand.com
>
>
>
>> -Original Message-
>> From: Sudripta Nandy [mailto:sudrip...@sarangsoft.co.in]
>> Sent: Monday, December 21, 2009 15:11
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] Conditional installation of a feature
>>
>> Hi,
>> I want to install a feature depending on the user's choice. I have a
> property
>> 'MYPROPERTY' whose default value is '0'. If the user checks a checkbox, I
> am
>> setting that property value to '1' and installing that feature. I have 
>> the
>> feature element as below:
>>
>> 
>> 
>> 
>> 
>> MYPROPERTY = 0
>> 
>> 
>>
>>
>> The problem is that the feature is never getting installed. But, if I set
> the
>> default value of 'MYPROPERTY' as '1', it gets installed.
>>
>>
>> Please let me know what am I doing wrong.
>>
>>
>>
>> Thanking You,
>> With Regards,
>> // Sudripta Nandy
>>
>>
>>
>

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

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



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


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

Re: [WiX-users] Setting properties in custom actions

[Blair]

The  on the components is evaluated during CostFinalize, not
CreateShortcuts. You don't get the shortcuts because the components
installing the shortcuts are not being installed due to the false condition
on them.

I would recommend moving your CheckApplicationLicence custom action sequence
to before CostInitialize (as per the MSDN page on the CostFinalize action).

-Original Message-
From: David Allen [mailto:david.al...@1spatial.com] 
Sent: Tuesday, December 22, 2009 3:45 AM
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] Setting properties in custom actions

I am updating an installer for a product that provides multiple applications
and want to change it so that it creates shortcuts only for applications
that have a valid licence.

The basic approach is to define each shortcut in a separate component, to
set a condition on the component based on the value of a property and to
execute a custom action to set an appropriate value for the property based
on the licence before the shortcuts are created.

If I set different values when defining the properties, I can see the
correct shortcuts get created. However, any changes to properties made by
the custom action have no effect.

Within the Product element
- define the applications for which we may wish to create shortcuts


- define a property for each application

  


- declare the custom action



- arrange for it to be invoked on install

   NOT (REMOVE = "ALL")
   


- create the desktop shortcuts


  

  
  
INSTALL_DESKTOP_SHORTCUTS AND $(var._cut) = 1
  

  
  
  

  
  

  


The custom action VBScript is:

Option Explicit

Function CheckLicence()
   On error resume next

   MsgBox("CheckLicence: " + Session.Property("LAMPS2"))
   Session.Property("LAMPS2") = "1"
   Session.Property("translate") = "1"
   MsgBox("CheckLicence: " + Session.Property("LAMPS2"))
End Function

I see both message boxes pop up, showing that the property has been
modified.  In the log file, it appears this has been executed before the
shortcuts:

InstallFiles: File: Copying new files,  Directory: ,  Size:
Action ended 11:12:25: InstallFiles. Return value 1.
Action 11:12:25: CheckApplicationLicence.
Action start 11:12:25: CheckApplicationLicence.
Action ended 11:12:29: CheckApplicationLicence. Return value 1.
Action 11:12:29: CreateShortcuts. Creating shortcuts
Action start 11:12:29: CreateShortcuts.
CreateShortcuts: Shortcut: Creating shortcuts
Action ended 11:12:29: CreateShortcuts. Return value 1.
Action 11:12:29: WriteRegistryValues. Writing system registry values

If I start with all the properties having a value of 0 and set them to 1 in
the custom action, no shortcuts are created.  If I start with a value of 1
and set them to 0 in the custom action, all the shortcuts are created.

I presume I have made some sort of simple mistake, but I can't see what it
is.  Help much appreciated.

I am using the final (July) release of WiX 3 on Windows XP SP2 32-bit.

David

--
David Allen,
Telephone: +44 (0)1223 420 414



1Spatial Group Limited; Registered in England No. 4785688 VAT Reg. No.
816329821; Registered Office: Cavendish House; 6 Cambridge Business Park;
Cambridge; CB4 0WZ; United Kingdom

http://www.1spatial.com/



1Spatial: unlocking data, empowering business
Making geospatial data current, accessible, easily shared and trusted

www.1spatial.com

1Spatial Group Limited; Registered in England No. 4785688 VAT Reg. No.
816329821; Registered Office: Tennyson House; Cambridge Business Park;
Cambridge; CB4 0WZ; United Kingdom


IMPORTANT NOTICE
 
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this e-mail in error please notify the sender
immediately and delete this e-mail from your system. Please note that any
views or opinions presented in this e-mail are solely those of the author
and do not necessarily represent those of 1Spatial Group Limited, its
subsidiaries or associated companies, except where the author specifically
states them to be the views of 1Spatial Group Limited, its subsidiaries or
associated companies. 
 
1Spatial Group Limited, its subsidiaries and associated companies will not
be held liable for any legally binding obligations that are not the subject
of an official 1Spatial purchase order or as part of a contract signed by a
director of one of the aforementioned companies.
 
Although the company has taken reasonable precautions to ensure no viruses
are present in this email, the company cannot accept responsibility for any
loss or damage arising from the use of this email or attachments. You should
understand and accept that, when communicating with us by e-mail, it is not
a totally secure communications medium.

--

Re: [WiX-users] writing to console from smoke.exe using custom action

[Blair]

You need to use MsiProcessMessage with the INSTALLMESSAGE_USER type. See
http://msdn.microsoft.com/library/aa369205.aspx for details.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Tuesday, December 22, 2009 5:13 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] writing to console from smoke.exe using custom action

Hi,

 

I wrote a custom action dll in C++ & added to .cub file that I am using in
-cub switch in smoke.exe, I was not successful in writing to console like
the ICE(s) in darice.cub does it but I am able to display the log info in
MessageBox.  

 

Thanks,

Nag

 


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


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

Re: [WiX-users] Forcing uninstall with different InstallScope?

[Blair]

The Upgrade table/RemoveExistingProducts action cannot cross scopes. You
will have to use a bootstrapper to remove the old per-user installation.

-Original Message-
From: Evan Beeton [mailto:ebee...@informasoftware.com] 
Sent: Tuesday, December 22, 2009 11:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Forcing uninstall with different InstallScope?

Hello,

We're building a WiX installer to replace an old one built with
InstallShield; the original is authored as per-user, but we think that
per-machine is more appropriate. Our understanding is that you can't
perform an upgrade when the InstallScope is different, so we tried just
forcing an uninstall of the old product. The new installer has a
different UpgradeCode, and we added an UpgradeVersion element with the
old UpgradeCode with RemoveFeatures set to "all" and OnlyDetect to "no".
Unfortunately this doesn't seem to work and the log tells us:

"FindRelatedProducts: current install is per-machine.  Related install
for product '{GUID}' is per-user.  Skipping..."

Does this mean you can't cross the per-machine/per-user boundary even
for unrelated products (that is, those with different UpgradeCodes)?
Does this mean our only other option is to use a bootstrapper?

Thanks


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


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

Re: [WiX-users] writing to console from smoke.exe using custom action

[Blair]

In every .CUB file created by Microsoft, each action is an immediate custom
action contained in the .CUB file itself. The two .CUB files I wrote worked
the same way (immediate custom actions I put into the .CUB file). Each one
of those used MsiProcessMessage and each one spewed through smoke the exact
same way as the Microsoft supplied ones. I never had to use any other means
to get to the console (nor did I ever try).

It is expected that all custom actions that smoke runs will all be immediate
actions since they don't change any state, they instead verify the internal
state of the .MSI database, thus it isn't expected that they would require
admin privs or any other reason that the action would be anything other than
immediate.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Tuesday, December 22, 2009 9:54 PM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] writing to console from smoke.exe using custom
action

I already tried below solution but is not writing to console, I think
MsiProcessMessage works only if the custom action is run through msiexec or
if the CA is immediate mode, but where as I am running these CA through
smoke utility & for the CA to be made immediate I will have to create the CA
from using installer project work space.

In some of samples I have seen it uses OutputDebugString for writing it to
the console

Naga Ram M Chavakula | Project Manager

O: 608.448.3116 |M: 0091.9885778079 | nagara...@symphony.cc

Symphony Corporation | Hyderabad, A.P.India-500 082 | A SEI-CMMI Level 4
Company   

 We synchronize business, technology and people


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Tuesday, December 22, 2009 7:35 AM
To: nagara...@symphony.cc; 'General discussion for Windows Installer XML
toolset.'
Subject: RE: [WiX-users] writing to console from smoke.exe using custom
action

You need to use MsiProcessMessage with the INSTALLMESSAGE_USER type. See
http://msdn.microsoft.com/library/aa369205.aspx for details.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Tuesday, December 22, 2009 5:13 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] writing to console from smoke.exe using custom action

Hi,

 

I wrote a custom action dll in C++ & added to .cub file that I am using in
-cub switch in smoke.exe, I was not successful in writing to console like
the ICE(s) in darice.cub does it but I am able to display the log info in
MessageBox.  

 

Thanks,

Nag

 


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



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

Re: [WiX-users] Clarification on the MSI security

[Blair]

You can try setting the packa...@readonly attribute. As far as I know Orca
respects the read-only selection but I have never tried it myself. However,
the APIs don't seem to prohibit editing (and committing) "read-only" MSI
files.

If your MSI file is authenticode-signed than any editing at all will cause
the signature to "disappear". If you have some means of testing the
signature and/or can educate the user about verifying the signature in the
UAC prompts that may provide you with your solution...

-Original Message-
From: Andy2k8 [mailto:appr...@gmail.com] 
Sent: Monday, December 21, 2009 10:22 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Clarification on the MSI security


If anybody can use the orca tool to edit a shipped MSI package, are we not
compromising on the security of the installer database? Or is there any way
i can make my MSI read only?

-
Andy
MSI Developer
Schneider Electric:working:
-- 
View this message in context:
http://n2.nabble.com/Clarification-on-the-MSI-security-tp4202247p4202247.htm
l
Sent from the wix-users mailing list archive at Nabble.com.


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


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

Re: [WiX-users] Creating MSI for 64bit machine

[Blair]

I would recommend using the DTF "wrapper" for C# (or any other .net) custom
actions. If your C# code is AnyCPU you won't need to worry about bitness for
the CA code itself using DTF.

Otherwise, 32-bit CAs work in all 64-bit systems that have WoW64 present
(see
http://blogs.msdn.com/heaths/archive/2009/11/06/wow64-is-optional-in-windows
-server-2008-r2-server-core.aspx). Know that 32-bit code in a 64-bit system
may have to use WoW64 APIs to "see" some things you may wish to access when
it runs.

-Original Message-
From: Sagar [mailto:sagarkavitak...@gmail.com] 
Sent: Tuesday, December 29, 2009 11:16 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Creating MSI for 64bit machine


Thank you very for the quick reply Rob and Michael.

I have a custom Action written in C# which is being used in the MSI.
So do i need to build that custom action separately for 32 bit and 64 bit
and then use those specific "CA.dll" files for respective MSI

-Sagar



Rob Mensching-7 wrote:
> 
> candle -arch will switch the Package/@Platform to 64-bit. That's about all
> you need to do. Then you can mark Components/@Win64 as necessary.
> File/@ProcessorArchitecture probably won't be needed.
> 
> Play with it a little bit, that tends to help a lot.
> 
> On Tue, Dec 29, 2009 at 6:24 AM, Sagar
> wrote:
> 
>>
>> Hi
>> I want to develop a 64 bit MSI.
>> I have already developed 32 bit MSI. But now if i had to modify it for 64
>> bit machine, what changes do i need to make?
>> For eg:Package/@Platform , Component/@Win64, file/@ProcessorArchitecture
>>
>> or will candle -arch command build 64 bit MSI for me?
>>
>> I am pretty much confused!
>> Please help ASAP
>> --
>> View this message in context:
>>
http://n2.nabble.com/Creating-MSI-for-64bit-machine-tp4227783p4227783.html
>> Sent from the wix-users mailing list archive at Nabble.com.
>>
>>
>>

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

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

-- 
View this message in context:
http://n2.nabble.com/Creating-MSI-for-64-bit-machine-tp4227783p4231246.html
Sent from the wix-users mailing list archive at Nabble.com.


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


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

Re: [WiX-users] BrowseDlg & SelectionPathOn help

[Blair]

I don't know, but look at CustomizeDlg.wxs in the sources for ideas since
that is the .wxs that incorporates BrowseDlg and it seems to employ the same
features you are trying to enable in your ChangeFolderDlg.

-Original Message-
From: Sagar [mailto:sagarkavitak...@gmail.com] 
Sent: Tuesday, December 29, 2009 11:05 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] BrowseDlg & SelectionPathOn help


Anybody there to help me out?
Please



Sagar wrote:
> 
> Hi
> 
> I am using WixUI_Mondo as my UI. However i am skipping SetupTypeDlg which
> comes with standard WixMondo (This is because i have a single feature).
> Now i have added a my own dialog ChangeFolderDlg between
> LicenseAgreementDlg and VerifyReadyDlg.
> In this dialog i have 
> 1) a control of type text to show the folder path Selected by user
> 2) a control of type pushButton to allow user to browse the directories
> 
> Here is my code snippet:
>  Y="120" Text="Browse">
>Value="FOLDERDIR">1
>   1
> 
> 
>  Y="120" >
>   
>   
>   
> 
> 
> Problem:
> I am able to successfully open BrowseDlg.
> i am able to copy files to FOLDERDIR. But i am not able to update my
> control FolderDirPath with the updated text from BrowseDlg.
> Seems this is something to do with the "subscribe" part.
> 
> Me being a newbie,i am not able to figure out the where the actually
> problem is. Please help me out !
> Thanks in advance.
> 
> 
> 
> 

-- 
View this message in context:
http://n2.nabble.com/BrowseDlg-SelectionPathOn-help-tp4207467p4231227.html
Sent from the wix-users mailing list archive at Nabble.com.


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


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

Re: [WiX-users] Input Validation

[Blair]

How about this?




  
  
NOT ($(var.InputValidated))
  
  
$(var.InputValidated)
  


Yes, I realize that this maintains the double-evaluation, but it is more
maintainable (since you type it only once) and the time to evaluate
shouldn't be long compared to the time required to use the UI via mouse
and/or keyboard.

-Original Message-
From: pmdarrow [mailto:pdar...@metaworks.com] 
Sent: Thursday, December 31, 2009 10:34 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Input Validation


Hi all, what's the best way to validate that several required fields on a
dialog are filled in? I've done some searching on this list but haven't
found anything conclusive. Here's a snippet of a dialog that asks the user
to enter some database information:


  
  
NOT (SERVERNAME AND DATABASENAME AND (USEINTEGRATEDSECURITY = 1
OR (DBUSERNAME AND DBPASSWORD)))
  
  
SERVERNAME AND DATABASENAME AND (USEINTEGRATEDSECURITY = 1 OR
(DBUSERNAME AND DBPASSWORD))
  


This works, but I don't like repeating those two statements (albeit one
wrapped in a NOT). It seems like this is the only way I can get it to
validate every time. If I store the result of the main statement in a
property, the property doesn't get reset when going back or forward in the
wizard so therefore it only validates the input once. Any ideas?
-- 
View this message in context:
http://n2.nabble.com/Input-Validation-tp4237405p4237405.html
Sent from the wix-users mailing list archive at Nabble.com.


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


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

Re: [WiX-users] writing to console from smoke.exe using customaction

[Blair]

Custom Actions in CUB files are supposed to be immediate custom actions.
Please read MSDN. Use MsiProcessMessage.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Thursday, December 31, 2009 3:33 AM
To: 'Schrieken, Rene'; 'General discussion for Windows Installer XML
toolset.'
Subject: Re: [WiX-users] writing to console from smoke.exe using
customaction

With the below code WriteFile is returning false, GetLastError shows “Handle
is invalid”

 

Nag

  _  

From: Schrieken, Rene [mailto:rene.schrie...@logica.com] 
Sent: Tuesday, December 29, 2009 11:41 AM
To: General discussion for Windows Installer XML toolset.
Cc: nagara...@symphony.cc
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

 

Looking at your code and reading msdn WriteConsole(szBuffer); might fail.
Something with ansi and widechar but this is really not my area of
expertise. Can you try to see if this might work: (everybody else: HELP!)

 

AttachConsole(...);

HANDLE file;

file = GetStdHandle(STD_OUTPUT_HANDLE); 

// check if you have something valid

// you might need an if for non-redirected output?
BOOL ok;

ok = WriteFile(file, szBuffer, somesafelenfunc(szBuffer), &written, NULL);

// check if true is returned

FreeConsole(...);

 

 

Please save everything before you try this... 

 

  _  

Van: nagaram.c [mailto:nagara...@symphony.cc]
Verzonden: di 29-12-2009 8:04
Aan: Schrieken, Rene; 'General discussion for Windows Installer XML
toolset.'; 'General discussion for Windows Installer XML toolset.'
Onderwerp: Re: [WiX-users] writing to console from smoke.exe using
customaction

Thanks for that, but it is only writing to file what ever is displayed in
the command window through other ICE(s) (ICE1 - 1CE100) performed by
darice.cub, but not those of my CA even through it can display in the
command window



Nag

  _ 

From: Schrieken, Rene [mailto:rene.schrie...@logica.com]
Sent: Thursday, December 24, 2009 10:46 AM
To: nagara...@symphony.cc; General discussion for Windows Installer XML
toolset.; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction



smoke.exe - cub myCub.cub myMSI.msi >> smoke.log



(use two >> to redirect output, that will open the file for append, instead
of create)



  _ 

Van: nagaram.c [mailto:nagara...@symphony.cc]
Verzonden: do 24-12-2009 6:46
Aan: 'General discussion for Windows Installer XML toolset.'; 'Blair'
Onderwerp: Re: [WiX-users] writing to console from smoke.exe using
customaction



I found a solution, the custom action DLL isn't writing to console unless I
call AttachConsole as like below

cpid = GetCurrentProcessId();
hWnd = FindWindowEx(NULL, NULL, _T("ConsoleWindowClass"), NULL);
//this need not be the same console where the process is running at
//need to fetch parent process id & check if they are same
GetWindowThreadProcessId(hWnd, & ppid);
cppid = GetParentPID(cpid); //user defined function to get the parent id

if(cppid == ppid) //then this is the same console what we are looking for
{
   AttachConsole(cppid);
   WriteConsole(szBuffer);
   FreeConsole();
}
else
{
 //continue with FindWindow till the right parent is identified
}

Also smoke isn't calling CA directly instead its validation engine invokes
these CA through msiexec process, so GetParentPID has to get its 2 parents
for to cmd.exe PID


Now I need to redirect validation errors that are displayed in console to
log file I know this could be done by using something like

smoke.exe - cub myCub.cub myMSI.msi > smoke.log

but every time I run the smoke the log file gets overwritten, is there a way
that I can append to the existing log file.

If I do create my own logging in the CA then this log contains only those
logs generated by my CA which in case the other validations of ICEs (1-100)
done by darice.cub will not be listed into my log file, so this is not the
efficient solution. It would be much efficient if the log file generated by
> switch in the command line could get appended every time the program is
executed


Nag

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc]
Sent: Tuesday, December 22, 2009 11:54 PM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] writing to console from smoke.exe using
customaction

I already tried below solution but is not writing to console, I think
MsiProcessMessage works only if the custom action is run through msiexec or
if the CA is immediate mode, but where as I am running these CA through
smoke utility & for the CA to be made immediate I will have to create the CA
from using installer project work space.

In some of samples I have seen it uses OutputDebugString for writing it to
the console

Naga Ram M Chavakula | Project Manager

Re: [WiX-users] Source files and MSI file location.

[Blair]

As I understand it, the SourceDir property must be the root of the source
tree (the directory tree that the files and folders you are installing), and
it is set to be the directory location of the MSI file itself.

Can you move setup.msi to the Conent folder?

-Original Message-
From: V0id [mailto:void.i...@gmail.com] 
Sent: Wednesday, December 30, 2009 12:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Source files and MSI file location.

Hi!
Help me pls. I need to separate source files for the installation from 
.msi file.
Example (G:\ - name of the CD-drive):

G:\Setup\setup.msi - actual location of the .msi file)
G:\Conent\CD1\*.* - set of files and folders that i need to install.

How can i do this? I try to use Layout property of the Media element 
(like http://www.esetnod32.ru




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


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

Re: [WiX-users] Setting properties in custom actions

[Blair]

Windows Installer evaluates component conditions during CostFinalize, so
your custom action that sets those session values must be scheduled before
then. I would recommend scheduling those types of actions to run before
CostInitialize, just to have a "smoother" flow.

-Original Message-
From: David Allen [mailto:david.al...@1spatial.com] 
Sent: Saturday, January 02, 2010 4:48 AM
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] Setting properties in custom actions

Resending this question since it appeared not to get through before
Christmas, just after joining the list.

I am updating an installer for a product that provides multiple applications
and want to change it so that it creates shortcuts only for applications
that have a valid licence.

The basic approach is to define each shortcut in a separate component, to
set a condition on the component based on the value of a property and to
execute a custom action to set an appropriate value for the property based
on the licence before the shortcuts are created.

If I set different values when defining the properties in the main product
XML, I can see the correct shortcuts get created. However, any changes to
properties made by the custom action have no effect.

Within the Product element
- define the applications for which we may wish to create shortcuts


- define a property for each application

  


- declare the custom action



- arrange for it to be invoked on install

   NOT (REMOVE = "ALL")
   


- create the desktop shortcuts


  

  
  
INSTALL_DESKTOP_SHORTCUTS AND $(var._cut) = 1
  

  
  
  

  
  

  


The custom action VBScript is:

Option Explicit

Function CheckLicence()
   On error resume next

   MsgBox("CheckLicence: " + Session.Property("LAMPS2"))
   Session.Property("LAMPS2") = "1"
   Session.Property("translate") = "1"
   MsgBox("CheckLicence: " + Session.Property("LAMPS2"))
End Function

I see both message boxes pop up, showing that the property has been
modified.  In the log file, it appears this has been executed before the
shortcuts:

InstallFiles: File: Copying new files,  Directory: ,  Size:
Action ended 11:12:25: InstallFiles. Return value 1.
Action 11:12:25: CheckApplicationLicence.
Action start 11:12:25: CheckApplicationLicence.
Action ended 11:12:29: CheckApplicationLicence. Return value 1.
Action 11:12:29: CreateShortcuts. Creating shortcuts
Action start 11:12:29: CreateShortcuts.
CreateShortcuts: Shortcut: Creating shortcuts
Action ended 11:12:29: CreateShortcuts. Return value 1.
Action 11:12:29: WriteRegistryValues. Writing system registry values

If I start with all the properties having a value of 0 and set them to 1 in
the custom action, no shortcuts are created.  If I start with a value of 1
and set them to 0 in the custom action, all the shortcuts are created.

I presume I have made some sort of simple mistake, but I can't see what it
is.  Help much appreciated.

I am using the final (July) release of WiX 3 on Windows XP SP2 32-bit.

David

--
David Allen,
Development Manager - Core,
Telephone: +44 (0)1223 420 414



1Spatial Group Limited; Registered in England No. 4785688 VAT Reg. No.
816329821; Registered Office: Cavendish House; 6 Cambridge Business Park;
Cambridge; CB4 0WZ; United Kingdom

http://www.1spatial.com/



1Spatial: unlocking data, empowering business
Making geospatial data current, accessible, easily shared and trusted

www.1spatial.com

1Spatial Group Limited; Registered in England No. 4785688 VAT Reg. No.
816329821; Registered Office: Tennyson House; Cambridge Business Park;
Cambridge; CB4 0WZ; United Kingdom


IMPORTANT NOTICE
 
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this e-mail in error please notify the sender
immediately and delete this e-mail from your system. Please note that any
views or opinions presented in this e-mail are solely those of the author
and do not necessarily represent those of 1Spatial Group Limited, its
subsidiaries or associated companies, except where the author specifically
states them to be the views of 1Spatial Group Limited, its subsidiaries or
associated companies. 
 
1Spatial Group Limited, its subsidiaries and associated companies will not
be held liable for any legally binding obligations that are not the subject
of an official 1Spatial purchase order or as part of a contract signed by a
director of one of the aforementioned companies.
 
Although the company has taken reasonable precautions to ensure no viruses
are present in this email, the company cannot accept responsibility for any
loss or damage arising from the use of this email or attachments. You should
understand and accept that, when communicating with us by e-mail, it is not
a totally secure communication

Re: [WiX-users] differentiating between COM & C++ dlls from installerdatabase (.msi)

[Blair]

You could try an "administrative install". You could also try heat.exe's
extraction option.

The APIs involve extracting the cabs and then using the cabinet APIs to
extract the files, for the cases where the files are compressed & embedded.

For external cabs, just the cabinet APIs. For non-compressed files, they are
already external to the MSI.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Sunday, January 03, 2010 10:01 PM
To: d...@rms.ro; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] differentiating between COM & C++ dlls from
installerdatabase (.msi)

Thanks Dan, is there an api that you could suggest for extracting the file
from msi database?


-Original Message-
From: d...@rms.ro [mailto:d...@rms.ro] 
Sent: Friday, January 01, 2010 1:30 AM
To: nagara...@symphony.cc; General discussion for Windows Installer XML
toolset.
Subject: Re: [WiX-users] differentiating between COM & C++ dlls from
installerdatabase (.msi)

The safest way is to extract the .dll files to a temporary directory
and verify if they export the method DllRegisterServer.
A COM .dll must export this method.
You can use the LoadLibrary and GetProcAddress Windows API-s for this.


Dan



Quoting "nagaram.c" :

> Thanks once again for clarification, I think if there is any way to locate
> non-COM file then that should be File table & selfReg table, like if
suppose
> if a particular record in File table has reference to selfReg then it is
COM
> component else a non-COM, but I am not really sure if the File table has
any
> relationship with selfReg table or not.
>
> - Nag
> -Original Message-
> From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
> Sent: Tuesday, December 29, 2009 4:48 AM
> To: nagara...@symphony.cc
> Subject: RE: [WiX-users] differentiating between COM & C++ dlls from
> installerdatabase (.msi)
>
> All COM, non-COM and .Net DLL files will be in the File table.
>
> .Net assemblies *may* be in the MSIAssembly table as well as the File
> table but dont have to be.
> If you install a .Net assembly into the application directory, then you
> can put it in the File table only.
>
> -Original Message-
> From: nagaram.c [mailto:nagara...@symphony.cc]
> Sent: 29 December 2009 10:37
> To: Peter Shirtcliffe; 'General discussion for Windows Installer XML
> toolset.'
> Subject: RE: [WiX-users] differentiating between COM & C++ dlls from
> installerdatabase (.msi)
>
> Hi,
>
> Thanks for your information.
>
> I have one more question. Is it true that both COM & non-COM are
> maintained in Files table & where as all .NET components are maintained
> under msiAssembly table
>
> - Nag
>
> -Original Message-
> From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
> Sent: Tuesday, December 29, 2009 4:28 AM
> To: nagara...@symphony.cc; General discussion for Windows Installer XML
> toolset.
> Subject: RE: [WiX-users] differentiating between COM & C++ dlls from
> installerdatabase (.msi)
>
> I presume you mean how do you differentiate between COM and non-COM DLLs
> - some COM DLLs are written in C++ :)
>
> There is no certain way of spotting a COM DLL from the MSI alone because
> it might be self-registering, registered by an external application or
> be used with registry-free COM.
>
> If there is any COM registration information to be found in the MSI, it
> could be in any of the following:
>
> Class table
> ProgId table
> Registry table
> SelfReg table
> TypeLib table
>
> There is no equivalent of the MSIAssembly table for COM.
>
> -Original Message-
> From: nagaram.c [mailto:nagara...@symphony.cc]
> Sent: 29 December 2009 09:59
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: [WiX-users] differentiating between COM & C++ dlls from
> installerdatabase (.msi)
>
> Hi,
>
>
>
> Is there a way that I could differentiate between COM & C++ DLL by
> looking into the installer database file (.msi), I know that all .NET
> components are maintained in msiAssembly table but I think both COM &
> C++ files are maintained under Files table, is there a way by looking
> into some attributes in the table that I can know if that is of type C++
> DLL or COM component.
>
>
>
> Thanks,
>
> Nag
>
>
> 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.
>
>
>

--
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
easy
> Join now and get 

Re: [WiX-users] writing to console from smoke.exe using customaction

[Blair]

What is the "Windows Installer project workspace" you speak of?

The custom action code itself isn't "marked" for one or the other. That
marking is done by the type setting in the CustomAction table for the custom
action (the "InScript" flag). There are differences in what code that is run
as either deferred or immediate can do/access, but those are beside the
point.

My C++ custom actions that I put in my custom .CUB files are simply Win32
dlls written in C++ where all the entry points are all Windows Installer
custom actions that are marked 'extern "C"' and are also listed in the .def
file to prevent any form of compiler/linker decoration.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Sunday, January 03, 2010 10:08 PM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.';
'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

Thanks Blair, yes I have read it in MSDN, but the example code for such
configuration uses Microsoft Installer project workspace in which there is a
properties toolbar for selecting either immediate or differed modes for the
selected CA, here in this case I created the CA DLL using VC++ project
workspace, there is no documentation that suggests what compiler setting is
needed for the custom action DLL to be run in immediate mode. Can you
suggest?

- Nag


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Thursday, December 31, 2009 9:47 PM
To: nagara...@symphony.cc; 'General discussion for Windows Installer XML
toolset.'; 'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

Custom Actions in CUB files are supposed to be immediate custom actions.
Please read MSDN. Use MsiProcessMessage.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Thursday, December 31, 2009 3:33 AM
To: 'Schrieken, Rene'; 'General discussion for Windows Installer XML
toolset.'
Subject: Re: [WiX-users] writing to console from smoke.exe using
customaction

With the below code WriteFile is returning false, GetLastError shows “Handle
is invalid”

 

Nag

  _  

From: Schrieken, Rene [mailto:rene.schrie...@logica.com] 
Sent: Tuesday, December 29, 2009 11:41 AM
To: General discussion for Windows Installer XML toolset.
Cc: nagara...@symphony.cc
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

 

Looking at your code and reading msdn WriteConsole(szBuffer); might fail.
Something with ansi and widechar but this is really not my area of
expertise. Can you try to see if this might work: (everybody else: HELP!)

 

AttachConsole(...);

HANDLE file;

file = GetStdHandle(STD_OUTPUT_HANDLE); 

// check if you have something valid

// you might need an if for non-redirected output?
BOOL ok;

ok = WriteFile(file, szBuffer, somesafelenfunc(szBuffer), &written, NULL);

// check if true is returned

FreeConsole(...);

 

 

Please save everything before you try this... 

 

  _  

Van: nagaram.c [mailto:nagara...@symphony.cc]
Verzonden: di 29-12-2009 8:04
Aan: Schrieken, Rene; 'General discussion for Windows Installer XML
toolset.'; 'General discussion for Windows Installer XML toolset.'
Onderwerp: Re: [WiX-users] writing to console from smoke.exe using
customaction

Thanks for that, but it is only writing to file what ever is displayed in
the command window through other ICE(s) (ICE1 - 1CE100) performed by
darice.cub, but not those of my CA even through it can display in the
command window



Nag

  _ 

From: Schrieken, Rene [mailto:rene.schrie...@logica.com]
Sent: Thursday, December 24, 2009 10:46 AM
To: nagara...@symphony.cc; General discussion for Windows Installer XML
toolset.; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction



smoke.exe - cub myCub.cub myMSI.msi >> smoke.log



(use two >> to redirect output, that will open the file for append, instead
of create)



  _ 

Van: nagaram.c [mailto:nagara...@symphony.cc]
Verzonden: do 24-12-2009 6:46
Aan: 'General discussion for Windows Installer XML toolset.'; 'Blair'
Onderwerp: Re: [WiX-users] writing to console from smoke.exe using
customaction



I found a solution, the custom action DLL isn't writing to console unless I
call AttachConsole as like below

cpid = GetCurrentProcessId();
hWnd = FindWindowEx(NULL, NULL, _T("ConsoleWindowClass"), NULL);
//this need not be the same console where the process is running at
//need to fetch parent process id & check if they are same
GetWindowThreadProcessId(hWnd, & ppid);
cppid = GetParentPID(cpid); //user defined function to get the parent id

if(cppid == ppid) //then this is the same console what we are looking 

Re: [WiX-users] Overwrite property only if it was not set on command line

[Blair]

The only thing you can do is compare the current value of the property
against the known default value. If the command-line value is the same as
the default value you wouldn't ever be able to know.

The only way to know for sure if a property was set from the command-line is
to not have the property in the Property table at all and to assign it its
default value from some sort of custom action.

-Original Message-
From: Alex Ivanoff [mailto:alex.ivan...@shavlik.com] 
Sent: Sunday, January 03, 2010 10:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Overwrite property only if it was not set on command
line

I have a property that has a default value. I want to change this property
in custom action only if this property was not set on command line. How do I
do this?

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


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

Re: [WiX-users] writing to console from smoke.exe using customaction

[Blair]

Something like this?

int SendSampleICEMessage(void)
{
PMSIHANDLE hRecord = MsiCreateRecord(1);

UINT error = MsiRecordSetString(hRecord, 0, 
"Name of ICE\tMessage Type\tDescription\tHelp URL or location\tTable
Name\tColumn Name\tPrimary Key\tPrimary Key\tPrimary Key . . . (repeat for
as many primary keys as needed)"); // first three tab-delimited fields are
required. Primary Key are the values of the primary key columns in order.
Most tables have only one.

if (0 == error)
{
return MsiProcessMessage(hInstall, INSTALLMESSAGE_USER, hRecord);
}
return (int) error;
}

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Monday, January 04, 2010 5:20 AM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.';
'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

I tried this option but still the issue exist. 

- Nag


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, January 04, 2010 5:22 AM
To: nagara...@symphony.cc; 'General discussion for Windows Installer XML
toolset.'; 'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

What is the "Windows Installer project workspace" you speak of?

The custom action code itself isn't "marked" for one or the other. That
marking is done by the type setting in the CustomAction table for the custom
action (the "InScript" flag). There are differences in what code that is run
as either deferred or immediate can do/access, but those are beside the
point.

My C++ custom actions that I put in my custom .CUB files are simply Win32
dlls written in C++ where all the entry points are all Windows Installer
custom actions that are marked 'extern "C"' and are also listed in the .def
file to prevent any form of compiler/linker decoration.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Sunday, January 03, 2010 10:08 PM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.';
'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

Thanks Blair, yes I have read it in MSDN, but the example code for such
configuration uses Microsoft Installer project workspace in which there is a
properties toolbar for selecting either immediate or differed modes for the
selected CA, here in this case I created the CA DLL using VC++ project
workspace, there is no documentation that suggests what compiler setting is
needed for the custom action DLL to be run in immediate mode. Can you
suggest?

- Nag


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Thursday, December 31, 2009 9:47 PM
To: nagara...@symphony.cc; 'General discussion for Windows Installer XML
toolset.'; 'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

Custom Actions in CUB files are supposed to be immediate custom actions.
Please read MSDN. Use MsiProcessMessage.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Thursday, December 31, 2009 3:33 AM
To: 'Schrieken, Rene'; 'General discussion for Windows Installer XML
toolset.'
Subject: Re: [WiX-users] writing to console from smoke.exe using
customaction

With the below code WriteFile is returning false, GetLastError shows “Handle
is invalid”

 

Nag

  _  

From: Schrieken, Rene [mailto:rene.schrie...@logica.com] 
Sent: Tuesday, December 29, 2009 11:41 AM
To: General discussion for Windows Installer XML toolset.
Cc: nagara...@symphony.cc
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

 

Looking at your code and reading msdn WriteConsole(szBuffer); might fail.
Something with ansi and widechar but this is really not my area of
expertise. Can you try to see if this might work: (everybody else: HELP!)

 

AttachConsole(...);

HANDLE file;

file = GetStdHandle(STD_OUTPUT_HANDLE); 

// check if you have something valid

// you might need an if for non-redirected output?
BOOL ok;

ok = WriteFile(file, szBuffer, somesafelenfunc(szBuffer), &written, NULL);

// check if true is returned

FreeConsole(...);

 

 

Please save everything before you try this... 

 

  _  

Van: nagaram.c [mailto:nagara...@symphony.cc]
Verzonden: di 29-12-2009 8:04
Aan: Schrieken, Rene; 'General discussion for Windows Installer XML
toolset.'; 'General discussion for Windows Installer XML toolset.'
Onderwerp: Re: [WiX-users] writing to console from smoke.exe using
customaction

Thanks for that, but it is only writing to file what ever is displayed in
the command window through other ICE(s) (ICE1 - 1CE100) performed by
darice.cub, but not those of my CA even through it can display in the
command window



Nag

 

Re: [WiX-users] Build time selection of codepage...

[Blair]

Easiest way is via .WXL files. Since each can contain just one culture you
simply use that file to set the codepage (and don't set the codepage in the
database code itself). The biggest limitation with this idea is you can't
directly set the summary codepage this way, but you can use loc variables
(e.g. "!(loc.SummaryCodePage)") for that, so you achieve the same effective
result.

The biggest gotcha is that the summary codepage cannot be set to UTF-8
(unlike the rest of the database) and I tend to force ASCII-7 (and thus NO
localization) for the summary codepage myself (since I have usually had to
deal with "unicode-only" languages).

-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com] 
Sent: Monday, January 04, 2010 11:41 AM
To: WiX Users
Subject: [WiX-users] Build time selection of codepage...

Is it possible to specify the codepage value at build time based on
the build culture and/or build configuration name?

-- 
Tony


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


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

Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

[Blair]

Most patches should not have any references under PatchFamily (nor more than
one PatchFamily). That will cause ALL changes between the target and
upgraded images to be included in the patch.

Some (generally very large and complicated) setups require scoping the
changes into groups/series/buckets where different changes are tracked
separately. PatchFamilies were implemented for them.

-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Monday, January 04, 2010 1:58 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to patch an installer dialog using WIX 3.0?

What do we need to include in a patch WXS file to let WIX know that the
patch should include a new dialog that is added to the installer UI? I tried
this with UIRef element under PatchFamily, with the ID of the dialog, but it
does not seem to include it in the patch.

Thanks,

Sharat Janapareddy
~ 40269


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


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

Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

[Blair]

The last time I built an MSP file, I had only one PatchFamily and it had NO
children at all. I built it this way:







To have the PatchFamily in a different fragment from the Patch element (as
you have) you would need to include an appropriate PatchFamilyRef to pull in
the corresponding fragment.

However, to use your authoring for your patch (where you list everything you
are patching), you would need to change your dialog authoring like this
(adding the ID to your UI element):


...


...


...

-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Monday, January 04, 2010 3:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

Blair, if we don't have ANY references under PatchFamily, how can we tell
WIX which change should be included in the patch? Without listing every
changed component/property/etc. in the patch WXS file, none of the changes
are making to the final MSP.

FYI, I am able to patch custom actions, components, etc. using their
corresponding Ref elements under PatchFamily element. However, when a new
dialog is added to the updated MSI, I see this change in all the transform
files, but the final MSP does not have this change.

Below is an excerpt from my patch's WXS file. Note that the component,
custom action and the property are patched as expected.


...











And this is how the dialog is defined in the MSI's WXS file.


...


...


...


Thanks,

Sharat Janapareddy
~ 40269

-Original Message-----
From: Blair [mailto:os...@live.com] 
Sent: Monday, January 04, 2010 2:24 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

Most patches should not have any references under PatchFamily (nor more than
one PatchFamily). That will cause ALL changes between the target and
upgraded images to be included in the patch.

Some (generally very large and complicated) setups require scoping the
changes into groups/series/buckets where different changes are tracked
separately. PatchFamilies were implemented for them.

-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com]
Sent: Monday, January 04, 2010 1:58 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to patch an installer dialog using WIX 3.0?

What do we need to include in a patch WXS file to let WIX know that the
patch should include a new dialog that is added to the installer UI? I tried
this with UIRef element under PatchFamily, with the ID of the dialog, but it
does not seem to include it in the patch.

Thanks,

Sharat Janapareddy
~ 40269


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



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



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


--
This SF.Net email is spon

Re: [WiX-users] multiple instances wix source code

[Blair]

Look at InstanceTransforms element?

-Original Message-
From: angela jones [mailto:suggestionang...@gmail.com] 
Sent: Monday, January 04, 2010 3:37 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] multiple instances wix source code

Hello,
I have built and msi for installing a bunch of custom windows
services using visual studio setup. During install use the visual studio
custom actions radio button to allow the user to choose 'Dev/Prod/Trn/QA'. I
use this context parameter in my service installers to modify the service
name and install dir. This works correctly. However while uninstalling since
it does not have the custom action the service name is the unmodified one
and uninstall fails

How can I modify the wix wxs file to
1) give the user a choice to uninstall 'Dev/Prod/Trn/QA'
2) allow the user to install all the 4 instances in the same machine -
multiple instances.

If someone has already done it could you please send me your wxs file. Has
anyone accomplished this with a bootstrapper if yes is it the
dotnetinstaller?

thanks,
wixuser

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


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

Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

[Blair]

My primary role in the WiX-based patching solution was adding the "-delta"
switch to Pyro, along with all the related authoring changes and
implementation. Since the products I worked with all went the "simple" route
with regard to patching I never used, except for an experiment or two, any
patch families that were not filtered (which is what you get when you
declare children of a PatchFamily element). Our products where mostly
removing Windows Installer UI due to various factors so I never experimented
with UI beyond the simple case of not filtering the patch family.

As I understand it, the dialog changes should be pulled in due to their
connection to the UI element you reference, but that could be incorrect. I
don't know if you can use a DialogRef under PatchFamily (I don't honestly
know if there is a DialogRef, either) although that could be looked up
easily enough. Otherwise, I would have to ask other members of this list who
use both patch families and Windows Installer UI to chime in with their
knowledge and/or experience.

If no one can help, I'll carve some time away to test the scenario and look
in the debugger to see what it really is/isn't doing. I'm interested to
understand patchfamilies better myself.

-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Monday, January 04, 2010 5:56 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

Thanks for the explaining that Blair. I already have everything in place for
the PatchFamily and PatchFamilyRef. So, that part is good and I am able to
generate the patch without any issues.

The only thing that I am not sure is if I can use the UIRef for including a
new dialog (added to the updated MSI) in the patch. Looks to me that I have
to have an ID associated with the UI element under Wix/Product. I don't have
that right now. So, I added the ID to the UI element, build the MSI,
regenerate the MSP and I still don't see the new dialog in the patch!
Another thing is, unlike the components, custom actions, properties, etc., I
can't find this new ID I added in the updated MSI when I opened it through
Orca. Any ideas on that?

Thanks,

Sharat Janapareddy
~ 40269


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, January 04, 2010 5:12 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

The last time I built an MSP file, I had only one PatchFamily and it had NO
children at all. I built it this way:







To have the PatchFamily in a different fragment from the Patch element (as
you have) you would need to include an appropriate PatchFamilyRef to pull in
the corresponding fragment.

However, to use your authoring for your patch (where you list everything you
are patching), you would need to change your dialog authoring like this
(adding the ID to your UI element):


...


...


...

-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com]
Sent: Monday, January 04, 2010 3:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

Blair, if we don't have ANY references under PatchFamily, how can we tell
WIX which change should be included in the patch? Without listing every
changed component/property/etc. in the patch WXS file, none of the changes
are making to the final MSP.

FYI, I am able to patch custom actions, components, etc. using their
corresponding Ref elements under PatchFamily element. However, when a new
dialog is added to the updated MSI, I see this change in all the transform
files, but the final MSP does not have this change.

Below is an excerpt from my patch's WXS file. Note that the component,
custom action and the property are patched as expected.


...











And this is how the dialog is defined in the MSI's WXS file.


...


...


...


Thanks,

Sharat Janapareddy
~ 40269

-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Monday, January 04, 2010 2:24 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How to patch an installer dialog using WIX 3.0?

Most patches should not have any references under PatchFamily (nor more than
one PatchFamily). That will cause ALL changes between the target and
u

Re: [WiX-users] writing to console from smoke.exe using customaction

[Blair]

Tests in a .CUB are always run from a sequence table (similar to the UI
sequence table, but the sequence table is named _ICESequence) and never as
control events (there is no UI associated with ICE tests).

Why is a control event even an issue?

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Monday, January 04, 2010 10:39 PM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.';
'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

It looks like MsiProcessMessage works only in case if CA is called through
UI Sequence, it returns 0 (No action was taken) while the CA is called
through control event, below posting has similar issue

http://www.mombu.com/microsoft/platform-sdk-msi/t-how-to-check-whether-a-ca-
is-called-by-a-controlevent-320176.html

An alternative is Session.Message but this I cannot use in C++ code 

- Nag
-----Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, January 04, 2010 3:57 PM
To: nagara...@symphony.cc; 'General discussion for Windows Installer XML
toolset.'; 'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

Something like this?

int SendSampleICEMessage(void)
{
PMSIHANDLE hRecord = MsiCreateRecord(1);

UINT error = MsiRecordSetString(hRecord, 0, 
"Name of ICE\tMessage Type\tDescription\tHelp URL or location\tTable
Name\tColumn Name\tPrimary Key\tPrimary Key\tPrimary Key . . . (repeat for
as many primary keys as needed)"); // first three tab-delimited fields are
required. Primary Key are the values of the primary key columns in order.
Most tables have only one.

if (0 == error)
{
return MsiProcessMessage(hInstall, INSTALLMESSAGE_USER, hRecord);
}
return (int) error;
}

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Monday, January 04, 2010 5:20 AM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.';
'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

I tried this option but still the issue exist. 

- Nag


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, January 04, 2010 5:22 AM
To: nagara...@symphony.cc; 'General discussion for Windows Installer XML
toolset.'; 'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

What is the "Windows Installer project workspace" you speak of?

The custom action code itself isn't "marked" for one or the other. That
marking is done by the type setting in the CustomAction table for the custom
action (the "InScript" flag). There are differences in what code that is run
as either deferred or immediate can do/access, but those are beside the
point.

My C++ custom actions that I put in my custom .CUB files are simply Win32
dlls written in C++ where all the entry points are all Windows Installer
custom actions that are marked 'extern "C"' and are also listed in the .def
file to prevent any form of compiler/linker decoration.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Sunday, January 03, 2010 10:08 PM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.';
'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

Thanks Blair, yes I have read it in MSDN, but the example code for such
configuration uses Microsoft Installer project workspace in which there is a
properties toolbar for selecting either immediate or differed modes for the
selected CA, here in this case I created the CA DLL using VC++ project
workspace, there is no documentation that suggests what compiler setting is
needed for the custom action DLL to be run in immediate mode. Can you
suggest?

- Nag


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Thursday, December 31, 2009 9:47 PM
To: nagara...@symphony.cc; 'General discussion for Windows Installer XML
toolset.'; 'Schrieken, Rene'
Subject: RE: [WiX-users] writing to console from smoke.exe using
customaction

Custom Actions in CUB files are supposed to be immediate custom actions.
Please read MSDN. Use MsiProcessMessage.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Thursday, December 31, 2009 3:33 AM
To: 'Schrieken, Rene'; 'General discussion for Windows Installer XML
toolset.'
Subject: Re: [WiX-users] writing to console from smoke.exe using
customaction

With the below code WriteFile is returning false, GetLastError shows “Handle
is invalid”

 

Nag

  _  

From: Schrieken, Rene [mailto:rene.schrie...@logica.com] 
Sent: Tuesday, December 29, 2009 11:41 AM
To: General discussion for Windows Installer XML 

Re: [WiX-users] Build time selection of codepage...

[Blair]

If you notice there are two places in the authoring where you set codepages
(once in the Product element for the database, and once in the Package
element for the "SummaryCodepage"). While there are warnings in MSDN against
using utf-8 for the database, experience has demonstrated a prohibition (at
least with MSI 3.x) of using it for the summary codepage since the MSI will
be seen as corrupted by the operating system if you attempt that.

There are several (generally newer) languages that use scripts for which
non-Unicode codepages don't exist for Windows (at least not provided by
MSFT). Most of the various languages from India, for example. What I did for
my teams was to require that the text in the summary information stream
remain in English and be constrained to 7-bit ASCII (MSI recognizes that as
the codepage "0") while the database would take the most appropriate
codepage for the language/culture it was targeting (substituting utf-8 when
the default codepage according to .Net was utf-16).

The rational for that decision was that an effort was made to enact the
concept "English is just another language" which forces good globalization
practices but requires that everything localizable be fully localizable.
Since we couldn't represent the text in the summary information stream in
all of the target languages, and since we never exposed our MSIs to the
clients directly, the decision was made that the text in the summary
information stream wasn't localizable and it was removed from all
globalization concerns (the only thing that is "localized" is the language
setting).

If you aren't targeting any languages that don't have codepages you will
likely be fine but if you are contemplating targeting any of those languages
you may want to consider how you will deal with the difference in support
available from Windows Installer between summary information and the rest of
the database.

-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com] 
Sent: Tuesday, January 05, 2010 7:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build time selection of codepage...

> The biggest gotcha is that the summary codepage cannot be set to UTF-8
> (unlike the rest of the database) and I tend to force ASCII-7 (and thus NO
> localization) for the summary codepage myself (since I have usually had to
> deal with "unicode-only" languages).

You lost me here.  I understood the first part...

On Mon, Jan 4, 2010 at 5:06 PM, Blair  wrote:
> Easiest way is via .WXL files. Since each can contain just one culture you
> simply use that file to set the codepage (and don't set the codepage in
the
> database code itself). The biggest limitation with this idea is you can't
> directly set the summary codepage this way, but you can use loc variables
> (e.g. "!(loc.SummaryCodePage)") for that, so you achieve the same
effective
> result.
>
> The biggest gotcha is that the summary codepage cannot be set to UTF-8
> (unlike the rest of the database) and I tend to force ASCII-7 (and thus NO
> localization) for the summary codepage myself (since I have usually had to
> deal with "unicode-only" languages).
>
> -Original Message-
> From: Tony [mailto:yellowjacketl...@gmail.com]
> Sent: Monday, January 04, 2010 11:41 AM
> To: WiX Users
> Subject: [WiX-users] Build time selection of codepage...
>
> Is it possible to specify the codepage value at build time based on
> the build culture and/or build configuration name?
>
> --
> Tony
>
>

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

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



-- 
Tony

-

Re: [WiX-users] Problem with mouse disappearing

[Blair]

The sourceforge group email system often strips attachments. Please consider
posting the wxs file to a server somewhere and include a URL in the email to
retrieve it.

Thanks.

-Original Message-
From: Helgi Hrafn Gunnarsson [mailto:he...@binary.is] 
Sent: Tuesday, January 05, 2010 7:29 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with mouse disappearing

Hi.

First, thanks for a cool product. :)

I have a problem and I'll get right to it. When the final screen pops up and
tells the user that the installation is complete, the mouse has disappeared
and doesn't reappear until you move it off of the form. This is from a
project that I'm taking over from someone else who is not available, and I
couldn't find anything about this online.

Included is my Product.wxs file.

Any suggestions appreciated. Thanks in advance.

Kind regards,
Helgi Hrafn Gunnarsson
he...@binary.is


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

Re: [WiX-users] Updating XML written with XmlFile

[Blair]

During your "change" transaction set the REINSTALL property to include the
feature(s) that include the components you would like to change.

-Original Message-
From: Kevin Garman [mailto:gar...@scadaware.com] 
Sent: Tuesday, January 05, 2010 6:19 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Updating XML written with XmlFile

O
k, that makes sense from the development side.  Ideally I'd like to be
able to click the 'change' button and then be able to change settings
(xml entries).  Any ideas how I could make this happen?


-- 
Thanks,

Kevin Garman, Project Engineer

SCADAware, Inc.
www.scadaware.com




Thanks



On Mon, 2010-01-04 at 20:06 -0800, Rob Mensching wrote: 

> Repair the Component.
> 
> On Mon, Jan 4, 2010 at 11:57 AM, Kevin Garman 
wrote:
> 
> > Hi,
> >
> > I have a component that includes some xml values that are written out
> > using XmlFile.  I want to be able to rerun the installer and change the
> > values without changing the install state of the component, but it seems
> > that it only writes the values when the component is going from
> > uninstalled to installed.  Does anyone know how to achieve the
> > functionality I'm after---currently I heading the direction of custom
> > actions but that's not preferred.
> >
> > Thanks,
> > Kevin
> >
> >
> >

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

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


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

Re: [WiX-users] Passwords, hidden and the log file

[Blair]

Add



To your authoring

-Original Message-
From: Balu Swaminathan [mailto:bswa...@hotmail.com] 
Sent: Tuesday, January 05, 2010 10:55 AM
To: wix user list
Subject: [WiX-users] Passwords, hidden and the log file


Hello All:

 

 

I have:

 



 

and the value passed on PASSWORD is written to the log file when the .msi is 
invoked with 

 

msiexec ... /l*v msilog.log ...

 

Investigation starts... In the log file it appears as 

 

and it appears in the log file as

 

MSI (s) (BC!80) [10:39:39:772]: PROPERTY CHANGE: Adding ConfigureIIsExec 
property. Its value is 
'ConfigureIIs€1€5€1€User€1€Component_€1€Name€1€Domain€1€Password€1€3€OURUSERID€C_OurUserAccount€_abc€mgdContoso€passwordIsHere€4€2€1€0€0€2€1€16€1€AppPool€1€Name€1€Component_€1€Attributes€2€User_€1

 

so it looks like ConfigureIIs is writing it.

 

Is there someway to prevent the password being written to the log file in this 
scenario where we configure a custom appPool, virtual directory, etc. in the 
MSI. ?

 

Thanks

 

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


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

Re: [WiX-users] Build time selection of codepage...

[Blair]

Do those MSIs have embedded streams? Might those streams contain transforms?
Transforms can change the codepage of a database.

I don't know if Orca shows the summary-codepage. I believe it just shows the
database codepage.

There also do exist many non-Unicode multi-byte codepages (there are
something like three different ones for Japanese alone, any one of which
will work for pretty much anyone) which is how most multi-byte scripts are
supported in Windows Installer. The Unicode-only languages are, for the most
part, for languages using writing scripts that were added to the universe of
MSFT operating systems after Windows 98 was released.

UTF-8 databases will have a codepage of 65001.

-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com] 
Sent: Tuesday, January 05, 2010 1:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build time selection of codepage...

Thanks.

While looking a quite a few msi with Orca, I see many have their code
page set to 0.  Which you mentioned means "ASCII" (7-bit).  However,
many of these same msi have dialogs which contain multi-byte
characters when installed on multi-byte OS platforms (like Chinese and
Japanese), how is this possible?  Or is that what you mean by having a
"UTF-8 database"?  I know UTF-8 encoding supports multi-byte character
sets.  So, maybe that is how these msi are working?


On Tue, Jan 5, 2010 at 1:40 PM, Blair  wrote:
> If you notice there are two places in the authoring where you set
codepages
> (once in the Product element for the database, and once in the Package
> element for the "SummaryCodepage"). While there are warnings in MSDN
against
> using utf-8 for the database, experience has demonstrated a prohibition
(at
> least with MSI 3.x) of using it for the summary codepage since the MSI
will
> be seen as corrupted by the operating system if you attempt that.
>
> There are several (generally newer) languages that use scripts for which
> non-Unicode codepages don't exist for Windows (at least not provided by
> MSFT). Most of the various languages from India, for example. What I did
for
> my teams was to require that the text in the summary information stream
> remain in English and be constrained to 7-bit ASCII (MSI recognizes that
as
> the codepage "0") while the database would take the most appropriate
> codepage for the language/culture it was targeting (substituting utf-8
when
> the default codepage according to .Net was utf-16).
>
> The rational for that decision was that an effort was made to enact the
> concept "English is just another language" which forces good globalization
> practices but requires that everything localizable be fully localizable.
> Since we couldn't represent the text in the summary information stream in
> all of the target languages, and since we never exposed our MSIs to the
> clients directly, the decision was made that the text in the summary
> information stream wasn't localizable and it was removed from all
> globalization concerns (the only thing that is "localized" is the language
> setting).
>
> If you aren't targeting any languages that don't have codepages you will
> likely be fine but if you are contemplating targeting any of those
languages
> you may want to consider how you will deal with the difference in support
> available from Windows Installer between summary information and the rest
of
> the database.
>
> -Original Message-
> From: Tony [mailto:yellowjacketl...@gmail.com]
> Sent: Tuesday, January 05, 2010 7:12 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Build time selection of codepage...
>
>> The biggest gotcha is that the summary codepage cannot be set to UTF-8
>> (unlike the rest of the database) and I tend to force ASCII-7 (and thus
NO
>> localization) for the summary codepage myself (since I have usually had
to
>> deal with "unicode-only" languages).
>
> You lost me here.  I understood the first part...
>
> On Mon, Jan 4, 2010 at 5:06 PM, Blair  wrote:
>> Easiest way is via .WXL files. Since each can contain just one culture
you
>> simply use that file to set the codepage (and don't set the codepage in
> the
>> database code itself). The biggest limitation with this idea is you can't
>> directly set the summary codepage this way, but you can use loc variables
>> (e.g. "!(loc.SummaryCodePage)") for that, so you achieve the same
> effective
>> result.
>>
>> The biggest gotcha is that the summary codepage cannot be set to UTF-8
>> (unlike the rest of the database) and I tend to force ASCII-7 (and thus
NO
>> localization) for the summary codepage myself 

Re: [WiX-users] Shortcut path for Merge modules

[Blair]

What you don't say is whether what you ship are the merge modules themselves
or if you simply use them as internal "global" libraries for the MSIs you
build. You also don't say whether you are porting all at once or in stages.

-Original Message-
From: Bill Packard [mailto:bill.pack...@kepware.com] 
Sent: Tuesday, January 05, 2010 9:55 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Shortcut path for Merge modules

I am evaluating whether I can port our installations from Wise to Wix. We
have several merge modules, each of which contains a set of files and a
couple of shortcuts. In the Wise definition we use a global property to
define the shortcut path for the merge modules. I can use the substitution
tables to tweak the directory table, and use the global property, but was
wondering if there was some other (better) way to accomplish this? 

http://schemas.microsoft.com/wix/2006/wi";>









  
  
  


 
  
  

  
  

  


  


When the merge module is merged into the msi the directory table is updated
and the user defined property SMPRODNAME (set in UI sequence) becomes the
parent of the SMHelp directory. I am simply wondering if there is some other
way to accomplish this?

Thanks,
Bill





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


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

Re: [WiX-users] How to create extension and a new schema ?

[Blair]

I know that the WixVsExtension defines properties like VS90_SCHEMAS_DIR that
would be the directory you would need to place the .xsd file into. Use the
appropriate property for the version of Visual Studio you are targeting.

Beyond that, either MSDN or the forums on MSDN would have much more
information on this topic.

-Original Message-
From: akihiro.shib...@jp.yokogawa.com
[mailto:akihiro.shib...@jp.yokogawa.com] 
Sent: Tuesday, January 05, 2010 6:16 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to create extension and a new schema ?

HI,

I develop a new extension.  And I written a new schema in xsd file.
I create a new setup project on Visual Studio, 
But it show display message  that "Id" attribute cannot found on the message
view of Visual Studio .

How to import a new schema file and use on Visual Studio? 
something wrong ?



1) xsd file like this:


---

http://www.w3.org/2001/XMLSchema";
 
xmlns:xse="http://schemas.microsoft.com/wix/2005/XmlSchemaExtension";
 xmlns:html="http://www.w3.org/1999/xhtml";
 targetNamespace="http://schema.www..com/wix/2009";>









http://schemas.microsoft.com/wix/2006/wi"; ref="Component" />









 

   





---

2) extending the CompilerExntension and overriding  a parse method. 

public override void ParseElement(SourceLineNumberCollection
sourceLineNumbers, XmlElement parentElement, XmlElement element, params
string[] contextValues)
{
switch (parentElement.LocalName)
{
case "Component":
string fileId = contextValues[0];
switch (element.LocalName)
{
case "AppendUserGroup ":
 this.ParseAppendUserGroupElement(element,
fileId);
break;
default:
this.Core.UnexpectedElement(parentElement,
element);
break;
}
break;
default:
this.Core.UnexpectedElement(parentElement, element);
break;
}
}

 3) insert AssemblyDefaultWixEtension into AsseblyInfo.cs

 4) a new setup project


---
http://schema.microsoft.com/wix/2006/wi";
 xmlns:myutil="http://schema.www..com/wix/2009";>
:

  

:



---

Thanks, 

Akihiro Shibuta.


 



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


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

Re: [WiX-users] getting win32 exception while running the newly added custom ICE

[Blair]

Is it at all possible that the new ICE900 test you wrote uses the C++
runtime DLL?

In your C++ build settings you need to make sure you link to the static
runtime library AND that you build Release (not Debug) for the version you
run away from the developer's box.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Tuesday, January 05, 2010 11:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] getting win32 exception while running the newly added
custom ICE

Hi,

 

I am getting below exception to my newly added ICE, whereas the same works
fine in the developer environment but fails in the tester environment, both
are XP machines.

 

To the tester environment I have deployed the below files

 

smoke.exe 

wconsole.dll 

wix.dll 

darice.cub (containing the newly added CA DLL)

 

.

..

ICE99: Created 06/18/2004. Last Modified 06/18/2004.

ICE100: ICE100 - Validates the MsiEmbeddedUI Table, checking for duplicate
filenames and validity of order values, attributes, etc.

ICE100: Created 04/02/2007. Last Modified 04/02/2007.

smoke.exe : error SMOK0216 : An unexpected Win32 exception with error code
0x643 occurred: Action - 'ICE900' Fatal error during installation

 

Thanks,

Nag

 


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


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

Re: [WiX-users] getting win32 exception while running the newly added custom ICE

[Blair]

The default build settings for native C++ code generation is to use the
runtime DLLs that come with VS2008 (which are NOT resident by default in any
OS). For Custom Action use, that isn't the build setting you want.

Open the project properties dialog, navigate to Configuration Properties -->
C/C++ --> Code Generation, select Debug in the Configuration drop-down at
the top of the dialog, change the Runtime Library setting to "Multi-threaded
Debug (/MTd)", select Release in the Configuration drop-down at the top of
the dialog (approving saving the changes in the confirmation dialog), change
the Runtime Library setting to "Multi-threaded (/MT)", then hit Apply and
OK.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Wednesday, January 06, 2010 5:17 AM
To: 'Blair'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] getting win32 exception while running the newly
added custom ICE

Hi,

With the release DLL I am getting these below errors, I am using VS2008 for
creating this C++ DLL, can you please suggest which of the linker setting I
have to select in the project properties dialog for to specify Static
Runtime Library setting.

smoke.exe : error SMOK0217 : Error executing ICE action 'ICE900'. The most
common cause of this kind of ICE failure is an incorrectly registered
scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for
details and how to solve this problem. The following string format was not
expected by the external UI message logger: "There is a problem with this
Windows Installer package. A DLL required for this install to complete could
not be run. Contact your support personnel or package vendor.  ".
smoke.exe : error SMOK0217 : Error executing ICE action 'ICE903'. The most
common cause of this kind of ICE failure is an incorrectly registered
scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for
details and how to solve this problem. The following string format was not
expected by the external UI message logger: "There is a problem with this
Windows Installer package. A DLL required for this install to complete could
not be run. Contact your support personnel or package vendor.  ".
Thanks,
Nag
-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, January 06, 2010 4:54 AM
To: nagara...@symphony.cc; 'General discussion for Windows Installer XML
toolset.'
Subject: RE: [WiX-users] getting win32 exception while running the newly
added custom ICE

Is it at all possible that the new ICE900 test you wrote uses the C++
runtime DLL?

In your C++ build settings you need to make sure you link to the static
runtime library AND that you build Release (not Debug) for the version you
run away from the developer's box.

-Original Message-
From: nagaram.c [mailto:nagara...@symphony.cc] 
Sent: Tuesday, January 05, 2010 11:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] getting win32 exception while running the newly added
custom ICE

Hi,

 

I am getting below exception to my newly added ICE, whereas the same works
fine in the developer environment but fails in the tester environment, both
are XP machines.

 

To the tester environment I have deployed the below files

 

smoke.exe 

wconsole.dll 

wix.dll 

darice.cub (containing the newly added CA DLL)

 

.

..

ICE99: Created 06/18/2004. Last Modified 06/18/2004.

ICE100: ICE100 - Validates the MsiEmbeddedUI Table, checking for duplicate
filenames and validity of order values, attributes, etc.

ICE100: Created 04/02/2007. Last Modified 04/02/2007.

smoke.exe : error SMOK0216 : An unexpected Win32 exception with error code
0x643 occurred: Action - 'ICE900' Fatal error during installation

 

Thanks,

Nag

 


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



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

Re: [WiX-users] Installing WiX 3.5

[Blair]

If you use the MSI, it only allows one installation of WiX at a time
(installing 3.5 will replace 3.0).

Other than that, I have not yet used 3.5 with VS2008, so I wouldn't know of
any issues with opening the files, but you can always disable building the
3.0 WiX project before you install 3.5 and add 3.5 projects after upgrading,
then copy over your settings and source files (which will allow you to
switch back with relative ease).

If you intend to use a non-RTM release of WiX then please be prepared to
take frequent updates (including dealing with any breaking changes that
result) to get bug fixes and support, which means it may not be a good idea
for use on production code (depending on what features you use). Having said
that, we are striving to not change the 3.0 features much in 3.5 to minimize
those kinds of impacts, but the warning is always valid. As far as timing
goes, the last I have heard is to release 3.5 shortly after VS2010.

-Original Message-
From: pmdarrow [mailto:pdar...@metaworks.com] 
Sent: Wednesday, January 06, 2010 5:52 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Installing WiX 3.5


Hi all, are there any gotchas when installing WiX 3.5 alongside or over 3.0?
I'd like to add the IIS7 capabilities to my installer from the WiX IIS
extension. I've read some mailing list posts that suggest there are issues
when opening Votive projects made with 3.0 in WiX 3.5. Any suggestions?

Peter
-- 
View this message in context:
http://n2.nabble.com/Installing-WiX-3-5-tp4260705p4260705.html
Sent from the wix-users mailing list archive at Nabble.com.


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


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

Re: [WiX-users] Passing installation parameter to exe

[Blair]

Preagent.exe is a file you are installing, using for configuration, or both?
You need to call it with those parameters as the installing user or
elevated? It needs to be visible to the user when it runs or not? It should
have those parameters every time it runs or just once? Can you do the same
thing to the OS that it does with those parameters without running it?

-Original Message-
From: Shlomi Tsadok [mailto:shl...@tsadok.net] 
Sent: Wednesday, January 06, 2010 7:23 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Passing installation parameter to exe

Hi,

Here is the relevant lines from the wxs file:

 
 
  

How do I pass installtion parameters to preagent.exe?

For example "preagent.exe -d d:\tmp"


Thanks,

Shlomi


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


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

Re: [WiX-users] Shortcut path for Merge modules

[Blair]

I'll have to let those people on this list that are more knowledgeable than
I about merge modules guide you as to whether there are better ways for you
to proceed. With my limited knowledge what you have looks fine. I would
recommend you convert the merge modules to wixlibs at the time or shortly
thereafter you convert the MSI projects to WiX, however.

-Original Message-
From: Bill Packard [mailto:bill.pack...@kepware.com] 
Sent: Wednesday, January 06, 2010 6:44 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Shortcut path for Merge modules

Blair,

The merge modules are internal only. At this point I am expecting to convert
all merge modules to wix, but initially leave the msi projects in Wise. The
merge modules are simple, only a few have more than payload and resources.
The msi projects are significantly more involved and will require more time
than I have right now.

I can currently create a more or less identical merge module with either
wise or wix, and have written a script to transform the wise merge module
projects to wix source.

Wise lets certain things pass, such as global properties, that wix allows
but warns about (SuppressModularization). I'm just trying to figure out the
best way to implement with wix functionality that effectively duplicates
what we can do with wise. I don't think that wixlibs are a possibility at
this point, though might be once all the msi projects are converted as well.
Oh, and I am using wix 3.0.5419.0.

Thanks,
bill

-Original Message-
Date: Tue, 5 Jan 2010 14:39:51 -0800
From: "Blair" 
Subject: Re: [WiX-users] Shortcut path for Merge modules
To: "'General discussion for Windows Installer XML toolset.'"

Message-ID: 
Content-Type: text/plain; charset="us-ascii"

What you don't say is whether what you ship are the merge modules themselves
or if you simply use them as internal "global" libraries for the MSIs you
build. You also don't say whether you are porting all at once or in stages.

-Original Message-
From: Bill Packard [mailto:bill.pack...@kepware.com]
Sent: Tuesday, January 05, 2010 9:55 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Shortcut path for Merge modules

I am evaluating whether I can port our installations from Wise to Wix. We
have several merge modules, each of which contains a set of files and a
couple of shortcuts. In the Wise definition we use a global property to
define the shortcut path for the merge modules. I can use the substitution
tables to tweak the directory table, and use the global property, but was
wondering if there was some other (better) way to accomplish this? 

http://schemas.microsoft.com/wix/2006/wi";>









  
  
  


 
  
  

  
  

  


  


When the merge module is merged into the msi the directory table is updated
and the user defined property SMPRODNAME (set in UI sequence) becomes the
parent of the SMHelp directory. I am simply wondering if there is some other
way to accomplish this?

Thanks,
Bill





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


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

Re: [WiX-users] Performance Counters supported for MSP?

[Blair]

Your keypath is 'DT.MyDir' (as you have authored it).

-Original Message-
From: Jeff Perrigo [mailto:jeff.perr...@microsoft.com] 
Sent: Wednesday, January 06, 2010 5:18 PM
To: General discussion for Windows Installer XML toolset.
Cc: Bob Arnson
Subject: Re: [WiX-users] Performance Counters supported for MSP?

Hi Bob,

I'm fairly new to WiX/Windows Installer, but I think things are starting to
click.  The keypath is set at the component level for the counters
component.  This one has been a little confusing since the component itself
doesn't specify a directory.  There is an include in a DirectoryRef which
includes the file that contains the counters component, so I believe the
keypath must be that directory.  Since a patch can't change the keypath of a
component I'm assuming I can't create a patch that is uninstallable if I
include this component.  I've included a sample of the code that I am
maintaining for clarification.

  

  
  

  

  

  

  
   

  

  There is also a feature that includes:
  
  

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Tuesday, January 05, 2010 5:02 AM
To: General discussion for Windows Installer XML toolset.
Cc: Jeff Perrigo
Subject: Re: [WiX-users] Performance Counters supported for MSP?

On 12/31/2009 6:05 PM, Jeff Perrigo wrote:
> I understand that patches cannot be uninstallable if they modify the
CreateFolder table.  I can set the patch so it is not uninstallable to get
around this issue, but I'm wondering where CreateFolder comes in since my
component does not use CreateFolder.  Does Util:PerformanceCounter
automatically update the CreateFolder table?

No. What's the keypath of your component?

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




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


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

Re: [WiX-users] Passing installation parameter to exe

[Blair]

The second questions asks if you can set registry values/write file
changes/whatever else that running the preagent.exe would have done for you
to avoid using it.

Is preagent.exe needed by your installation after it is complete or only
when installing, repairing, upgrading, and possibly removing the product?

-Original Message-
From: Shlomi Tsadok [mailto:shl...@tsadok.net] 
Sent: Wednesday, January 06, 2010 10:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Passing installation parameter to exe

1. Preagent.exe is an instalation file of Novell ZenWorks agent.
2. I need to call it with parameters as the installing user(the system
account in this case).
3. It will run unatennded, enforced by a machine GPO.
4. It should have those parameters every time it runs.

"Can you do the same thing to the OS that it does with those parameters
without running it?"
Sorry, I didn't understand this quastion..


Thanks for your time,

Shlomi

On Wed, Jan 6, 2010 at 6:26 PM, Blair  wrote:

> Preagent.exe is a file you are installing, using for configuration, or
> both?
> You need to call it with those parameters as the installing user or
> elevated? It needs to be visible to the user when it runs or not? It
should
> have those parameters every time it runs or just once? Can you do the same
> thing to the OS that it does with those parameters without running it?
>
> -Original Message-
> From: Shlomi Tsadok [mailto:shl...@tsadok.net]
> Sent: Wednesday, January 06, 2010 7:23 AM
> To: wix-users@lists.sourceforge.net
>   Subject: [WiX-users] Passing installation parameter to exe
>
> Hi,
>
> Here is the relevant lines from the wxs file:
>
>  
>  Name="PREAGENT.EXE"
> src="\\mf1\apps\Users\APPS_XP\Zen10Agent\GPO_MSI\preagent.exe"
> DiskId="1" Compressed="no"/>
>  
>
> How do I pass installtion parameters to preagent.exe?
>
> For example "preagent.exe -d d:\tmp"
>
>
> Thanks,
>
> Shlomi
>
>
>

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

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

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


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