[WiX-users] Condition for detecting minor upgrade

[Johan Appelgren]

Hi,

I'm attempting to create a customized UI sequence that when upgrading
or patching only displays a dialog that tells the user that the
application will be upgraded and what version it will upgraded to. For
major upgrades this isn't a problem, but I'm having trouble figuring
out how to detect minor upgrades in the conditions for the dialogs,
done with REINSTALL=ALL REINSTALLMODE=vomus.

Has anyone done anything like this? Or is there support for something
like this built-in to the UIExtension that I have missed?


/Johan Appelgren

--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to create compressed output

[Johan Appelgren]

On Wed, Aug 20, 2008 at 12:37 PM, Devarajan, Mahesh IN BLR SISL
<[EMAIL PROTECTED]> wrote:
> I have tried it , still give the same behaviour..by the way I use
> WiXAware to create and compile wix source files.
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Johan
> Appelgren
> Sent: Wednesday, August 20, 2008 3:53 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to create compressed output
>
> On Wed, Aug 20, 2008 at 11:45 AM, Devarajan, Mahesh IN BLR SISL
> <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I am new to WiX and we need to deliver our software as in form of
> single
>> .msi file and all other media types, program files should be
> compressed
>> in to .cab files that are separate from the .msi file.
>>
>> We use the following code
>>
>> > />
>>
>> But the output is not creating the .cab file instead all the files are
>> uncompressed.
>>
>> Is my requirement is feasible with WiX or do I have to do some extra
>> step to achieve this?
>>
>> I am using 2.0.5805.0 version of WiX
>
> Since you've set the EmbedCab attribute to yes the cab will be
> embedded in the msi. Set it to no to get a separate cab file.

Have you set the DiskId attribute on your Component or File elements?

Maybe you'll get better answers if you ask WiXAware support.

/Johan

-
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] How to create compressed output

[Johan Appelgren]

On Wed, Aug 20, 2008 at 11:45 AM, Devarajan, Mahesh IN BLR SISL
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am new to WiX and we need to deliver our software as in form of single
> .msi file and all other media types, program files should be compressed
> in to .cab files that are separate from the .msi file.
>
> We use the following code
>
>  />
>
> But the output is not creating the .cab file instead all the files are
> uncompressed.
>
> Is my requirement is feasible with WiX or do I have to do some extra
> step to achieve this?
>
> I am using 2.0.5805.0 version of WiX

Since you've set the EmbedCab attribute to yes the cab will be
embedded in the msi. Set it to no to get a separate cab file.

/Johan

-
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] Running MSI as SYSTEM and no ARP and other weirdnesses?

[Johan Appelgren]

On Wed, Aug 13, 2008 at 1:47 PM, Stefan Kuhr <[EMAIL PROTECTED]> wrote:
>
> Hi Johan,
>
>
>
> Johan Appelgren wrote:
>>
>> Are you doing a per-user or a per-machine install?
>>
>>
>
> Oops, please excuse my ignorance, but how do I know that? The command line
> is the same as I would install as an interactive user, something like:
>
> msiexec.exe /i path-to-my.msi  /qn /l*v path-to-logfile
>
> I use the exact same command line as I would when logging in interactively,
> but now just running as SYSTEM. The real purpose of all this is to remotely
> install an MSI and the msiexec command line is executed as a scheduled task
> running as SYSTEM. However I experienced the same behaviour when starting
> this MSI from an interactive command shell run as SYSTEm with the cmdasuser
> tool.

That is determined by the ALLUSERS property. If it is not set you get
a per-user installation, so I'm guessing that is what you have.

http://msdn.microsoft.com/en-us/library/aa367559(VS.85).aspx

For a per-user installation the install is only visible to the user
who installed your package. Everything the installer does must be
unique for the installing user. That means that you should only write
to the HKCU registry hive and write files in a unique location for
that user, easiest solution is to only write files somewhere in
%userprofile%. If you write files in, for example, %ProgramFiles% and
multiple users on the same machine installs the package things can
easily break when one user uninstalls the package or installs an
upgrade.

I think it's a lot simpler to have my installers always do a
per-machine install.

/Johan

-
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] Running MSI as SYSTEM and no ARP and other weirdnesses?

[Johan Appelgren]

On Wed, Aug 13, 2008 at 9:08 AM, Stefan Kuhr <[EMAIL PROTECTED]> wrote:
>
> Hello everyone,
>
> I have an MSI built with WiX. If I install this using msiexec from the
> SYSTEM account, the product gets installed (files and registry keys are
> there) but it is not visible in ARP. Also if I run this MSI then again from
> an interactive user, I do not get the option to repair or remove it but
> instead the UI behaves as if the product had not been previously installed.
> Can someone explain to me what's happening there? I'd rather have an entry
> in ARP as if it was installed by an ordinary user.

Are you doing a per-user or a per-machine install?

/Johan

-
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] InstallDir is lost on minor upgrade

[Johan Appelgren]

On Tue, Jul 1, 2008 at 11:29 AM, Frédéric Viollet
<[EMAIL PROTECTED]> wrote:
> Johan Appelgren a écrit :
>> On Tue, Jul 1, 2008 at 10:07 AM, Frédéric Viollet
>> <[EMAIL PROTECTED]> wrote:
>>
>>> Hi everyone,
>>>
>>> I've got a real big problem here on applying minor upgrades to my
>>> product. I really need your help here :)
>>> During the first install, I ask the user where the product should be
>>> installed (by using the wix standard Gui)
>>> But on minor upgrades, I do not ask him again. I just re-install the
>>> files to the previously selected location (well, that's what I'd like to do)
>>> I seem to have some problems with the property that points to my
>>> installation directory.
>>> Here's an extraction of the code I'm using:
>>>
>>> 
>>>  
>>>
>>>  
>>>
>>>  
>>>>> Key="Software\MyCompany\MyProduct\MySuite\MyModule">
>>>  >> Value="[SUITEINSTALLDIR]MyModule" Type="string" Action="write" />
>>>
>>>. Install a bunch of files 
>>>  
>>>
>>>  
>>>
>>>  
>>> 
>>> 
>>> 
>>> 
>>>
>>> Now, let's say that the default ProgramFilesFolder is C:\Program Files\
>>> On the first installation, the installdir is ask for. I enter F:\Program
>>> Files\MyCompany\MyProduct\MySuite *(and not C:)*. Everything works well :
>>> -the files are installed in F:\Program Files\MyCompany\MyProduct\MySuite
>>> -the registry value "InstallDir" is set to F:\Program
>>> Files\MyCompany\MyProduct\MySuite\MyModule
>>>
>>> On a minor upgrade, no installation dir is ask for (this is ok), and the
>>> new files are correctly copied to F:\Program
>>> Files\MyCompany\MyProduct\MySuite, but :
>>> -the registry value "InstallDir" is set to *C::\Program
>>> Files\MyCompany\MyProduct\MySuite\MyModule*
>>>
>>> Any idea of how I could fix this?
>>>
>>> Thanks a lot for your patience for reading all way down here :)
>>>
>>> Fred
>>>
>>
>> I think you must set the SUITEINSTALLDIR property using a RegistrySearch.
>> http://wix.sourceforge.net/manual-wix2/wix_xsd_registrysearch.htm
>>
> Ok. I will try this.
> The code should look like this then I guess:
>
> |
>   Key="|Software\MyCompany\MyProduct\MySuite\MyModule|" Name="InstallDir" />
> 
> 
>   snip 
> 
> 
>   snip 
> 
> 
> 
> |
>
> But, will this work on first install (the registry key will not be
> found)? Will the SUITEINSTALLDIR Property have a default value?

Yes, in that case the registry search will not set the property.
SUITEINSTALLDIR will then be set as before based on the Directory
structure.

>> Why is the InstallDir registry value the KeyPath for all your files?
>> Normally you have one component per .exe, .dll, .ocx and so on with
>> the file as KeyPath.
>>
> My fault. The extracted code was incomplete. There was a missing
>  after the Registry entries :)

Okey. :)

/Johan

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

Re: [WiX-users] InstallDir is lost on minor upgrade

[Johan Appelgren]

On Tue, Jul 1, 2008 at 10:07 AM, Frédéric Viollet
<[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> I've got a real big problem here on applying minor upgrades to my
> product. I really need your help here :)
> During the first install, I ask the user where the product should be
> installed (by using the wix standard Gui)
> But on minor upgrades, I do not ask him again. I just re-install the
> files to the previously selected location (well, that's what I'd like to do)
> I seem to have some problems with the property that points to my
> installation directory.
> Here's an extraction of the code I'm using:
>
> 
>  
>
>  
>
>  
> Key="Software\MyCompany\MyProduct\MySuite\MyModule">
>   Value="[SUITEINSTALLDIR]MyModule" Type="string" Action="write" />
>
>. Install a bunch of files 
>  
>
>  
>
>  
> 
> 
> 
> 
>
> Now, let's say that the default ProgramFilesFolder is C:\Program Files\
> On the first installation, the installdir is ask for. I enter F:\Program
> Files\MyCompany\MyProduct\MySuite *(and not C:)*. Everything works well :
> -the files are installed in F:\Program Files\MyCompany\MyProduct\MySuite
> -the registry value "InstallDir" is set to F:\Program
> Files\MyCompany\MyProduct\MySuite\MyModule
>
> On a minor upgrade, no installation dir is ask for (this is ok), and the
> new files are correctly copied to F:\Program
> Files\MyCompany\MyProduct\MySuite, but :
> -the registry value "InstallDir" is set to *C::\Program
> Files\MyCompany\MyProduct\MySuite\MyModule*
>
> Any idea of how I could fix this?
>
> Thanks a lot for your patience for reading all way down here :)
>
> Fred

I think you must set the SUITEINSTALLDIR property using a RegistrySearch.
http://wix.sourceforge.net/manual-wix2/wix_xsd_registrysearch.htm

Why is the InstallDir registry value the KeyPath for all your files?
Normally you have one component per .exe, .dll, .ocx and so on with
the file as KeyPath.

/Johan

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

Re: [WiX-users] How to set the Guid property of component element during upgrade

[Johan Appelgren]

On Thu, Jun 19, 2008 at 4:27 PM, Shiliang Li <[EMAIL PROTECTED]> wrote:
> Hi, all,
>
>I am a newbie to Wix. Can you please provide some information 
> about how to set the Guid property of component element when doing a 
> major/minor upgrade? Is there any rules?

You can read about windows installer components here:
http://msdn.microsoft.com/en-us/library/aa372830(VS.85).aspx

/Johan

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

Re: [WiX-users] Installing an EventSource for a .NET application

[Johan Appelgren]

On Tue, Jun 24, 2008 at 4:08 PM, Wouter Demuynck
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> For a .NET application I would like to create an event log source in
> the setup process. Until moving to WiX, this was done via an
> InstallUtil-type Installer class, but, for obvious reasons, I'm moving
> away from this now. I have been looking at various sources of
> documentation and what I've found is this:
>
>
> EventMessageFile='C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll'
>   SupportsErrors='yes'
>   SupportsWarnings='yes'
>   SupportsInformationals='yes'
>   />
>
> Now, as for the EventMessageFile, this should be the .NET
> EventLogMessages.dll for the target framework version, but I would
> rather not hard code the full path to this file. Does anyone have any
> suggestions on how this could be done best? I'm thinking of a registry
> search for InstallRoot in HKLM\Software\Microsoft\.NETFramework and
> then somehow append the version number, but perhaps anyone has a
> better way?
>
> Also, this may have been asked before, but the NetFxExtension exposes
> various properties of the .NET Framework, including the SDK directory,
> but it does not provide a property for the runtime directory
> (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727). Is this omitted for
> any specific reason or is it planned for a future version?

I don't think it's possible to change the install location for .NET
Framework so this should work.



/Johan

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

Re: [WiX-users] Windows Service is not started/Custom Actions Fail in vista

[Johan Appelgren]

Does your service depend on MSVC DLLs that you are installing, or just
the custom action exe that starts the service?

If your service does not depend on anything installed in the GAC or
winsxs you could just the ServiceControl table instead. Otherwise
static linking to the dlls will work, or schedule the custom action
after InstallFinalize.

http://msdn2.microsoft.com/en-us/library/aa371634(VS.85).aspx

I doubt UAC has anything to do with this.

/Johan

On Feb 6, 2008 12:57 PM, Sneha Gharpure <[EMAIL PROTECTED]> wrote:
>
> Thanks for the reply.
>
> The problem is that the exe that starts the service is running as a custom
> action. This exe depends on MSVC DLLs. During installation, this custom
> action is failing. I believe that this is because the DLLs are not available
> till InstallFinalize and the custom action is scheduled before
> InstallFinalize. So is there any way by which these DLLs can be made
> available to the exe? will static linking of these DLLs with the exe work?
>
> How do you disable UAC from User accounts? Also, whats are the general
> things that we need to take care of so that the installation works fine on
> vista? We are taking care of the "Impersonate=no and execute=deferred " in
> custom actions and we are running the MSI as an administrator.
>
> Thanks,
> Sneha
>
>
> Anidil wrote:
> >
> > This is a problem with UAC on Windows Vista.Disable UAC from User
> > accounts,restart the system and try starting the service..
> >
> >
> >
> > Sneha Gharpure wrote:
> >>
> >> Hi,
> >>
> >> The problem is that service is not starting on Vista. The service is
> >> being started through one of the custom actions which is an exe custom
> >> action. The exe depends on some MSVC DLLs which are also deployed along
> >> with the package.
> >>
> >> Is the issue with these DLLs? Does these DLLs are not available when the
> >> exe is trying to start the service? or the problem is with the
> >> permissions?
> >>
> >> Can anyone clarify?
> >>
> >> Thanks in Advance,
> >> Sneha
> >>
> >
> >
>
> --
> View this message in context: 
> http://www.nabble.com/Windows-Service-is-not-started-Custom-Actions-Fail-in-vista-tp15285631p15306500.html
>
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Possible dependency failure (ICE25)

[Johan Appelgren]

Hi,

I'm using a number of merge modules for a project and when building I
get an ICE warning that I'm missing a dependency.

An improvement to Wix that would be helpful in a situation like this
would be if the warning contained information about which merge module
it is that requires the missing merge modules.

I'm currently using Wix 3.0.3509.0.

/Johan

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] unexpected SqlDatabase element

[Johan Appelgren]

On Jan 30, 2008 8:46 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
>
> When I use WIX 3.0.2512.0 to compile, I get error on this line:
>
>Guid='65721384-ACFB-11DC-8E65-758256D89593' DiskId='1' Location='either'
> Permanent="yes">
>
> 
>
>  Server='[SQLSERVER]' CreateOnInstall='yes'>
>
>
>
> The error is:
>
> c:\map\private\map\installers\sql\handsetmgrdata\handsetmgrdbsetup.wxs(92) :
> error CNDL0005 : The Component element contains an unexpected child element
> 'SqlDatabase'.
>
>
>
> But according to public\ext\wix\3.0.2512.0\doc\WiX.chm, Component can be
> parent of SqlDatabase.
>
>
>
> Why do I encounter this error ?

I think it is because you haven't specified the correct namespace for
the SqlDatabase element. The namespace is
http://schemas.microsoft.com/wix/SqlExtension according to the wix
docs.

/Johan

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Convert installer to ClickOnce

[Johan Appelgren]

On Jan 30, 2008 6:41 PM, hina1703 <[EMAIL PROTECTED]> wrote:
>
> I have created a installer using Wix toolset. How can I convert it to
> ClickOnce deployment?
>
> Thanks,
>

ClickOnce and Windows Installer are two different installer
technologies. You can read a comparison between the two here
.

I don't think there is any way to automatically convert between the two.

/Johan

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom actions working fine in xp - failing in Vista

[Johan Appelgren]

On Jan 23, 2008 2:20 PM, SaiTeja <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have created a WIX installer that works perfectly on XP.
>
> But When I try in Vista Business, my custom actions are failing
>
> Below is the custom action
>
>  ExeCommand="UninstallLogonHandler" FileKey="xyz.exe">
> 
>
> 
> Not
> Installed
> 
>
>
> I tried with Impersonate="yes" and Impersonate="no". Still it is failing
>
> Any ideas of what might be this issue would be greatly appreciated.
>
>
> I want my installer should work on xp,vista,windows server2003 per machine.
>
>
> please suggest solution for general cases like admin check, registry, COM
> objects etc also.

What does a log of a failed install say? msiexec /i your.msi /lv* install.log

What does xyz.exe do?

/Johan

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] License in wix-3.0.2925.0-sources.zip ?

[Johan Appelgren]

On Nov 15, 2007 5:15 PM, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Johan Appelgren wrote:
> > I just downloaded the latest source drop of wix 3,
> > wix-3.0.2925.0-sources.zip, and noticed that the CPL license
> > information in the header of all files has been removed since
> > wix-3.0.2420.0-sources.zip. Has the license for Wix 3 changed? I
> > couldn't find any signs of this change in the CVS repository.
> >
>
> No license change. In v3.0.3429.0, files have the CPL blurb, at least
> from a spot-check.

Okey. The source in wix-3.0.2925.0-sources.zip fails to build as well
so I guess something went wrong when the zip was created.

/Johan

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] License in wix-3.0.2925.0-sources.zip ?

[Johan Appelgren]

Hi,

I just downloaded the latest source drop of wix 3,
wix-3.0.2925.0-sources.zip, and noticed that the CPL license
information in the header of all files has been removed since
wix-3.0.2420.0-sources.zip. Has the license for Wix 3 changed? I
couldn't find any signs of this change in the CVS repository.

//The use and distribution terms for this software are covered by the
//Common Public License 1.0 (http://opensource.org/licenses/cpl.php)
//which can be found in the file CPL.TXT at the root of this distribution.
//By using this software in any fashion, you are agreeing to be bound by
//the terms of this license.


/Johan

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Shortcut + hyperlink 2

[Johan Appelgren]

On 4/24/07, Scott Sam <[EMAIL PROTECTED]> wrote:
> This is what I do.  Basically make a shortcut to internet explorer  and
> pass the web address as the argument.  I do it this way so that it
> always opens another instance of ie when you use the shortcut instead of
> opening it the current window.  This was a big problem with ie6.

Isn't it better to let the user decide by changing the option for this
in Internet Explorer? If that is the browser he is using.

I think the advanced Options called "Reuse windows for launching
shortcuts" controls this.

/Johan

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using .NET 2.0 Managed Custom Actions

[Johan Appelgren]

On 4/20/07, Mailinglist <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hello WiX-users,
>
>
>
> because we needed to use managed custom actions in our setup, I searched
> around the net for a real solution to this.
>
>
>
> I found two projects ([1],[2]),  that followed quite good ideas, but both
> did not work out of the box or only under special circumstances. So I
> combined them both to something working.
>
>
>
> Simply, we now use a custom action to start a C++ library, that hosts the
> CLR, loads a specified assembly and calls a class that needs to implement a
> small interface. From inside that class the installer context can be used to
> fill properties, etc.
>
>
>
> Since the demo code package is 3 MB, I uploaded it to Rapidshare [3] as well
> as to my blog [4].
>
>
>
> Greetings,
>
>
>
> Oliver Friedrich
>
> Consultant - Software Solutions
>
>
>
>
>
> [1] "Hosting the CLR within a custom action" – Pablo M. Cibaro -
> http://weblogs.asp.net/cibrax/archive/2005/04/11/399839.aspx
>
> [2] "Wrapping the Windows Installer 2.0 API" -
> http://www.codeproject.com/csharp/msiinterop.asp
>
> [3] Rapidshare Download Link:
> http://rapidshare.com/files/26953203/ManagedCustomActions.zip.html
>
> [4] Blogentry: http://www.forestwalk.de/?p=31
>

How does this work around the technical reason for managed custom
actions not working that Rob Mensching blogged about recently?

http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx

/Johan

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Default REINSTALLMODE for repair

[Johan Appelgren]

On 2/21/07, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Johan Appelgren wrote:
> >[candle] src\ext\uiextension\wixlib\FatalError.wxs(24) : error
> > CNDL0008 : The Control/@X attribute's value,
> > '!(wix.WixUIDialogBitmapWidth)', is not a legal integer value.  Legal
> > integer values are from -2,147,483,648 to 2,147,483,647.
> >
>
> Can you enter this as a bug? I need to dig into the code to see why it
> shouldn't be allowed. Especially given that it's a localizable column, I
> believe a bind-time variable should be supported.

Okey.

http://sourceforge.net/tracker/index.php?func=detail&aid=1664906&group_id=105970&atid=642714

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Default REINSTALLMODE for repair

[Johan Appelgren]

On 2/20/07, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Johan Appelgren wrote:
> > I don't think WixVariables works for what I'm trying to do. If I try
> > to use a wix variable candle fails with an error that states that only
> > integers are valid values for the Control/@Width attribute. Could I be
> > doing this the wrong way somehow?
> >
>
> Could you show your syntax? If loc variables work, I'd expect bind-time
> variables to work too. BTW, I'm talking about  in WiX v3.
> I'd expect preprocessor variables to work too; if they don't, it's
> probably a bug.

What I did to try using a WixVariable was adding the following to the
fragment in Common.wxs as default values for the variables.




And then in the dialogs that have a sidebar bitmap I changed the
Control/@X and Control/@Width attributes. For example the Title in
FatalError.wxs.



I'm probably doing this wrong since it doesn't work.

   [candle] src\ext\uiextension\wixlib\FatalError.wxs(24) : error
CNDL0008 : The Control/@X attribute's value,
'!(wix.WixUIDialogBitmapWidth)', is not a legal integer value.  Legal
integer values are from -2,147,483,648 to 2,147,483,647.
   [candle] src\ext\uiextension\wixlib\FatalError.wxs(24) : error
CNDL0008 : The Control/@Width attribute's value,
'!(wix.WixUIDialogTextWidth)', is not a legal integer value.  Legal
integer values are from -2,147,483,648 to 2,147,483,647.
   [candle] src\ext\uiextension\wixlib\FatalError.wxs(24) : error
CNDL0010 : The Control/@Width attribute was not found; it is required.
   [candle] src\ext\uiextension\wixlib\FatalError.wxs(24) : error
CNDL0010 : The Control/@X attribute was not found; it is required.

/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Default REINSTALLMODE for repair

[Johan Appelgren]

On 2/9/07, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Johan Appelgren wrote:
> > Anyways, we're already using a custom WixUIExtension, abused
> > localization to make the sidebar bitmap width configurable, so I've
> > made ReinstallMode configurable the same way.
> >
>
> You could also do it with WixVariables -- see WixUI_Advanced for how
> we're doing some stuff like that.

I don't think WixVariables works for what I'm trying to do. If I try
to use a wix variable candle fails with an error that states that only
integers are valid values for the Control/@Width attribute. Could I be
doing this the wrong way somehow?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows Forms App

[Johan Appelgren]

On 2/14/07, Dhaval Patel <[EMAIL PROTECTED]> wrote:
> I don't know if this issue is WIX related, or something completely random. I
> had developed an app that was deployed using "Xcopy" via a batch file.
> Recently my PM decided to port it to WIX because of my newly gained "WIX
> powers." Anyway, this app has a bunch of .dll files and a Windows Forms app
> that references a couple of these .dll files. There are no problems  with
> the installer and everything installs just fine. But as soon as I try and
> launch the .exe file (the Windows Form), it crashes. The Windows Forms app
> has no problems, whatsoever, if deployed via Xcopy. I am not sure if how I
> have laid out my "Components" (the "Name" attribute for backward
> compatiblity, etc.) in the WIX file is screwing up somehow...
>
> This is a .NET 2.0 app being deployed on W2K3 server. I haven't tried
> installing it on XP.
>
> Thanks in advance, folks!

How does the application crash? The exception should give you some
clues to track down the problem. Although since it works when you copy
the files a possible cause could be that one or more of the files are
missing or were installed in the wrong location.

/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Default REINSTALLMODE for repair

[Johan Appelgren]

On 2/7/07, Johan Appelgren <[EMAIL PROTECTED]> wrote:
> On 2/7/07, Bob Arnson <[EMAIL PROTECTED]> wrote:
> > Johan Appelgren wrote:
> > > A possible cause for this is that the ReinstallMode is set to 'ecmus'
> > > VerifyReadyDlg. If I interpret the documentation correctly 'e' means
> > > to always repair files. So even if the file isn't missing or broken it
> > > is repaired.
> > >
> > > Shouldn't 'ocmus' be enough? 'o' to repair if the existing file has an
> > > older version, and 'c' to repair if the checksum does not match? Or
> > > does this have some negative consequences? The default is after just
> > > 'omus'.
> > >
> >
> > Both are valid, of course -- sometimes a "thorough" repair is more
> > useful for fixing problems. But it does have a consequence for shared
> > components, as you discover. It's fair to change REINSTALLMODE to avoid
> > that issue.
> >
> > --
> > sig://boB
> > http://bobs.org
> >
>
> Is REINSTALLMODE configurable when using UIExtension? Can't find any
> traces of that in the sources at least.
>

Anyways, we're already using a custom WixUIExtension, abused
localization to make the sidebar bitmap width configurable, so I've
made ReinstallMode configurable the same way.

/Johan

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Repair on install upgraded from url fails

[Johan Appelgren]

Hi,

I'm having an issue with repairing an install after a minor upgrade if
both the original installation and the upgrade was done from urls.

For example.

Original install was done from http://someurl/v10/product.msi by
executing msiexec /i http://someurl/v10/product.msi
Minor upgrade was done from http://someurl/v11/product.msi by executing
msiexec /i http://someurl/v11/product.msi REINSTALL=ALL REINSTALLMODE=vomus

If I then try to repair the upgraded installation it fails. First I
get a dialog that asks me to enter the path to the v11 msi. The log
says that windows installer downloaded http://someurl/v10/product.msi
but since the package code was incorrect I was presented with the
dialog. If I then enter the correct url http://someurl/v11/product.msi
it still fails.

After the upgrade it looks like the SourceList (in the registry) for
the product isn't correctly updated. It still contains the url to the
initial installation. Could I somehow be using wix wrong so that my
package is broken which causes this behavior? Or is this a problem in
wix or windows installer?

I'm using wix 3.0.2420.0.

/Johan

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Default REINSTALLMODE for repair

[Johan Appelgren]

On 2/7/07, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Johan Appelgren wrote:
> > A possible cause for this is that the ReinstallMode is set to 'ecmus'
> > VerifyReadyDlg. If I interpret the documentation correctly 'e' means
> > to always repair files. So even if the file isn't missing or broken it
> > is repaired.
> >
> > Shouldn't 'ocmus' be enough? 'o' to repair if the existing file has an
> > older version, and 'c' to repair if the checksum does not match? Or
> > does this have some negative consequences? The default is after just
> > 'omus'.
> >
>
> Both are valid, of course -- sometimes a "thorough" repair is more
> useful for fixing problems. But it does have a consequence for shared
> components, as you discover. It's fair to change REINSTALLMODE to avoid
> that issue.
>
> --
> sig://boB
> http://bobs.org
>

Is REINSTALLMODE configurable when using UIExtension? Can't find any
traces of that in the sources at least.

/Johan

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Default REINSTALLMODE for repair

[Johan Appelgren]

Hi,

I've run into a minor issue when repairing an install built with wix
3.0.2420.0.

I'm using Microsoft_VC80_CRT_x86.msm and if I repair
C:\WINDOWS\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcr80.dll
is reported as in use.  This causes a reboot prompt at the end of the
repair, ReplacedInUseFiles is set.

It is reported as in use by mscorsvw, msiexec and rundll32.

A possible cause for this is that the ReinstallMode is set to 'ecmus'
VerifyReadyDlg. If I interpret the documentation correctly 'e' means
to always repair files. So even if the file isn't missing or broken it
is repaired.

Shouldn't 'ocmus' be enough? 'o' to repair if the existing file has an
older version, and 'c' to repair if the checksum does not match? Or
does this have some negative consequences? The default is after just
'omus'.


/Johan

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX3 Error: The primary key xxx is duplicated in table 'Registry'

[Johan Appelgren]

On 1/29/07, Neil Sleightholm <[EMAIL PROTECTED]> wrote:
>
> I wonder if anyone could give me some pointers on what the following error
> means:
>
> "The primary key 'regCEE002B6E272C08B0F4B8191A9027490' is
> duplicated in table 'Registry'.  Please remove one of the entries or rename
> a part of the primary key to avoid the collision."
>
>
>
> I think this is generated by the following fragment but it is part of a very
> large file with lot of  keys:
>
>Guid="811B5C06-06A4-431D-B1E8-F2025806A91E">
>
>  Source="$(var.SourceDir)\.yy..dll">
>
>Context="InprocServer32" Description=".yy..SystemInfo"
> ThreadingModel="both">
>
>  Description=".yy..SystemInfo" />
>
>   
>
>Context="InprocServer32" Description=".yy..VideoView"
> ThreadingModel="both" Version="4.6">
>
>  Description=".yy..VideoView" />
>
>   
>
> 
>
>   
>

It means that wix has generated the same Id for two registry values,
which normally means that you have one or more duplicates of a
registry value in a component.

If you search through the wixobj files created by candle for
regCEE002B6E272C08B0F4B8191A9027490 you should find it in more than
one place. From those locations you should be able to figure out where
your duplicate registry values are coming from.

Btw, I compiled the fragment you supplied with Wix 3.0.2420.0 and did
not get any duplicated registry values from that alone.

/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] upgrade/install with one MSI

[Johan Appelgren]

On 1/25/07, Kaushik Barat <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Is it possible for an MSI to detect an earlier installation? What property
> should be checked for?
> Is it possible to only upgrade the changed files if an earlier MSI is
> detected?

Have you read the tutorial linked from ?
It should at least give you some ideas how upgrades work with Windows
Installer.



/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Minor upgrade fails when original install is from removable media

[Johan Appelgren]

On 1/25/07, Chris Allen <[EMAIL PROTECTED]> wrote:
>
> Johan Appelgren wrote:
> > I've created a setup package using Wix 3.0.2420.0 that I've used to
> > install our product on a computer from a CD (removable media). But
> > when I try to perform a minor upgrade it prompts me for a disk,
> > "Please insert disk".
> >
> > In the logs there is a PackageMediaPath property set to the directory
> > from where the original installation was done but without the drive,
> > and I think Windows Installer is trying to find the cabs in that
> > directory instead of looking in the directory where the upgrade msi is
> > located.
>
> Our experience with MSI upgrades on removable media is that both:
>
> 1. The media volume label must be the same as the original media.
>
> 2. The directory where the package lives must be the same as the
> original.  (Although setting "MEDIAPACKAGEPATH" may work.)
>
> MSI records this information when you first install the package into the
> registry locations noted here:
>
> http://support.microsoft.com/kb/299803/en-us
>
> In MSI 3.0 they finally added the "MsiSourceList...()" API functions
> that allow you to access this stuff.  (Of course, no good if you still
> need to support NT4 :( )
>
> Hope this helps.
> Regards,
> Chris

Thank you. This explains what I'm seeing perfectly.

/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Minor upgrade fails when original install is from removable media

[Johan Appelgren]

Hi,

I've created a setup package using Wix 3.0.2420.0 that I've used to
install our product on a computer from a CD (removable media). But
when I try to perform a minor upgrade it prompts me for a disk,
"Please insert disk".

In the logs there is a PackageMediaPath property set to the directory
from where the original installation was done but without the drive,
and I think Windows Installer is trying to find the cabs in that
directory instead of looking in the directory where the upgrade msi is
located.

If I install from a CD where both the original package and the minor
upgrade exist in different directories Windows Installer complains
that the PackageCode is invalid.

Has anyone encountered anything similar or know what's wrong? Maybe
it's not a Wix problem at all?

If the original install is not done from a CD the upgrade works just
fine, and the PackageMediaPath property is never set according to the
log.


/Johan Appelgren

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Shortcuts and ICE

[Johan Appelgren]

On 1/8/07, André Pönitz <[EMAIL PROTECTED]> wrote:
> Johan Appelgren wrote:
> > So the answer to the initial question is that windows installer is
> > broken, and I should just ignore the ICE57 error?
>
> I think 'yes, and not necessarily'. Have a look at hack I just
> posted in the 'Solution for StartMenuFolder < x < StartupFolder ?'
> thread today.

Okey, but wouldn't it work better if you use HKMU and ignore the ICE57
error for the registry value that is key path for the component that
contains the unadvertised shortcut? I can't figure out what issues I
might run into that the ICE57 error is there to help me avoid.

I need to support both per-user and per-machine installs.

/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Shortcuts and ICE

[Johan Appelgren]

So the answer to the initial question is that windows installer is
broken, and I should just ignore the ICE57 error?

I'm trying to use unadvertised shortcuts and haven't been able to find
out the recommended way to create them.

/Johan

On 1/4/07, Rob Mensching <[EMAIL PROTECTED]> wrote:
> 1.  The "All User" profile is a "per-machine" location. fact that there is no way to get settings removed from all users is (IMHO) a 
> fundamental architecture flaw in Windows (that affects the Windows 
> Installer).  All per-user scenarios just don't quite work perfectly.  
>  [mailto:[EMAIL PROTECTED] On Behalf Of Bart Kapitein January 04, 2007 07:41 [WiX-users] Shortcuts and ICE the ALLUSERS property can change. And I with a component which has a HKCU registry needed to pass ICE57) and an unadvertised installation is done, the shortcut is placed (is this location a per-user location?). The   key is placed in the HKCU of the person who is installing 
> the application? I deleted, which
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Better handling of invalid mergeLanguage

[Johan Appelgren]

Done.

http://sourceforge.net/tracker/index.php?func=detail&aid=1629314&group_id=105970&atid=642714

 /Johan

On 1/5/07, Rob Mensching <[EMAIL PROTECTED]> wrote:
> Yes, can you open a bug with just that. Message-mailto:[EMAIL PROTECTED] On Behalf 
> Of Johan Appelgren wix-users@lists.sourceforge.net invalid mergeLanguage ProcessMergeModules exceptions are handled for does not exist and some other cases and you if you've specified an invalid language COMException: installation package HRESULT: 0x80070657) caught and a WixException instead to make it easier is?http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEVhttps://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Better handling of invalid mergeLanguage

[Johan Appelgren]

Hi,

In src\wix\Binder.cs ProcessMergeModules exceptions are handled for
when the merge module file does not exist and some other cases and you
get great error messages. But if you've specified an invalid language
for the merge all you get is a COMException:

light.exe : error LGHT0001 : The language of this installation package
is not supported by your system. (Exception from HRESULT: 0x80070657)

Wouldn't it be good if the COMException was caught and a WixException
was thrown with source line number and file instead to make it easier
to figure out where the error is?

/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat produces invalid wxs

[Johan Appelgren]

Okey. I'll see if I can find the bug then and append to it. Thanks.

/Johan

On 1/4/07, Rob Mensching <[EMAIL PROTECTED]> wrote:
> It's a bug in heat.  There was a discussion about heat not quite getting all 
> the registry keys right earlier and I think a bug is opened on it (you could 
> add this information to that bug if it is missing).  Unfortunately, no one is 
> working on heat right now (since Derek left). Message-mailto:[EMAIL PROTECTED] On Behalf 
> Of Johan Appelgren wix-users@lists.sourceforge.net wxs xml. It looks like registry COM two instead of producing brokenhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEVhttps://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat produces invalid wxs

[Johan Appelgren]

Forgot to mention that I tested this using heat that comes with wix 3.0.2420.0

/Johan

On 1/4/07, Johan Appelgren <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I ran heat on a COM dll and it produced invalid wxs xml. It looks like
> it was because of a copy/paste error in a COM objects registry
> settings. The CurVer keys value was set to the progid of another COM
> objects progid. This caused heat to generate a class element with two
> progid children.
>
> Would it be possible for heat to error out instead of producing broken
> wxs output?
>
> /Johan
>

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Heat produces invalid wxs

[Johan Appelgren]

Hi,

I ran heat on a COM dll and it produced invalid wxs xml. It looks like
it was because of a copy/paste error in a COM objects registry
settings. The CurVer keys value was set to the progid of another COM
objects progid. This caused heat to generate a class element with two
progid children.

Would it be possible for heat to error out instead of producing broken
wxs output?

/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing COM components

[Johan Appelgren]

Thank you for your response.

In what way would automatic generation be more fragile? Isn't all the
information available for an automated approach? When it comes to
converting one format to another the computer is usually better than
me at getting it right.

/Johan

On 9/22/06, Mike Dimmick <[EMAIL PROTECTED]> wrote:
> If you're writing regular COM components in C++, you should manually
> edit the .wxs to maintain it. You know what is being created, you should
> replicate it. Reverse-engineering is fragile. Heat is intended for
> one-off use to generate an initial template .wxs file.
>
> You can use the Class table to take away some of the pain of creating
> the registry entries, although Rob Mensching has some reservations with
> this apparently. I'm not quite sure why. The SDK currently calls out the
> Typelib table as having problems with rollback. Using the Class table
> creates an _advertised_ class, which I believe will potentially run
> repair when instantiated if the component's dependencies are the wrong
> versions (it also allows an administrator to advertise the package; when
> the class is instantiated it will be installed if only advertised, not
> yet installed - install-on-first-use).
>
> If registering .NET assemblies for COM Interop, use regasm to generate a
> .reg file and convert that to .wxs code. I don't think the Class table
> can be made to register a .NET assembly properly. If strong-name signing
> the assembly, install it to the GAC with the Assembly='.net' parameter;
> if not strong-name signing, use the /codebase option to regasm and set
> the CodeBase registry value in your .wxs file to the path you installed
> the DLL to. (This isn't really supported by the .NET Framework team for
> deployment but it does work).
>
> The .NET Framework will generate GUIDs based on a hash of the assembly
> identity and class or interface name, but you can control the GUIDs used
> with a [Guid] attribute, and this is better for keeping binary
> compatibility for COM. It may be better to avoid auto-generated class
> interfaces and actually define your interfaces yourself, applying a
> [Guid] attribute - I can't see a way to control the GUID of an
> auto-generated class interface. Use the [ClassInterface] attribute to
> turn off the automatic generation of a class interface.
>
> Alternatively you can use the [ComCompatibleVersion] attribute at the
> assembly level to indicate that all the classes and interfaces in the
> assembly are compatible with those in an earlier version of the
> assembly. This causes the Framework to use that version number when
> computing the GUIDs and therefore the GUIDs are stable across versions.
>
> --
> Mike Dimmick
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Johan
> Appelgren
> Sent: 22 September 2006 13:03
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Installing COM components
>
> Hi,
>
> I'm looking at using wix to create an installer for an application that
> consists of both .NET assemblies and COM. As far as I can tell if I want
> to try wix3 I'm supposed to use heat to generate wxs files for the COM
> components and their primary interop assemblies.
>
> During the development there's probably going to be changes the the COM
> interfaces, mainly additions, how do I best capture those changes after
> the initial heat harvesting? Manually editing the wxs files seems very
> errorprone. Is there a better/recommended way to keep the wxs and COM
> interfaces in sync?
>
>
> /Johan
>
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT Join
> SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Installing COM components

[Johan Appelgren]

Hi,

I'm looking at using wix to create an installer for an application
that consists of both .NET assemblies and COM. As far as I can tell if
I want to try wix3 I'm supposed to use heat to generate wxs files for
the COM components and their primary interop assemblies.

During the development there's probably going to be changes the the
COM interfaces, mainly additions, how do I best capture those changes
after the initial heat harvesting? Manually editing the wxs files
seems very errorprone. Is there a better/recommended way to keep the
wxs and COM interfaces in sync?


/Johan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users