Re: [WiX-users] Delete temp files during uninstall

[post]

Not able to test, but try something like this (from the documentation):





Kind regards

Hans


>
> thanks Hans.
> Tried the third option of QTExec and it errors out.
> with the following message:
>
> CAQuietExec:  Error 0x80070057: failed to get command line data
> CAQuietExec:  Error 0x80070057: failed to get Command Line
>
> This is from my wxs:
>
>Property="QtExecCmdLine"
> Value=""c:\windows\system32\cmd.exe" rmdir /s /q
> "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
> Files\myapplication""/>
>
>BinaryKey="WixCA"
> DllEntry="CAQuietExec"
> Execute="immediate"
> Return="check"/>
>
>
>
> post wrote:
>>
>> Hi Vivek,
>>
>> You have at least these options:
>>
>> 1)Create a DTF custom action
>> 2)Create a VB script custom action
>> 3)Look into Quiet Execution Custom Action (ref Wix Help file)
>>
>> and then put a condition like REMOVE="ALL" so it does not get run on
>> installs.
>>
>> If these files and folders are not installed by the msi, you can not use
>> RemoveFolder or RemoveFile(s) according to the help file documentation.
>>
>> Kind regards,
>>
>> Hans
>>
>>
>>> I have a requirement to delete temporary files at
>>> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
>>> Files. As the number of directories and files created by the
>>> application
>>> are
>>> close to 200 and RemoveFolder,RemoveFile with "*" is only
>>> on a directory and not recursive, makes it harder to do for every
>>> directory.
>>> Do we have any other solution?
>>> Can we run a dos command rmdir /s /q? If so how to do it in WiX?
>>>
>>> thanks,
>>> Vivek
>>>
>>> 
>>> -
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> ___
>>> 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 Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> 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/Delete-temp-files-during-uninstall-tp1130780p1132763.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> 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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Delete temp files during uninstall

[vivek.anandan]

thanks Hans.
Tried the third option of QTExec and it errors out.
with the following message:

CAQuietExec:  Error 0x80070057: failed to get command line data
CAQuietExec:  Error 0x80070057: failed to get Command Line

This is from my wxs:



  



post wrote:
> 
> Hi Vivek,
> 
> You have at least these options:
> 
> 1)Create a DTF custom action
> 2)Create a VB script custom action
> 3)Look into Quiet Execution Custom Action (ref Wix Help file)
> 
> and then put a condition like REMOVE="ALL" so it does not get run on
> installs.
> 
> If these files and folders are not installed by the msi, you can not use
> RemoveFolder or RemoveFile(s) according to the help file documentation.
> 
> Kind regards,
> 
> Hans
> 
> 
>> I have a requirement to delete temporary files at
>> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
>> Files. As the number of directories and files created by the application
>> are
>> close to 200 and RemoveFolder,RemoveFile with "*" is only
>> on a directory and not recursive, makes it harder to do for every
>> directory.
>> Do we have any other solution?
>> Can we run a dos command rmdir /s /q? If so how to do it in WiX?
>>
>> thanks,
>> Vivek
>>
>> 
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> 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 Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> 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/Delete-temp-files-during-uninstall-tp1130780p1132763.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Scheduling custom action at end of install

[Alan Sinclair]

I need to have a merge module custom action happen at the end of the
InstallExecuteSequence.
 
Normally I sequence a "MyFinalize" custom action in a merge module as
being after InstallFinalize, but if RemoveExistingProducts follows
InstallFinalize then MyFinalize must be after RemoveExistingProducts.
Because this is a merge module I don't have any insight into which of
InstallFinalize or RemoveExistingProducts will come last. 
 
How can I code my CA to be after everything else?
 
 
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Richard]

In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> Have you ever generated the WiX registry code for
> VB6 COM component? Has anyone?

Oh, I almost forgot -- yes, I have registered VB6 COM components
manually by populating the Class, etc., tables.  I haven't done it
with WiX; I did it by editing an MSI with Orca directly.  (When I did
this, WiX didn't exist yet.)  So yes, I know it can be done and it can
work reliably.  We never had any problems with the VB6 components that
we registered in this way.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Richard]

In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> Richard 
> 
> >> The answer to that is pretty simple -- you ignore anything that's not
> >> related to your component.
> 
> I think you are missing the point (or I am), how do I know it is not
> related?

Well, the things that are related to your COM object are laid out in
the COM specification.  I'm assuming since its your COM object, that
you know the CLSIDs, IIDs, etc., that go with your object.

> In VB6 you don't edit the COM registration so you don't know
> the details.

True, but you do decide the ProgId that exposes your COM object and
for the places where COM is registering a server, it is coupled to the
filename of the DLL containing the server, so you can link things back
that way.  There will also be a type library associated with your COM
object, to support VB6's dispinterface style late binding.  The type
library for a VB6 COM object is always contained in the DLL of the
object, so that's also coupled back to your object through the
filename.

> I have a fairly simple ocx and heat generates 182 lines of
> WiX code for it!

Can you post a URL to the generated WiX code from heat?  I'd like to
see what kind of stuff its generating.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Neil Sleightholm]

Richard 

>> The answer to that is pretty simple -- you ignore anything that's not
>> related to your component.

I think you are missing the point (or I am), how do I know it is not
related? In VB6 you don't edit the COM registration so you don't know
the details. I have a fairly simple ocx and heat generates 182 lines of
WiX code for it! I have tried a few times to remove the unrelated code
and never successfully got the component to work or to leave the machine
working on uninstall. Have you ever generated the WiX registry code for
VB6 COM component? Has anyone?

Neil

-Original Message-
From: Richard [mailto:[EMAIL PROTECTED] 
Sent: 01 October 2008 21:11
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness


In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> The key issue here is what do you need to exclude when registering a
VB6
> DLL or is it possible to monitor it so we find the key information.
Can
> you recommend a registry monitoring tool that works for VB6 DLL?

The answer to that is pretty simple -- you ignore anything that's not
related to your component.

It sounds to me like DllRegisterServer on a VB6 DLL "helps" you by
making sure that your dependencies (the VB6 runtime) is also
registered.  This was a problem in the early days when the VB6 runtime
was something you had to add onto windows.  I'm not certain which OS
started including the VB6 DLLs as part of "system", but IIRC they all
include the runtime dependencies now so you shouldn't ever need to do
that part.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
  

Legalize Adulthood! 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Weekly releases

[Rob Mensching]

No idea... thought the last one went through (but obviously didn't check).  
I'll make sure it goes through correctly this week.

-Original Message-
From: Alex Ivanoff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 12:16
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Weekly releases

What happened to weekly releases?



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Will XmlConfig do this?

[Chad Petersen]

My config file is simple. Just a configuration section.

 



 



 

I want to add a connectionStrings section inside the existing element.

 









 

However, the installer always does this

 





 



 

 

 

Any ideas?

Chad

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Richard]

In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> The key issue here is what do you need to exclude when registering a VB6
> DLL or is it possible to monitor it so we find the key information. Can
> you recommend a registry monitoring tool that works for VB6 DLL?

The answer to that is pretty simple -- you ignore anything that's not
related to your component.

It sounds to me like DllRegisterServer on a VB6 DLL "helps" you by
making sure that your dependencies (the VB6 runtime) is also
registered.  This was a problem in the early days when the VB6 runtime
was something you had to add onto windows.  I'm not certain which OS
started including the VB6 DLLs as part of "system", but IIRC they all
include the runtime dependencies now so you shouldn't ever need to do
that part.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Richard]

In article <[EMAIL PROTECTED]>,
Rob Mensching <[EMAIL PROTECTED]>  writes:

> Note, those actions are only necessary if you are using the Advertised
> features of COM registration otherwise it's all just Registry rows.

True.  So let me state it another way -- is there an ICE that fails if
your COM tables are populated but your action sequences don't contain
the COM registration actions?
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Richard]

In article <[EMAIL PROTECTED]>,
"Evans, Jim" <[EMAIL PROTECTED]>  writes:

> Interestingly, ProcMon (the successor to RegMon) was no help here, as
> all of the registration calls were being sent to HKEY_CLASSES_ROOT,
> which does not differentiate between which elements are going to the
> user hive and which to the local machine hive. Dumping the registry and
> comparing was the only way I could find the problem.

...but it would have told you what was wrong if you also ran ProcMon
on your install and compared the output.  You would have seen that one
set things in HKCR and the other set things in HKCU.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] major upgrades and component states

[Ian Elliott (Excell Data Corporation)]

I have some sql scripts that should only be run on initial install and never 
again. Unfortunately, before this was released, the scripts were in such a 
state such that they couldn't detect that they had already been run. So, when 
the component installs during the major upgrade the scripts run again and fail.

If I condition out the component that contains the scripts, it doesn't get 
installed during major upgrade. I see in the log that ComponentRegister then 
registers that component as State=-7. When you finally uninstall, the component 
does not get uninstalled. So, apparently conditioning the component on major 
upgrade causes it to remain upon uninstall.

This normally would be an issue I could live with except that the SqlDatabase 
tag is also part of this component. So, the database will not get removed on 
uninstall because it associated with the component that doesn't get uninstalled 
for some reason I don't understand.



NOT OLDAPPFOUND





















Log snippets:
Install:
Component: CID_AccountDatabase; Installed: Absent;   Request: Local;   Action: 
Local
ComponentRegister(ComponentId={1B56E106-923A-4CDE-82D2-15BC5E7F4165},KeyPath=C:\blah\,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)

Major Upgrade:
Component: CID_AccountDatabase; Installed: Absent;   Request: Local;   Action: 
Null
ComponentRegister(ComponentId={1B56E106-923A-4CDE-82D2-15BC5E7F4165},,State=-7,,Disk=1,SharedDllRefCount=0,BinaryType=0)

Uninstall:
Component: CID_AccountDatabase; Installed: Local;   Request: Absent;   Action: 
Null
ComponentUnregister(ComponentId={1B56E106-923A-4CDE-82D2-15BC5E7F4165},,BinaryType=0,PreviouslyPinned=1)


My understanding of the component states is as follows. Please tell me if or 
where I'm mistaken.
Install:
Installed: Absent - this component is not installed
Request: Local - the component should be installed locally
Action: Local - the component will be installed locally

Major Upgrade:
Installed: Absent - ?
Request: Local - the component should be installed locally unless conditioned 
out
Action: Null - the component will not be installed because it was conditioned 
out

Uninstall:
Installed: Local - the component is installed locally
Request: Absent - the component is requested to be removed
Action: Null - ?



1.)I don't understand the logging from the upgrade. Why does it list 
"Installed" as "Absent" when it really is installed?

2.)During uninstall, why is the "Action" listed as "Null" indicating not to 
uninstall yet the ComponentUnregsiter is removing the component registration as 
though the component is being uninstalled?

Any help in understanding is appreciated.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Weekly releases

[Alex Ivanoff]

What happened to weekly releases?



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Moving from InstallShield 12 to wix

[Bryan Turner]

Q: I'm also curious why you chose to use an Include instead of using a Fragment 
with a ComponentGroup in it that is pulled in at link time?

A: Ignorance.

It seems like what you are suggesting is more complicated than my current 
solution, but its more likely that I simply don't fully understand what you are 
suggesting.

My problem came in automatically generating the list of files.  It looked like 
Heat would do the job, but when I implemented, I got errors when I tried to 
bring that into my install because the Heat generated file included the 
DirectoryRef as well.  I also liked that using my current implementation, I can 
clearly identify the entire directory structure, component GUID, and if 
necessary, registry entries associated with a given component, the only thing 
in my include file is the list of files to be included in that component...

 

  
  
  



Again, most of what I have done is because I still don't fully understand WIX.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 11:07 AM
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Understood and I'm just trying to ensure that everyone understands that the 
reasons the WiX toolset doesn't have a general purpose tool that solves this 
problem because a "correct and complete" solution is very, very difficult to 
implement.  

I'm also curious why you chose to use an Include instead of using a Fragment 
with a ComponentGroup in it that is pulled in at link time?

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:49
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Rob,

You are correct, it does require some diligence on the source control side.

In my case, I do dynamic file pickup on files that are not to be patched or 
updated .  For example, we don't patch sample files, so the dynamically 
included files are locked down after we release, thereby eliminating this 
problem.  This requires some planning to be properly implemented.  By creating 
the list of files dynamically, and then using them in an include file, I can 
check the include file in once we are locked down for a release and then I 
don't have to worry about new files being dynamically picked up.  I am not 
advocating this for everyone, I just do not want to be manually updating files 
in the install every time something is changed.


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:14 AM
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

1.  What happens if you want to add or remove one of those sample files?  You 
can't technically add or remove resources from a Component so that would break 
things... unless you guaranteed a major upgrade.  Like I said, it gets tricky.

3.  Did you actually specify any Files to be compressed?  Either set the 
Compress attribute on the File or compress everything by default by setting 
Package/@Compress.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:00
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Rob,

I am using one component for a group of files, not all my files.  For example, 
non-versioned files like samples that are all grouped into the same directory 
(and therefore the same component) should be safely grouped in one component, I 
believe.

Regarding the embed cab, it does not work for me, I simply get this warning:
warning LGHT1079 : The cabinet 'product.cab' does not contain any files.  If 
this installation contains no files, this warning can likely be safely ignored. 
 Otherwise, please addfiles to the cabinet or remove it.


Here is the email I sent on this earlier, although I never did see it hit the 
message board (probably user error)...
Hello, I think I am missing something obvious

I am using Wix 3.0.4429.  In my .wxs file, I have the following elements:







  



  
  


When I link with Light, I get this warning, and my files are not compressed 
into an internal cab inside the .msi, but are instead uncompressed next to the 
.msi

light.exe Core.wixobj -out Core.msi -nologo
Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain 
any files.  If this installation contains no files, this warning can likely be 
safely ignored.  Otherwise, please addfiles to the cabinet or remove it.

If anyone ca

Re: [WiX-users] Moving from InstallShield 12 to wix

[Rob Mensching]

Understood and I'm just trying to ensure that everyone understands that the 
reasons the WiX toolset doesn't have a general purpose tool that solves this 
problem because a "correct and complete" solution is very, very difficult to 
implement.  

I'm also curious why you chose to use an Include instead of using a Fragment 
with a ComponentGroup in it that is pulled in at link time?

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:49
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Rob,

You are correct, it does require some diligence on the source control side.

In my case, I do dynamic file pickup on files that are not to be patched or 
updated .  For example, we don't patch sample files, so the dynamically 
included files are locked down after we release, thereby eliminating this 
problem.  This requires some planning to be properly implemented.  By creating 
the list of files dynamically, and then using them in an include file, I can 
check the include file in once we are locked down for a release and then I 
don't have to worry about new files being dynamically picked up.  I am not 
advocating this for everyone, I just do not want to be manually updating files 
in the install every time something is changed.


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:14 AM
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

1.  What happens if you want to add or remove one of those sample files?  You 
can't technically add or remove resources from a Component so that would break 
things... unless you guaranteed a major upgrade.  Like I said, it gets tricky.

3.  Did you actually specify any Files to be compressed?  Either set the 
Compress attribute on the File or compress everything by default by setting 
Package/@Compress.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:00
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Rob,

I am using one component for a group of files, not all my files.  For example, 
non-versioned files like samples that are all grouped into the same directory 
(and therefore the same component) should be safely grouped in one component, I 
believe.

Regarding the embed cab, it does not work for me, I simply get this warning:
warning LGHT1079 : The cabinet 'product.cab' does not contain any files.  If 
this installation contains no files, this warning can likely be safely ignored. 
 Otherwise, please addfiles to the cabinet or remove it.


Here is the email I sent on this earlier, although I never did see it hit the 
message board (probably user error)...
Hello, I think I am missing something obvious

I am using Wix 3.0.4429.  In my .wxs file, I have the following elements:







  



  
  


When I link with Light, I get this warning, and my files are not compressed 
into an internal cab inside the .msi, but are instead uncompressed next to the 
.msi

light.exe Core.wixobj -out Core.msi -nologo
Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain 
any files.  If this installation contains no files, this warning can likely be 
safely ignored.  Otherwise, please addfiles to the cabinet or remove it.

If anyone can see the obvious, please let me know.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 9:22 AM
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

1.  One Component with all your files in it is a can be a very dangerous 
design.  There are a lot of servicing scenarios where you might be very unhappy 
with that decision.  The difficulty of autogenerating Components that meet all 
"good design guidelines" is why we don't have a good tool in WiX yet... 
knowingly painful.

2.  No doubt.  I believe, there are several tools around who's strengths are on 
UI editing.

3.  It is simple:   
also set Package/@Compressed="yes" to get everything compressed, or compress 
File elements individually.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 09:06
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

I just moved a project from IS 12 to WIX, other than what has been pointed out 
below, here is what I did:

1.  Created my IS 12 generated msm's
2.  Ripped out all the IS tables in the .msm's with 

Re: [WiX-users] Moving from InstallShield 12 to wix

[Bryan Turner]

Rob,

You are correct, it does require some diligence on the source control side.

In my case, I do dynamic file pickup on files that are not to be patched or 
updated .  For example, we don't patch sample files, so the dynamically 
included files are locked down after we release, thereby eliminating this 
problem.  This requires some planning to be properly implemented.  By creating 
the list of files dynamically, and then using them in an include file, I can 
check the include file in once we are locked down for a release and then I 
don't have to worry about new files being dynamically picked up.  I am not 
advocating this for everyone, I just do not want to be manually updating files 
in the install every time something is changed.


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:14 AM
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

1.  What happens if you want to add or remove one of those sample files?  You 
can't technically add or remove resources from a Component so that would break 
things... unless you guaranteed a major upgrade.  Like I said, it gets tricky.

3.  Did you actually specify any Files to be compressed?  Either set the 
Compress attribute on the File or compress everything by default by setting 
Package/@Compress.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:00
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Rob,

I am using one component for a group of files, not all my files.  For example, 
non-versioned files like samples that are all grouped into the same directory 
(and therefore the same component) should be safely grouped in one component, I 
believe.

Regarding the embed cab, it does not work for me, I simply get this warning:
warning LGHT1079 : The cabinet 'product.cab' does not contain any files.  If 
this installation contains no files, this warning can likely be safely ignored. 
 Otherwise, please addfiles to the cabinet or remove it.


Here is the email I sent on this earlier, although I never did see it hit the 
message board (probably user error)...
Hello, I think I am missing something obvious

I am using Wix 3.0.4429.  In my .wxs file, I have the following elements:







  



  
  


When I link with Light, I get this warning, and my files are not compressed 
into an internal cab inside the .msi, but are instead uncompressed next to the 
.msi

light.exe Core.wixobj -out Core.msi -nologo
Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain 
any files.  If this installation contains no files, this warning can likely be 
safely ignored.  Otherwise, please addfiles to the cabinet or remove it.

If anyone can see the obvious, please let me know.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 9:22 AM
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

1.  One Component with all your files in it is a can be a very dangerous 
design.  There are a lot of servicing scenarios where you might be very unhappy 
with that decision.  The difficulty of autogenerating Components that meet all 
"good design guidelines" is why we don't have a good tool in WiX yet... 
knowingly painful.

2.  No doubt.  I believe, there are several tools around who's strengths are on 
UI editing.

3.  It is simple:   
also set Package/@Compressed="yes" to get everything compressed, or compress 
File elements individually.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 09:06
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

I just moved a project from IS 12 to WIX, other than what has been pointed out 
below, here is what I did:

1.  Created my IS 12 generated msm's
2.  Ripped out all the IS tables in the .msm's with ORCA
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msm's with ORCA
4.  Ran dark.exe on the now gutted merge modules and diffed them against 
the IS generated ones
5.  Checked in my .wxs files that generate my .msm's
1.  Created my IS 12 generated .msi, without merging in all my .msm's, just 
wanted the bare .msi
2.  Ripped out all the IS tables in the .msi
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msi
4.  Ran the now gutted install to make sure it still worked
5.  Ran dark on the now gutted .msi's
6.  compiled and tested wi

Re: [WiX-users] COM registration weirdness

[Bob Arnson]

Neil Sleightholm wrote:
> My untested theory is that when you call DllRegisterServer on a VB6 DLL
> it either calls DllRegisterServer on MSVBVM60.dll or the code from it is
> embedded into the VB6 dll.
>   

In my experience, self-reg code gets extra-aggressive in response to bug 
reports to respond to symptoms rather than fixing underlying causes.

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



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Moving from InstallShield 12 to wix

[Rob Mensching]

1.  What happens if you want to add or remove one of those sample files?  You 
can't technically add or remove resources from a Component so that would break 
things... unless you guaranteed a major upgrade.  Like I said, it gets tricky.

3.  Did you actually specify any Files to be compressed?  Either set the 
Compress attribute on the File or compress everything by default by setting 
Package/@Compress.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:00
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Rob,

I am using one component for a group of files, not all my files.  For example, 
non-versioned files like samples that are all grouped into the same directory 
(and therefore the same component) should be safely grouped in one component, I 
believe.

Regarding the embed cab, it does not work for me, I simply get this warning:
warning LGHT1079 : The cabinet 'product.cab' does not contain any files.  If 
this installation contains no files, this warning can likely be safely ignored. 
 Otherwise, please addfiles to the cabinet or remove it.


Here is the email I sent on this earlier, although I never did see it hit the 
message board (probably user error)...
Hello, I think I am missing something obvious

I am using Wix 3.0.4429.  In my .wxs file, I have the following elements:







  



  
  


When I link with Light, I get this warning, and my files are not compressed 
into an internal cab inside the .msi, but are instead uncompressed next to the 
.msi

light.exe Core.wixobj -out Core.msi -nologo
Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain 
any files.  If this installation contains no files, this warning can likely be 
safely ignored.  Otherwise, please addfiles to the cabinet or remove it.

If anyone can see the obvious, please let me know.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 9:22 AM
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

1.  One Component with all your files in it is a can be a very dangerous 
design.  There are a lot of servicing scenarios where you might be very unhappy 
with that decision.  The difficulty of autogenerating Components that meet all 
"good design guidelines" is why we don't have a good tool in WiX yet... 
knowingly painful.

2.  No doubt.  I believe, there are several tools around who's strengths are on 
UI editing.

3.  It is simple:   
also set Package/@Compressed="yes" to get everything compressed, or compress 
File elements individually.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 09:06
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

I just moved a project from IS 12 to WIX, other than what has been pointed out 
below, here is what I did:

1.  Created my IS 12 generated msm's
2.  Ripped out all the IS tables in the .msm's with ORCA
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msm's with ORCA
4.  Ran dark.exe on the now gutted merge modules and diffed them against 
the IS generated ones
5.  Checked in my .wxs files that generate my .msm's
1.  Created my IS 12 generated .msi, without merging in all my .msm's, just 
wanted the bare .msi
2.  Ripped out all the IS tables in the .msi
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msi
4.  Ran the now gutted install to make sure it still worked
5.  Ran dark on the now gutted .msi's
6.  compiled and tested with my merged modules
7.  modified my build scripts to use WIX instead of IS to build

This was just finished, and it seems to be working OK.  WIX files are so much 
easier to maintain, and you can simply check the WIX folder into your source 
tree and your entire development/QA team can create installations without 
having to have IS installed.

However, here is what you will lose, in my opinion, and you need to be ready 
for this:

1.  the niceness that IS provides, like being able to just point it at a 
directory tree and telling the install to go gather up all the files and 
folders and add them to the install.  My dev team almost choked on that, so I 
had to role my own implementation of dynamically picking up files from a 
directory (but not recursively) and making sure that all the files were 
assigned only one GUID.  There are tools for this, like Heat.exe, Parafin, 
Tallow, etc... but I was unable to find one that would allow me to just use a 
wix include file to insert mu

Re: [WiX-users] Moving from InstallShield 12 to wix

[Bryan Turner]

Rob,

I am using one component for a group of files, not all my files.  For example, 
non-versioned files like samples that are all grouped into the same directory 
(and therefore the same component) should be safely grouped in one component, I 
believe.

Regarding the embed cab, it does not work for me, I simply get this warning:
warning LGHT1079 : The cabinet 'product.cab' does not contain any files.  If 
this installation contains no files, this warning can likely be safely ignored. 
 Otherwise, please addfiles to the cabinet or remove it.


Here is the email I sent on this earlier, although I never did see it hit the 
message board (probably user error)...
Hello, I think I am missing something obvious

I am using Wix 3.0.4429.  In my .wxs file, I have the following elements:







  



  
  


When I link with Light, I get this warning, and my files are not compressed 
into an internal cab inside the .msi, but are instead uncompressed next to the 
.msi

light.exe Core.wixobj -out Core.msi -nologo
Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain 
any files.  If this installation contains no files, this warning can likely be 
safely ignored.  Otherwise, please addfiles to the cabinet or remove it.

If anyone can see the obvious, please let me know.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 9:22 AM
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

1.  One Component with all your files in it is a can be a very dangerous 
design.  There are a lot of servicing scenarios where you might be very unhappy 
with that decision.  The difficulty of autogenerating Components that meet all 
"good design guidelines" is why we don't have a good tool in WiX yet... 
knowingly painful.

2.  No doubt.  I believe, there are several tools around who's strengths are on 
UI editing.

3.  It is simple:   
also set Package/@Compressed="yes" to get everything compressed, or compress 
File elements individually.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 09:06
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

I just moved a project from IS 12 to WIX, other than what has been pointed out 
below, here is what I did:

1.  Created my IS 12 generated msm's
2.  Ripped out all the IS tables in the .msm's with ORCA
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msm's with ORCA
4.  Ran dark.exe on the now gutted merge modules and diffed them against 
the IS generated ones
5.  Checked in my .wxs files that generate my .msm's
1.  Created my IS 12 generated .msi, without merging in all my .msm's, just 
wanted the bare .msi
2.  Ripped out all the IS tables in the .msi
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msi
4.  Ran the now gutted install to make sure it still worked
5.  Ran dark on the now gutted .msi's
6.  compiled and tested with my merged modules
7.  modified my build scripts to use WIX instead of IS to build

This was just finished, and it seems to be working OK.  WIX files are so much 
easier to maintain, and you can simply check the WIX folder into your source 
tree and your entire development/QA team can create installations without 
having to have IS installed.

However, here is what you will lose, in my opinion, and you need to be ready 
for this:

1.  the niceness that IS provides, like being able to just point it at a 
directory tree and telling the install to go gather up all the files and 
folders and add them to the install.  My dev team almost choked on that, so I 
had to role my own implementation of dynamically picking up files from a 
directory (but not recursively) and making sure that all the files were 
assigned only one GUID.  There are tools for this, like Heat.exe, Parafin, 
Tallow, etc... but I was unable to find one that would allow me to just use a 
wix include file to insert multiple files under a single component (and GUID).  
This could be user error/ignorance on my part.
2.  UI changes - If you need to modify the UI of your installer, you have 
lost that nice interface you get with a GUI based install tool like IS
3.  Still can't figure out how to embed the cab files into the .msi with 
WIX 3.0, even though it is supposed to be simple.  I am sure this is user error.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 7:49 AM
To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Re: [WiX-users] COM registration weirdness

[Neil Sleightholm]

Richard

This has gone off topic a bit but yes I have done complex c/c++
registrations and have monitored what happens when com is registered and
it all made sense until I monitored a VB6 DLL. 

For example, it always seems to rewrite this (among many many more):
Key:
HKCR\CLSID\{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}\InProcServer32
Value="C:\Windows\system32\MSVBVM60.DLL"
Which I think is part of the VB runtime and I certainly wouldn't want my
install to remove it. 

My untested theory is that when you call DllRegisterServer on a VB6 DLL
it either calls DllRegisterServer on MSVBVM60.dll or the code from it is
embedded into the VB6 dll.

The key issue here is what do you need to exclude when registering a VB6
DLL or is it possible to monitor it so we find the key information. Can
you recommend a registry monitoring tool that works for VB6 DLL?

Neil


-Original Message-
From: Richard [mailto:[EMAIL PROTECTED] 
Sent: 01 October 2008 16:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness


In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> All regsvr32 does is call DllRegisterServer on the DLL, what happens
in =
> here is voodoo! It is perfectly legal to d anything you want in this =
> call and is the reason why self registration is frowned upon.

Actually, no, its not perfectly legal to do anything you want in
DllRegisterServer.  You are *only* supposed to do COM registration
there.

Yeah, if you put other code in there, it will run.  But that is not
"legal" in terms of how you are supposed to implement this entry point
into the DLL.

> I know a =
> VB6 DLL is just doing standard COM stuff but it is way more
complicated =
> that any COM I have ever done in C++ [...]

I'm guessing that means you've never done dispinterfaces in C++ or
used other attributes of COM that are used by VB6.  VB6 supports late
binding on its COM servers, so there is a lot of infrastructure there
to support dispinterfaces, Invoke, etc.

> of things to make binary compatibility work. There are also references
=
> back to the VB runtime. I'm not saying it is not possible to make it =
> work by just writing registry entries but I have never got it to work,
=
> hence setting self reg (which I assume just calls DllRegisterServer) =
> works for me.  =20

The way to gather all the registry entries is to use a registry
capture tool to capture all the changes made to the registry when
regsvr32 is run on the DLL.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
  

Legalize Adulthood! 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Moving from InstallShield 12 to wix

[Rob Mensching]

1.  One Component with all your files in it is a can be a very dangerous 
design.  There are a lot of servicing scenarios where you might be very unhappy 
with that decision.  The difficulty of autogenerating Components that meet all 
"good design guidelines" is why we don't have a good tool in WiX yet... 
knowingly painful.

2.  No doubt.  I believe, there are several tools around who's strengths are on 
UI editing.

3.  It is simple:   
also set Package/@Compressed="yes" to get everything compressed, or compress 
File elements individually.

-Original Message-
From: Bryan Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 09:06
To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

I just moved a project from IS 12 to WIX, other than what has been pointed out 
below, here is what I did:

1.  Created my IS 12 generated msm's
2.  Ripped out all the IS tables in the .msm's with ORCA
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msm's with ORCA
4.  Ran dark.exe on the now gutted merge modules and diffed them against 
the IS generated ones
5.  Checked in my .wxs files that generate my .msm's
1.  Created my IS 12 generated .msi, without merging in all my .msm's, just 
wanted the bare .msi
2.  Ripped out all the IS tables in the .msi
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msi
4.  Ran the now gutted install to make sure it still worked
5.  Ran dark on the now gutted .msi's
6.  compiled and tested with my merged modules
7.  modified my build scripts to use WIX instead of IS to build

This was just finished, and it seems to be working OK.  WIX files are so much 
easier to maintain, and you can simply check the WIX folder into your source 
tree and your entire development/QA team can create installations without 
having to have IS installed.

However, here is what you will lose, in my opinion, and you need to be ready 
for this:

1.  the niceness that IS provides, like being able to just point it at a 
directory tree and telling the install to go gather up all the files and 
folders and add them to the install.  My dev team almost choked on that, so I 
had to role my own implementation of dynamically picking up files from a 
directory (but not recursively) and making sure that all the files were 
assigned only one GUID.  There are tools for this, like Heat.exe, Parafin, 
Tallow, etc... but I was unable to find one that would allow me to just use a 
wix include file to insert multiple files under a single component (and GUID).  
This could be user error/ignorance on my part.
2.  UI changes - If you need to modify the UI of your installer, you have 
lost that nice interface you get with a GUI based install tool like IS
3.  Still can't figure out how to embed the cab files into the .msi with 
WIX 3.0, even though it is supposed to be simple.  I am sure this is user error.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 7:49 AM
To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Sorry, caught the end of this thread.

1.  You need to maintain Component/@Guids according to the Component Rules.  It 
doesn't matter what tool you use to create the MSI.  Once you ship, you must 
maintain the GUIDs appropriately.

2.  ProductCodes and UpgradeCodes need to be updated following the Windows 
Installer rules for upgrades.  Major upgrade?  Change the ProductCode... etc.

3.  Dark.exe can help get all of your authoring and it will preserve all the 
GUIDs for you.  Technically speaking, you should be able to switch at any time 
and rebuild a functionally identical MSI file (although it may be a little 
smaller since WiX tries very hard to only add the things you need).

-Original Message-
From: Michael Owings [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 18:01
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Moving from InstallShield 12 to wix

I'm currently in the process of moving from an InstallShield 12 (which I
loathe)  project over to wix. I'd ideally like to be able to update the
next version of this project via wix.

I'm wondering if I use the the same product and component IDs if I'd be
in good shape as far as an upgrading goes. Any gotchas I should be aware of?

Thanx in advance -- m
--
Teleoperate a roving mobile robot from the web:
http://www.swampgas.com/robotics/rover.html

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://mobli

Re: [WiX-users] Moving from InstallShield 12 to wix

[Michael Owings]

Thanx -- I actually have an alternate wix installer already for our 
product -- I really just need to add another component or two and some 
more custom actions. For the most part the work is in rewriting the 
custom actions. Other than that, I just need to reorganize it a bit and 
use the old component and product IDs.

H -- tallow looks pretty useful. Could probably use a mention in the 
help file (although I'm using wix2).

Bryan Turner wrote:
> I just moved a project from IS 12 to WIX, other than what has been pointed 
> out below, here is what I did:
> 
> 1.  Created my IS 12 generated msm's
> 2.  Ripped out all the IS tables in the .msm's with ORCA
> 3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
> the .msm's with ORCA
> 4.  Ran dark.exe on the now gutted merge modules and diffed them against 
> the IS generated ones
> 5.  Checked in my .wxs files that generate my .msm's
> 1.  Created my IS 12 generated .msi, without merging in all my .msm's, 
> just wanted the bare .msi
> 2.  Ripped out all the IS tables in the .msi
> 3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
> the .msi
> 4.  Ran the now gutted install to make sure it still worked
> 5.  Ran dark on the now gutted .msi's
> 6.  compiled and tested with my merged modules
> 7.  modified my build scripts to use WIX instead of IS to build
> 
> This was just finished, and it seems to be working OK.  WIX files are so much 
> easier to maintain, and you can simply check the WIX folder into your source 
> tree and your entire development/QA team can create installations without 
> having to have IS installed.
> 
> However, here is what you will lose, in my opinion, and you need to be ready 
> for this:
> 
> 1.  the niceness that IS provides, like being able to just point it at a 
> directory tree and telling the install to go gather up all the files and 
> folders and add them to the install.  My dev team almost choked on that, so I 
> had to role my own implementation of dynamically picking up files from a 
> directory (but not recursively) and making sure that all the files were 
> assigned only one GUID.  There are tools for this, like Heat.exe, Parafin, 
> Tallow, etc... but I was unable to find one that would allow me to just use a 
> wix include file to insert multiple files under a single component (and 
> GUID).  This could be user error/ignorance on my part.
> 2.  UI changes - If you need to modify the UI of your installer, you have 
> lost that nice interface you get with a GUI based install tool like IS
> 3.  Still can't figure out how to embed the cab files into the .msi with 
> WIX 3.0, even though it is supposed to be simple.  I am sure this is user 
> error.
> 
> -Original Message-
> From: Rob Mensching [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 01, 2008 7:49 AM
> To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Moving from InstallShield 12 to wix
> 
> Sorry, caught the end of this thread.
> 
> 1.  You need to maintain Component/@Guids according to the Component Rules.  
> It doesn't matter what tool you use to create the MSI.  Once you ship, you 
> must maintain the GUIDs appropriately.
> 
> 2.  ProductCodes and UpgradeCodes need to be updated following the Windows 
> Installer rules for upgrades.  Major upgrade?  Change the ProductCode... etc.
> 
> 3.  Dark.exe can help get all of your authoring and it will preserve all the 
> GUIDs for you.  Technically speaking, you should be able to switch at any 
> time and rebuild a functionally identical MSI file (although it may be a 
> little smaller since WiX tries very hard to only add the things you need).
> 
> -Original Message-
> From: Michael Owings [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 30, 2008 18:01
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Moving from InstallShield 12 to wix
> 
> I'm currently in the process of moving from an InstallShield 12 (which I
> loathe)  project over to wix. I'd ideally like to be able to update the
> next version of this project via wix.
> 
> I'm wondering if I use the the same product and component IDs if I'd be
> in good shape as far as an upgrading goes. Any gotchas I should be aware of?
> 
> Thanx in advance -- m
> --
> Teleoperate a roving mobile robot from the web:
> http://www.swampgas.com/robotics/rover.html
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.s

Re: [WiX-users] Moving from InstallShield 12 to wix

[Bryan Turner]

I just moved a project from IS 12 to WIX, other than what has been pointed out 
below, here is what I did:

1.  Created my IS 12 generated msm's
2.  Ripped out all the IS tables in the .msm's with ORCA
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msm's with ORCA
4.  Ran dark.exe on the now gutted merge modules and diffed them against 
the IS generated ones
5.  Checked in my .wxs files that generate my .msm's
1.  Created my IS 12 generated .msi, without merging in all my .msm's, just 
wanted the bare .msi
2.  Ripped out all the IS tables in the .msi
3.  Ripped out all the IS custom actions, binaries, properties, etc... in 
the .msi
4.  Ran the now gutted install to make sure it still worked
5.  Ran dark on the now gutted .msi's
6.  compiled and tested with my merged modules
7.  modified my build scripts to use WIX instead of IS to build

This was just finished, and it seems to be working OK.  WIX files are so much 
easier to maintain, and you can simply check the WIX folder into your source 
tree and your entire development/QA team can create installations without 
having to have IS installed.

However, here is what you will lose, in my opinion, and you need to be ready 
for this:

1.  the niceness that IS provides, like being able to just point it at a 
directory tree and telling the install to go gather up all the files and 
folders and add them to the install.  My dev team almost choked on that, so I 
had to role my own implementation of dynamically picking up files from a 
directory (but not recursively) and making sure that all the files were 
assigned only one GUID.  There are tools for this, like Heat.exe, Parafin, 
Tallow, etc... but I was unable to find one that would allow me to just use a 
wix include file to insert multiple files under a single component (and GUID).  
This could be user error/ignorance on my part.
2.  UI changes - If you need to modify the UI of your installer, you have 
lost that nice interface you get with a GUI based install tool like IS
3.  Still can't figure out how to embed the cab files into the .msi with 
WIX 3.0, even though it is supposed to be simple.  I am sure this is user error.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 7:49 AM
To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Moving from InstallShield 12 to wix

Sorry, caught the end of this thread.

1.  You need to maintain Component/@Guids according to the Component Rules.  It 
doesn't matter what tool you use to create the MSI.  Once you ship, you must 
maintain the GUIDs appropriately.

2.  ProductCodes and UpgradeCodes need to be updated following the Windows 
Installer rules for upgrades.  Major upgrade?  Change the ProductCode... etc.

3.  Dark.exe can help get all of your authoring and it will preserve all the 
GUIDs for you.  Technically speaking, you should be able to switch at any time 
and rebuild a functionally identical MSI file (although it may be a little 
smaller since WiX tries very hard to only add the things you need).

-Original Message-
From: Michael Owings [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 18:01
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Moving from InstallShield 12 to wix

I'm currently in the process of moving from an InstallShield 12 (which I
loathe)  project over to wix. I'd ideally like to be able to update the
next version of this project via wix.

I'm wondering if I use the the same product and component IDs if I'd be
in good shape as far as an upgrading goes. Any gotchas I should be aware of?

Thanx in advance -- m
--
Teleoperate a roving mobile robot from the web:
http://www.swampgas.com/robotics/rover.html

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

---

Re: [WiX-users] COM registration weirdness

[Evans, Jim]

Glad you got this worked out. In my case, the problem was that I wasn't
specifying ALLUSERS=1, so I was inadvertently doing a per-user install
instead of a per-machine install. When the Windows service (running as
LocalSystem) tried to instantiate one of the COM objects, it couldn't
find the registration for it because it was registered in the CLSID
branch of HKEY_CURRENT_USER, not HKEY_LOCAL_MACHINE.

Interestingly, ProcMon (the successor to RegMon) was no help here, as
all of the registration calls were being sent to HKEY_CLASSES_ROOT,
which does not differentiate between which elements are going to the
user hive and which to the local machine hive. Dumping the registry and
comparing was the only way I could find the problem.

-Original Message-
From: Troy Howard [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 01, 2008 2:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness

Ok, I found a process that works...

First, I had to explicitly add:

  
  
  
  
  
  
  


then for each .net com dll, i ran heat against it to generate a wxs.

I then fixedup those wxs files in the following manner:
1. Wrap the Class/ProgID/etc tags inside the File tag so that
class/@server
gets set
2. Update the registry values that referred to mscoree.dll so that they
each
have a unique id in the Id attribute.

That combination get me functioning .Net COM DLLs, and now that I fully
understand what's happening, it makes sense. The default sequence
doesn't
include the com registration actions that read the class table/etc. So
those
have to be added. The heat output doesn't nest the class tags in the
file
tag, so server attribute doesn't know what it's target is. The registry
values for mscoree.dll are in conflict with the autogenerated ones made
form
the class tag, because they both use autogenerated ids, which are a hash
of
componentId, root, key, and name... And so they need to be differentiate
by
assigning a unique id.

I'm quite relieved I got it worked out.

Thanks,
Troy



On Tue, Sep 30, 2008 at 9:51 PM, Troy Howard <[EMAIL PROTECTED]>
wrote:

> It's both.
>
> The application is written in VB6. It uses COM DLLs written in various
> languages, including C++, VB6, and .NET. The installer needs to be
able to
> register all of these things.
>
> The non-.Net COM DLLs seem to be doing alright with the SelfRegCost
> attribute applied, but now the .Net DLLs are having trouble. I've
tried
> various ways to get them working.
>
> What I'm currently looking at is the RegisterClassInfo/ProgID/TypeLib
> actions. I opened the MSI up in ORCA, and realized that they are not
in my
> InstallExecuteSequence table. That makes sense why it wasn't working
with
> Class/Progid etc elements in the components. The action was never
getting
> called that dealt with those things. I assumed those actions would be
> included, and that I didn't to explicitly add them. I'm going to give
it a
> try with the "correct" methodology again, this time with the correct
actions
> in the sequence and see if that does the trick. If so, I can get rid
of the
> self registration stuff, AND the duct tape batch file full of regasm
calls.
>
> Conveniently, re-ghosting the test box and building the installer take
> about the same amount of time.. >sigh<
>
> This application is a beast, and the installer has to tame it. What a
> project At least I have a nice view of downtown Portland at night
from
> the 11th floor of this building.
>
> Thanks,
> Troy
>
>
>
> On Tue, Sep 30, 2008 at 8:10 PM, Richard <[EMAIL PROTECTED]>
wrote:
>
>>
>> In article
<[EMAIL PROTECTED]>,
>>"Troy Howard" <[EMAIL PROTECTED]>  writes:
>>
>> > So, in my efforts to resolve the .Net COM issues, [...]
>>
>> Earlier, this thread was talking about registering a VB6 control.
>>
>> Now you're talking about registering a .NET assembly for COM interop.
>>
>> So which is it?
>>
>> I've registered .NET assemblies for COM interop with no problems by
>> taking the output of /regfile.
>> --
>> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
>>

>> >
>>
>>Legalize Adulthood! 
>>
>>

-
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
--

Re: [WiX-users] COM registration weirdness

[Rob Mensching]

Note, those actions are only necessary if you are using the Advertised features 
of COM registration otherwise it's all just Registry rows.

Also, I personally don't recommend advertising COM goo 
(http://robmensching.com/blog/archive/2007/03/12/RobMens-Recommendation-Do-not-advertise-COM-information-in-MSI.aspx)
 and I don't *think* heat generates advertised by default.

-Original Message-
From: Richard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 08:18
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness


In article <[EMAIL PROTECTED]>,
"Troy Howard" <[EMAIL PROTECTED]>  writes:

> [...] The default sequence doesn't
> include the com registration actions that read the class table/etc.

IMO, that seems like a bug in WiX.  IIRC, the recommended default
install sequence *does* include all the registration related actions.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Richard]

In article <[EMAIL PROTECTED]>,
"Troy Howard" <[EMAIL PROTECTED]>  writes:

> [...] The default sequence doesn't
> include the com registration actions that read the class table/etc.

IMO, that seems like a bug in WiX.  IIRC, the recommended default
install sequence *does* include all the registration related actions.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Richard]

In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> All regsvr32 does is call DllRegisterServer on the DLL, what happens in =
> here is voodoo! It is perfectly legal to d anything you want in this =
> call and is the reason why self registration is frowned upon.

Actually, no, its not perfectly legal to do anything you want in
DllRegisterServer.  You are *only* supposed to do COM registration
there.

Yeah, if you put other code in there, it will run.  But that is not
"legal" in terms of how you are supposed to implement this entry point
into the DLL.

> I know a =
> VB6 DLL is just doing standard COM stuff but it is way more complicated =
> that any COM I have ever done in C++ [...]

I'm guessing that means you've never done dispinterfaces in C++ or
used other attributes of COM that are used by VB6.  VB6 supports late
binding on its COM servers, so there is a lot of infrastructure there
to support dispinterfaces, Invoke, etc.

> of things to make binary compatibility work. There are also references =
> back to the VB runtime. I'm not saying it is not possible to make it =
> work by just writing registry entries but I have never got it to work, =
> hence setting self reg (which I assume just calls DllRegisterServer) =
> works for me.  =20

The way to gather all the registry entries is to use a registry
capture tool to capture all the changes made to the registry when
regsvr32 is run on the DLL.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] preprocessor and environment variables?

[Mark Modrall]

Sorry...  Should have included that to begin with - v2.0.5325.0

Thanks
Mark

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 6:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] preprocessor and environment variables?

What version of the WiX toolset are you using?

-Original Message-
From: Mark Modrall [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 14:38
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] preprocessor and environment variables?

Hi...

I recently ran into a number of problems trying to change wix project 
behavior based on environment variable settings.  A number of the things that 
sounded intuitive to me didn't work.

For example





didn't work because ifdef returns false for all environment variables always 
whether they are set or not.





works as long as $(env.A) is defined, but if it's not, Candle generates an 
exception.

Is there any way to test for environment variable existence before you try 
to use it in Wix?

Thanks
Mark

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge 
Build the coolest Linux based applications with Moblin SDK & win great prizes 
Grand prize is a trip for two to an Open Source event anywhere in the world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge 
Build the coolest Linux based applications with Moblin SDK & win great prizes 
Grand prize is a trip for two to an Open Source event anywhere in the world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Rob Mensching]

That's *one* of the reasons SelfReg is frowned upon.  

The other big problem with SelfReg is that the Windows Installer doesn't 
rollback SelfReg.

Another big problem with SelfReg is that they are more fragile than using the 
built in functionality in MSI.  MSXML3 [I think] used to have SelfReg and it 
accounted for a percentage point or two of installation failures for Office... 
that was lot of money wasted on SelfReg.

The only good thing about SelfReg is that it lets developers be lazy.


-Original Message-
From: Neil Sleightholm [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 03:14
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness

All regsvr32 does is call DllRegisterServer on the DLL, what happens in here is 
voodoo! It is perfectly legal to d anything you want in this call and is the 
reason why self registration is frowned upon. I know a VB6 DLL is just doing 
standard COM stuff but it is way more complicated that any COM I have ever done 
in C++, for example, it supports all sorts of things to make binary 
compatibility work. There are also references back to the VB runtime. I'm not 
saying it is not possible to make it work by just writing registry entries but 
I have never got it to work, hence setting self reg (which I assume just calls 
DllRegisterServer) works for me.

Neil

Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED] 




From: Richard [mailto:[EMAIL PROTECTED]
Sent: Wed 01/10/2008 04:08
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness




In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> >> By the time it's a COM object, VB6 or C++ it doesn't make any
> >> difference.
>
> That is a nice theory [...]

Its not a theory.  An OCX from VB6 is just a DLL with a well defined entry 
point for registering the COM object.  That's *all* that
regsrv32 does when you run it!

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

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge 
Build the coolest Linux based applications with Moblin SDK & win great prizes 
Grand prize is a trip for two to an Open Source event anywhere in the world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Moving from InstallShield 12 to wix

[Rob Mensching]

Sorry, caught the end of this thread.

1.  You need to maintain Component/@Guids according to the Component Rules.  It 
doesn't matter what tool you use to create the MSI.  Once you ship, you must 
maintain the GUIDs appropriately.

2.  ProductCodes and UpgradeCodes need to be updated following the Windows 
Installer rules for upgrades.  Major upgrade?  Change the ProductCode... etc.

3.  Dark.exe can help get all of your authoring and it will preserve all the 
GUIDs for you.  Technically speaking, you should be able to switch at any time 
and rebuild a functionally identical MSI file (although it may be a little 
smaller since WiX tries very hard to only add the things you need).

-Original Message-
From: Michael Owings [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 18:01
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Moving from InstallShield 12 to wix

I'm currently in the process of moving from an InstallShield 12 (which I
loathe)  project over to wix. I'd ideally like to be able to update the
next version of this project via wix.

I'm wondering if I use the the same product and component IDs if I'd be
in good shape as far as an upgrading goes. Any gotchas I should be aware of?

Thanx in advance -- m
--
Teleoperate a roving mobile robot from the web:
http://www.swampgas.com/robotics/rover.html

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Delete temp files during uninstall

[Rob Mensching]

Or, better, write a C++ CustomAction that writes temporary rows in to the 
RemoveFile table and let the Windows Installer do the heavy lifting.  I may 
have to write this CustomAction for my team soon... if I do, I'll add it to 
WiX, like everyone else could.  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 23:59
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Delete temp files during uninstall

Hi Vivek,

You have at least these options:

1)Create a DTF custom action
2)Create a VB script custom action
3)Look into Quiet Execution Custom Action (ref Wix Help file)

and then put a condition like REMOVE="ALL" so it does not get run on
installs.

If these files and folders are not installed by the msi, you can not use
RemoveFolder or RemoveFile(s) according to the help file documentation.

Kind regards,

Hans


> I have a requirement to delete temporary files at
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
> Files. As the number of directories and files created by the application
> are
> close to 200 and RemoveFolder,RemoveFile with "*" is only
> on a directory and not recursive, makes it harder to do for every
> directory.
> Do we have any other solution?
> Can we run a dos command rmdir /s /q? If so how to do it in WiX?
>
> thanks,
> Vivek
>
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> 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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RE Moving from InstallShield 12 to wix

[Rob Mensching]

You should *not* change the Component GUIDs.  Component GUIDs must be stable 
from release to release.  ProductCodes need to be updated according to how you 
want your package to upgrade.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 20:56
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RE Moving from InstallShield 12 to wix

You should always change component and product codes when redoing the package.  
Your best bet would be to isntall the Windows Installer SDK which is part of 
the Windows SDK.  The documentation gives you several rules when you need to 
change the product codes.

I've used InstallShield upto version 9.0, some things drove me crazy about it.  
I though by 12 some things have gotton better.  I'd love to here what you think 
about the new version.

Regards,
greenaj

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Logging from a Custom Action during the UI phase

[Rob Mensching]

Yeah, Windows Installer doesn't let it work.  Why?  Some message processing 
issue inside them.  I think this is documented in some small print somewhere.

PS:  Please don't shoot the messenger.  

-Original Message-
From: John Hall [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 02:05
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Logging from a Custom Action during the UI phase

In my installer I have some C++ custom actions that log to the main MSI log 
file using MsiProcessMessage. I'm now writing a CA that is executed on a button 
press in the UI as the user leaves the feature selection dialog. However, none 
of my debug output is appearing in the log.

Is there a reason why this doesn't work?

Regards,
John
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Single installer instance question

[Rob Hamflett]

That's supposed to be taken care of by Windows Installer itself.  You can run 
as many as you like in 
the UI mode, but there's supopsed to be a guard so that only one instance can 
perform the 
server-side actions.  Are you seeing something different, or do you mean you 
want to only have one 
instance of your UI open?  If the latter, does knowing about the built-in guard 
mean this is no 
longer a concern for you?

Rob

kamal sharma wrote:
> Hi All,
>  
> I am newbie to Wix.
>  
> I wanted to know if there is any option by which I can allow only a single 
> instance of MSI to run.
> Right now, if I execute one instance of MSI and start the other one, then it 
> allows seamlessly to run both the msi installers. Ideally, only one should be 
> allowed.
>  
> Any pointers would help.
>  
> Regards,
> Kamal
> 
> 
>   
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Single installer instance question

[kamal sharma]

Hi All,
 
I am newbie to Wix.
 
I wanted to know if there is any option by which I can allow only a single 
instance of MSI to run.
Right now, if I execute one instance of MSI and start the other one, then it 
allows seamlessly to run both the msi installers. Ideally, only one should be 
allowed.
 
Any pointers would help.
 
Regards,
Kamal


  

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Neil Sleightholm]

All regsvr32 does is call DllRegisterServer on the DLL, what happens in here is 
voodoo! It is perfectly legal to d anything you want in this call and is the 
reason why self registration is frowned upon. I know a VB6 DLL is just doing 
standard COM stuff but it is way more complicated that any COM I have ever done 
in C++, for example, it supports all sorts of things to make binary 
compatibility work. There are also references back to the VB runtime. I'm not 
saying it is not possible to make it work by just writing registry entries but 
I have never got it to work, hence setting self reg (which I assume just calls 
DllRegisterServer) works for me.   
 
Neil
 
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]  
 



From: Richard [mailto:[EMAIL PROTECTED]
Sent: Wed 01/10/2008 04:08
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness




In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> >> By the time it's a COM object, VB6 or C++ it doesn't make any
> >> difference.
>
> That is a nice theory [...]

Its not a theory.  An OCX from VB6 is just a DLL with a well defined
entry point for registering the COM object.  That's *all* that
regsrv32 does when you run it!

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

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Logging from a Custom Action during the UI phase

[John Hall]

In my installer I have some C++ custom actions that log to the main MSI log 
file using MsiProcessMessage. I'm now writing a CA that is executed on a button 
press in the UI as the user leaves the feature selection dialog. However, none 
of my debug output is appearing in the log.

Is there a reason why this doesn't work?

Regards,
John
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Delete temp files during uninstall

[post]

Hi Vivek,

You have at least these options:

1)Create a DTF custom action
2)Create a VB script custom action
3)Look into Quiet Execution Custom Action (ref Wix Help file)

and then put a condition like REMOVE="ALL" so it does not get run on
installs.

If these files and folders are not installed by the msi, you can not use
RemoveFolder or RemoveFile(s) according to the help file documentation.

Kind regards,

Hans


> I have a requirement to delete temporary files at
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
> Files. As the number of directories and files created by the application
> are
> close to 200 and RemoveFolder,RemoveFile with "*" is only
> on a directory and not recursive, makes it harder to do for every
> directory.
> Do we have any other solution?
> Can we run a dos command rmdir /s /q? If so how to do it in WiX?
>
> thanks,
> Vivek
>
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> 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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users