date:20131003

Re: [WiX-users] WiX disaster -- how did I cause it?

2013-10-03 Thread Nicolás Alvarez

2013/10/3 Nicolás Alvarez :
> 2013/9/30 Nicolás Alvarez :
>> The registry key should be in HKLM to avoid your
>> product-getting-repaired problem (I don't know why that causes a
>> reboot, but I think that's beside the point; this shouldn't need a
>> reboot-less repair either). So your real problem is now ICE38. I can't
>> figure out why it's saying the component installs to user profile. The
>> ProgramMenuFolder property should be getting set to the 'all users'
>> start menu if you have Package/@InstallScope="perMachine" (which you
>> do).
>>
>> But let's take a step back. Your StartMenuDir component only has two
>> things: the RemoveFolder, and the registry key. The shortcut directory
>> is not in that component, because directories don't "belong to
>> components" to begin with, they are created when needed (in this case
>> when creating the shortcut). Is it normal/correct to have the
>> RemoveFolder in a different component? Is there any reason why it
>> can't go to the main component with the .exe and the shortcut? If so,
>> you won't need the registry key at all.
>>
>> Perhaps ICE38 is getting confused and saying the component installs to
>> a user profile because it doesn't install anything at all :)
>
> OK, I'm now hitting a very similar problem myself...
>
> I made a simple installer with a single .exe, an advertised shortcut,
> and a RemoveFolder for the start menu folder where the shortcut is,
> all in the same component, which is what I suggested in my previous
> email. That worked just fine, with no need for a registry key... until
> I had to add a second executable and shortcut. The whole idea breaks
> down if I have multiple shortcuts. I can't put it in one of the
> components, because later I may want to put the two exe+shortcut
> components in different features, so any of the two components may not
> be installed.
>
> So I moved the RemoveFolder to a different component, inside the
> Directory matching the folder being removed. "ICE38: component
> installs to user profile, must have HKCU registry key as keypath." I'm
> pretty sure I can now say I feel your pain :)
>
> If the ALLUSERS property is set to 1, ProgramMenuFolder is set to the
> "all users" start menu, which is *not* in the user profile, and I
> think everything would be safe (I couldn't even override it by setting
> ALLUSERS=0 in the command line). Isn't ICE38 wrong in this case?

Time for some experiments.

Base setup: Single feature, two components each containing an .exe and
an advertised shortcut. The advertised shortcuts are in a subdirectory
of ProgramMenuFolder. There's a few more DLL components, not relevant
to this. The package has InstallScope="perMachine".

Here's a long list of things I tried.

1. No RemoveFolder at all. The folder is being created by the
installer on demand, when the shortcut is installed, so it should be
getting removed automatically on uninstall, when the folder goes
empty. And simple tests show it does work. However, this triggers
ICE64, saying the folder could be left orphaned in some obscure
roaming-profile scenario which I'm not sure I care about. Can I ignore
this ICE?

2. Put RemoveFolder in one of the components with exe+shortcut. Works,
no ICE errors. But it wouldn't work if it was possible the components
weren't installed (eg. if they were in different features). It also
doesn't feel clean, because it would be an arbitrary decision to
choose what component to put it in...

3. Put a RemoveFolder in each and every component with exe+shortcut.
Works, no ICE errors. Feels silly. Is it a good idea?

4. Create a new component with the RemoveFolder, inside the Directory
with the shortcut (ie. the directory being removed):

4a. Component with *only* the RemoveFolder, no registry key. Works in
simple testing. But gives "ICE38: Component FolderRemover installs to
user profile. It must use a registry key under HKCU as its KeyPath,
not a file."

4b. Like 4a, but with a RegistryValue in HKLM as keypath. Works in
simple testing. But, as mentioned many times in this thread, it gives
"ICE38: Component FolderRemover installs to user profile. It's[sic]
KeyPath registry key must fall under HKCU".

4c. Like 4a, but with a RegistryValue in HKCU as keypath. Works, no
ICE errors, but every user who launches the application for the first
time through an advertised shortcut would get a repair, because the
registry key wouldn't exist.

5. Component with only RemoveFolder, registry value in HKLM [sic!],
but the component associated to the ProgramFilesFolder directory
instead of the start menu subdirectory being removed. This doesn't
give the ICE38 error like 4b, probably because ProgramFilesFolder is
properly identified as a global directory instead of part of the user
profile. This is exactly what WiX 3.7's own core.msi does. Since the
component doesn't install any files, I think it doesn't even matter
what directory it's associated to...


I also looked at what Orca.msi does. It turns out the whole problem
with R

Re: [WiX-users] WiX disaster -- how did I cause it?

2013-10-03 Thread Blair Murri

I'm curious: if you move the component that is per-user into a separate 
feature, would you still get the reboot?
 
The reason is that in this scenario, when the new user starts up the system, 
and Windows Installer discovers that the per-user component "isn't installed" 
it first starts a repair. It will always start the repair on the smallest scope 
possible (the feature containing the missing component). If that feature can be 
repaired without a reboot, then there would never have been a problem.
 
> From: nicolas.alva...@gmail.com
> Date: Thu, 3 Oct 2013 17:34:58 -0300
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] WiX disaster -- how did I cause it?
> 
> 2013/9/30 Charles Jenkins :
> > But when another user logs in and double-clicks the newly installed program 
> > icon, the installer briefly appears saying the program will be installed; 
> > then the program starts, but a reboot is also scheduled on the server -- 
> > regardless of the fact that other users don't have privilege to reboot the 
> > server. The first day after installing my product was a nightmare, with the 
> > server rebooting every five or ten minutes when each new user tried to run 
> > my program.
> 
> I have an idea of why this may have happened. Does your .exe file have
> a file version? If you go to the file properties in Explorer, in the
> Details tab, is there a file version?
> 
> -- 
> Nicolás
> 
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] .NET support question for custom actions

2013-10-03 Thread Blair Murri

Shooting from way outside of the court here, but could the order of the 
supportedRuntime elements matter? I've always seen them in the opposite order.
 
> From: chr...@iswix.com
> To: wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net
> Date: Thu, 3 Oct 2013 16:17:00 -0700
> Subject: Re: [WiX-users] .NET support question for custom actions
> 
> I've never had a problem with this. I typically compile for .NET 2.0 and 
> set the customaction.config to allow for CLR 2.0 or 4.0 and allow legacy 
> activation.  This gives me the broadest compatibility
> 
> Is there a .NET 3.5 feature you really need in your custom action?  
> 
> 
>  From: "Uma Harano" 
> Sent: Thursday, October 03, 2013 5:51 PM
> To: "General discussion for Windows Installer XML toolset." 
> wix-users@lists.sourceforge.net.  
> Subject: Re: [WiX-users] .NET support question for custom actions
> 
> Clarification: I am using WiX 3.5 tool set to build this right now.
> 
> -Original Message-
> From: Uma Harano [mailto:uhar...@esri.com] 
> Sent: Thursday, October 03, 2013 3:38 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] .NET support question for custom actions
> 
> Hi,
> I have a Visual Studio solution that uses DTF to create Custom Actions for 
> my setup. I am using WiX 3.6. The custom actions need to work on machines 
> that have  .NET Framework 3.5 sp1 or .NET 4.5. My CustomAction.config file 
> has this information:
> 
> 
> 
> 
> 
> When I run the setup that includes these custom actions on a Windows 8.1 
> machine that has only .NET 4.5, everything works. But when I run the same 
> msi on a Server 2008 R2 machine that has only .NET 3.5 SP1, the setup 
> crashes. This is the info from the log:
> 
> Invoking remote custom action. DLL: 
> C:\Users\uma2526\AppData\Local\Temp\MSIC72C.tmp, Entrypoint: GetSiteCount
> SFXCA: Extracting custom action to temporary directory: 
> C:\Users\uma2526\AppData\Local\Temp\MSIC72C.tmp-\
> SFXCA: Failed to get requested CLR info. Error code 0x80131700
> SFXCA: Ensure that the proper version of the .NET Framework is installed, 
> or that there is a matching supportedRuntime element in 
> CustomAction.config. If you are binding to .NET 4 or greater add 
> useLegacyV2RuntimeActivationPolicy=true to the  element.
> CustomAction DotNetGetWebsiteCount returned actual error code 1603 (note 
> this may not be 100% accurate if translation happened inside sandbox)
> 
> How can I get my msi program to work on both scenarios?
> Thanks!
> Uma-
> 
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and 
> register > 
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> 
> 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most 
> from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> 
> 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/

Re: [WiX-users] .NET support question for custom actions

2013-10-03 Thread Christopher Painter

I've never had a problem with this. I typically compile for .NET 2.0 and 
set the customaction.config to allow for CLR 2.0 or 4.0 and allow legacy 
activation.  This gives me the broadest compatibility

Is there a .NET 3.5 feature you really need in your custom action?  

 From: "Uma Harano" 
Sent: Thursday, October 03, 2013 5:51 PM
To: "General discussion for Windows Installer XML toolset." 
wix-users@lists.sourceforge.net.  
Subject: Re: [WiX-users] .NET support question for custom actions

Clarification: I am using WiX 3.5 tool set to build this right now.

-Original Message-
From: Uma Harano [mailto:uhar...@esri.com] 
Sent: Thursday, October 03, 2013 3:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] .NET support question for custom actions

Hi,
I have a Visual Studio solution that uses DTF to create Custom Actions for 
my setup. I am using WiX 3.6. The custom actions need to work on machines 
that have  .NET Framework 3.5 sp1 or .NET 4.5. My CustomAction.config file 
has this information:

When I run the setup that includes these custom actions on a Windows 8.1 
machine that has only .NET 4.5, everything works. But when I run the same 
msi on a Server 2008 R2 machine that has only .NET 3.5 SP1, the setup 
crashes. This is the info from the log:

Invoking remote custom action. DLL: 
C:\Users\uma2526\AppData\Local\Temp\MSIC72C.tmp, Entrypoint: GetSiteCount
SFXCA: Extracting custom action to temporary directory: 
C:\Users\uma2526\AppData\Local\Temp\MSIC72C.tmp-\
SFXCA: Failed to get requested CLR info. Error code 0x80131700
SFXCA: Ensure that the proper version of the .NET Framework is installed, 
or that there is a matching supportedRuntime element in 
CustomAction.config. If you are binding to .NET 4 or greater add 
useLegacyV2RuntimeActivationPolicy=true to the  element.
CustomAction DotNetGetWebsiteCount returned actual error code 1603 (note 
this may not be 100% accurate if translation happened inside sandbox)

How can I get my msi program to work on both scenarios?
Thanks!
Uma-

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most 
from the latest Intel processors and coprocessors. See abstracts and 
register > 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk

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

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most 
from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk

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

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] .NET support question for custom actions

2013-10-03 Thread Uma Harano

Clarification: I am using WiX 3.5 tool set to build this right now.

-Original Message-
From: Uma Harano [mailto:uhar...@esri.com] 
Sent: Thursday, October 03, 2013 3:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] .NET support question for custom actions

Hi,
I have a Visual Studio solution that uses DTF to create Custom Actions for my 
setup. I am using WiX 3.6. The custom actions need to work on machines that 
have  .NET Framework 3.5 sp1 or .NET 4.5. My CustomAction.config file has this 
information:

When I run the setup that includes these custom actions on a Windows 8.1 
machine that has only .NET 4.5, everything works. But when I run the same msi 
on a Server 2008 R2 machine that has only .NET 3.5 SP1, the setup crashes. This 
is the info from the log:

Invoking remote custom action. DLL: 
C:\Users\uma2526\AppData\Local\Temp\MSIC72C.tmp, Entrypoint: GetSiteCount
SFXCA: Extracting custom action to temporary directory: 
C:\Users\uma2526\AppData\Local\Temp\MSIC72C.tmp-\
SFXCA: Failed to get requested CLR info. Error code 0x80131700
SFXCA: Ensure that the proper version of the .NET Framework is installed, or 
that there is a matching supportedRuntime element in CustomAction.config. If 
you are binding to .NET 4 or greater add 
useLegacyV2RuntimeActivationPolicy=true to the  element.
CustomAction DotNetGetWebsiteCount returned actual error code 1603 (note this 
may not be 100% accurate if translation happened inside sandbox)

How can I get my msi program to work on both scenarios?
Thanks!
Uma-
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register > 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] .NET support question for custom actions

2013-10-03 Thread Uma Harano

Hi,
I have a Visual Studio solution that uses DTF to create Custom Actions for my 
setup. I am using WiX 3.6. The custom actions need to work on machines that 
have  .NET Framework 3.5 sp1 or .NET 4.5. My CustomAction.config file has this 
information:



  

When I run the setup that includes these custom actions on a Windows 8.1 
machine that has only .NET 4.5, everything works. But when I run the same msi 
on a Server 2008 R2 machine that has only .NET 3.5 SP1, the setup crashes. This 
is the info from the log:

Invoking remote custom action. DLL: 
C:\Users\uma2526\AppData\Local\Temp\MSIC72C.tmp, Entrypoint: GetSiteCount
SFXCA: Extracting custom action to temporary directory: 
C:\Users\uma2526\AppData\Local\Temp\MSIC72C.tmp-\
SFXCA: Failed to get requested CLR info. Error code 0x80131700
SFXCA: Ensure that the proper version of the .NET Framework is installed, or 
that there is a matching supportedRuntime element in CustomAction.config. If 
you are binding to .NET 4 or greater add 
useLegacyV2RuntimeActivationPolicy=true to the  element.
CustomAction DotNetGetWebsiteCount returned actual error code 1603 (note this 
may not be 100% accurate if translation happened inside sandbox)

How can I get my msi program to work on both scenarios?
Thanks!
Uma-
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX disaster -- how did I cause it?

2013-10-03 Thread Nicolás Alvarez

2013/9/30 Charles Jenkins :
> But when another user logs in and double-clicks the newly installed program 
> icon, the installer briefly appears saying the program will be installed; 
> then the program starts, but a reboot is also scheduled on the server -- 
> regardless of the fact that other users don't have privilege to reboot the 
> server. The first day after installing my product was a nightmare, with the 
> server rebooting every five or ten minutes when each new user tried to run my 
> program.

I have an idea of why this may have happened. Does your .exe file have
a file version? If you go to the file properties in Explorer, in the
Details tab, is there a file version?

-- 
Nicolás

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX disaster -- how did I cause it?

2013-10-03 Thread Keith.Douglas

When I had set up my shortcut (unadvertised, but I am not sure that matters) 
mentioned a few posts back, I got the impression that the registry key didn't 
really matter; it was just a "vestige" of some Windows Installer weirdness and 
would sort of "pollute" the installing user's profile, but that was it. My 
application certainly installs perMachine and all users easily see the shortcut 
in the start menu, etc.

Confound here is that we're using 2003r2 on the machine in question, I guess.

I guess another confound is that I was basically just following the 
documentation without any clear understanding of some aspects of WiX and 
certainly not of many parts of Windows Installer.



Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-951-4405
Facsimile | Télécopieur 613-951-1966
Government of Canada | Gouvernement du Canada 


-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] 
Sent: October-03-13 3:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX disaster -- how did I cause it?

2013/9/30 Nicolás Alvarez :
> 2013/9/30 Charles Jenkins :
>> As always, thank you all for trying to help.
>>
>> Rob, I took your and Phil's advice and scoped out the Event Log. Indeed it 
>> appears the missing component is that user-specific registry key that I 
>> personally don't want anyway, but MSI seems to require:
>>
>> Detection of product '{EC784F33-0A7C-4899-875B-5ADC75D7A670}', feature 
>> 'ProductFeature', component '{D3EB384F-AA52-4AAF-AD55-F610C55DC2C7}' failed. 
>> The resource 'HKEY_CURRENT_USER\Software\TEC\TEC Timesheet\' does not exist.
>>
>> I tried commenting out just the RegistryKey line, but that gets me the 
>> familiar error "ICE38: Component StartMenuDir installs to user profile. It 
>> must use a registry key under HKCU as its KeyPath, not a file."
>>
>> I'm wondering if the root of the problem is that StartMenuDir installs into 
>> a user profile. What I'm trying to do is create a program menu folder for 
>> all users. Have I just chosen completely the wrong approach?
>
> The registry key should be in HKLM to avoid your 
> product-getting-repaired problem (I don't know why that causes a 
> reboot, but I think that's beside the point; this shouldn't need a 
> reboot-less repair either). So your real problem is now ICE38. I can't 
> figure out why it's saying the component installs to user profile. The 
> ProgramMenuFolder property should be getting set to the 'all users'
> start menu if you have Package/@InstallScope="perMachine" (which you 
> do).
>
> But let's take a step back. Your StartMenuDir component only has two
> things: the RemoveFolder, and the registry key. The shortcut directory 
> is not in that component, because directories don't "belong to 
> components" to begin with, they are created when needed (in this case 
> when creating the shortcut). Is it normal/correct to have the 
> RemoveFolder in a different component? Is there any reason why it 
> can't go to the main component with the .exe and the shortcut? If so, 
> you won't need the registry key at all.
>
> Perhaps ICE38 is getting confused and saying the component installs to 
> a user profile because it doesn't install anything at all :)

OK, I'm now hitting a very similar problem myself...

I made a simple installer with a single .exe, an advertised shortcut, and a 
RemoveFolder for the start menu folder where the shortcut is, all in the same 
component, which is what I suggested in my previous email. That worked just 
fine, with no need for a registry key... until I had to add a second executable 
and shortcut. The whole idea breaks down if I have multiple shortcuts. I can't 
put it in one of the components, because later I may want to put the two 
exe+shortcut components in different features, so any of the two components may 
not be installed.

So I moved the RemoveFolder to a different component, inside the Directory 
matching the folder being removed. "ICE38: component installs to user profile, 
must have HKCU registry key as keypath." I'm pretty sure I can now say I feel 
your pain :)

If the ALLUSERS property is set to 1, ProgramMenuFolder is set to the "all 
users" start menu, which is *not* in the user profile, and I think everything 
would be safe (I couldn't even override it by setting
ALLUSERS=0 in the command line). Isn't ICE38 wrong in this case?

--
Nicolás

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register > 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_

Re: [WiX-users] WiX disaster -- how did I cause it?

2013-10-03 Thread Nicolás Alvarez

2013/9/30 Nicolás Alvarez :
> 2013/9/30 Charles Jenkins :
>> As always, thank you all for trying to help.
>>
>> Rob, I took your and Phil's advice and scoped out the Event Log. Indeed it 
>> appears the missing component is that user-specific registry key that I 
>> personally don't want anyway, but MSI seems to require:
>>
>> Detection of product '{EC784F33-0A7C-4899-875B-5ADC75D7A670}', feature 
>> 'ProductFeature', component '{D3EB384F-AA52-4AAF-AD55-F610C55DC2C7}' failed. 
>> The resource 'HKEY_CURRENT_USER\Software\TEC\TEC Timesheet\' does not exist.
>>
>> I tried commenting out just the RegistryKey line, but that gets me the 
>> familiar error "ICE38: Component StartMenuDir installs to user profile. It 
>> must use a registry key under HKCU as its KeyPath, not a file."
>>
>> I'm wondering if the root of the problem is that StartMenuDir installs into 
>> a user profile. What I'm trying to do is create a program menu folder for 
>> all users. Have I just chosen completely the wrong approach?
>
> The registry key should be in HKLM to avoid your
> product-getting-repaired problem (I don't know why that causes a
> reboot, but I think that's beside the point; this shouldn't need a
> reboot-less repair either). So your real problem is now ICE38. I can't
> figure out why it's saying the component installs to user profile. The
> ProgramMenuFolder property should be getting set to the 'all users'
> start menu if you have Package/@InstallScope="perMachine" (which you
> do).
>
> But let's take a step back. Your StartMenuDir component only has two
> things: the RemoveFolder, and the registry key. The shortcut directory
> is not in that component, because directories don't "belong to
> components" to begin with, they are created when needed (in this case
> when creating the shortcut). Is it normal/correct to have the
> RemoveFolder in a different component? Is there any reason why it
> can't go to the main component with the .exe and the shortcut? If so,
> you won't need the registry key at all.
>
> Perhaps ICE38 is getting confused and saying the component installs to
> a user profile because it doesn't install anything at all :)

OK, I'm now hitting a very similar problem myself...

I made a simple installer with a single .exe, an advertised shortcut,
and a RemoveFolder for the start menu folder where the shortcut is,
all in the same component, which is what I suggested in my previous
email. That worked just fine, with no need for a registry key... until
I had to add a second executable and shortcut. The whole idea breaks
down if I have multiple shortcuts. I can't put it in one of the
components, because later I may want to put the two exe+shortcut
components in different features, so any of the two components may not
be installed.

So I moved the RemoveFolder to a different component, inside the
Directory matching the folder being removed. "ICE38: component
installs to user profile, must have HKCU registry key as keypath." I'm
pretty sure I can now say I feel your pain :)

If the ALLUSERS property is set to 1, ProgramMenuFolder is set to the
"all users" start menu, which is *not* in the user profile, and I
think everything would be safe (I couldn't even override it by setting
ALLUSERS=0 in the command line). Isn't ICE38 wrong in this case?

-- 
Nicolás

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CA not logging anything on button press

2013-10-03 Thread Rob Mensching

For debugging purposes, IIRC, you can call ::MessageBox(). Just don't
submit that to end-users.


On Thu, Oct 3, 2013 at 11:46 AM, Tunney, Stephen
wrote:

> Thank you Rob for confirming my fears :(
>
> Any suggested workarounds for this?  I've been putting my messages into
> custom session properties and then reading them in the log file but it is
> really hard to get a handle on the continuity of the CA with other things
> going on as well in the background.
>
> Suggestions welcome or we can just let this thread die a peaceful and
> meaningless death.
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: October-03-13 2:00 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] CA not logging anything on button press
>
> Known issue with Windows Installer.
>
>
> On Thu, Oct 3, 2013 at 10:54 AM, Tunney, Stephen
> wrote:
>
> > Hey guys,
> >
> > I have a managed CA writing a tonne of messages our and a DoAction
> > call from a pushbutton on my dialog (immediate CA).
> >
> > The CA runs just fine but I get ZERO log entries anywhere in the /l*v
> > log that I'm writing out to.
> >
> > Any thoughts?  I remember this being an issue in windows installer but
> > I was hoping there was a known workaround.
> >
> > Cheers,
> > Stephen Tunney
> >
> > --
> >  October Webinars: Code for Performance Free Intel webinars
> > can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> > most from the latest Intel processors and coprocessors. See abstracts
> > and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.c
> > lktrk ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CA not logging anything on button press

2013-10-03 Thread Tunney, Stephen

Thank you Rob for confirming my fears :(

Any suggested workarounds for this?  I've been putting my messages into custom 
session properties and then reading them in the log file but it is really hard 
to get a handle on the continuity of the CA with other things going on as well 
in the background.

Suggestions welcome or we can just let this thread die a peaceful and 
meaningless death.

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: October-03-13 2:00 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] CA not logging anything on button press

Known issue with Windows Installer.


On Thu, Oct 3, 2013 at 10:54 AM, Tunney, Stephen
wrote:

> Hey guys,
>
> I have a managed CA writing a tonne of messages our and a DoAction 
> call from a pushbutton on my dialog (immediate CA).
>
> The CA runs just fine but I get ZERO log entries anywhere in the /l*v 
> log that I'm writing out to.
>
> Any thoughts?  I remember this being an issue in windows installer but 
> I was hoping there was a known workaround.
>
> Cheers,
> Stephen Tunney
>
> --
>  October Webinars: Code for Performance Free Intel webinars 
> can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the 
> most from the latest Intel processors and coprocessors. See abstracts 
> and register > 
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.c
> lktrk ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register > 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Cannot submit a bug

2013-10-03 Thread Ivanoff, Alex

Never mind, my bad. Sorry.


-Original Message-
From: Ivanoff, Alex [mailto:alex.ivan...@shavlik.com] 
Sent: Thursday, October 3, 2013 13:33
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Cannot submit a bug

I am getting the following error trying to submit a bug on wixtoolset.org:

Error! Something went awry while submitting your changes. Please, try again.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register > 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Cannot submit a bug

2013-10-03 Thread Ivanoff, Alex

I am getting the following error trying to submit a bug on wixtoolset.org:

Error! Something went awry while submitting your changes. Please, try again.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CA not logging anything on button press

2013-10-03 Thread Rob Mensching

Known issue with Windows Installer.


On Thu, Oct 3, 2013 at 10:54 AM, Tunney, Stephen
wrote:

> Hey guys,
>
> I have a managed CA writing a tonne of messages our and a DoAction call
> from a pushbutton on my dialog (immediate CA).
>
> The CA runs just fine but I get ZERO log entries anywhere in the /l*v log
> that I'm writing out to.
>
> Any thoughts?  I remember this being an issue in windows installer but I
> was hoping there was a known workaround.
>
> Cheers,
> Stephen Tunney
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] CA not logging anything on button press

2013-10-03 Thread Tunney, Stephen

Hey guys,

I have a managed CA writing a tonne of messages our and a DoAction call from a 
pushbutton on my dialog (immediate CA).

The CA runs just fine but I get ZERO log entries anywhere in the /l*v log that 
I'm writing out to.

Any thoughts?  I remember this being an issue in windows installer but I was 
hoping there was a known workaround.

Cheers,
Stephen Tunney
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Authoring a Major & Minor upgrade in same package

2013-10-03 Thread Blair Murri

If you have the screen go blank/taskbar disappear and then everything 
reappears, and there was someone else logged in, you will prompt for reboot 
anyway. But (as happens in the majority of cases with workstations) no one else 
was logged in, you will be done.
 
It's really your call. Different people will have different preferences. Some 
people hate reboots with a passion (and if they are your customers, ...)
 
> From: jacob.hoo...@greenheck.com
> To: wix-users@lists.sourceforge.net
> Date: Wed, 2 Oct 2013 21:48:04 +
> Subject: Re: [WiX-users] Authoring a Major & Minor upgrade in same package
> 
> Reboot, since it's 100% effective.
> 
> In a multi-user environment, you wouldn't want to be killing everyone's shell 
> off (if it were even possible). If it were me, I wouldn't force the reboot 
> either. (Similar to how TortoiseGit upgrades happen; I can ignore the reboot 
> till it suits me.)
> 
> -Original Message-
> From: victorwhiskey [mailto:victorhwhis...@yahoo.com] 
> Sent: Wednesday, October 02, 2013 4:38 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Authoring a Major & Minor upgrade in same package
> 
> Thanks for the info and tips. This brings me to another post of mine  here 
> 
> . I asked if it was possible to update a context menu handler component 
> without rebooting or restarting explorer. Which would be the better 
> experience? Tell the user a reboot is necessary, or restart explorer and have 
> the screen go blank and all icons and taskbar disappear?
> 
> Thanks
> 
> 
> 
> --
> View this message in context: 
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Authoring-a-Major-Minor-upgrade-in-same-package-tp7589392p7589411.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register > 
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX disaster -- how did I cause it?

Re: [WiX-users] WiX disaster -- how did I cause it?

Re: [WiX-users] .NET support question for custom actions

Re: [WiX-users] .NET support question for custom actions

Re: [WiX-users] .NET support question for custom actions

[WiX-users] .NET support question for custom actions

Re: [WiX-users] WiX disaster -- how did I cause it?

Re: [WiX-users] WiX disaster -- how did I cause it?

Re: [WiX-users] WiX disaster -- how did I cause it?

Re: [WiX-users] CA not logging anything on button press

Re: [WiX-users] CA not logging anything on button press

Re: [WiX-users] Cannot submit a bug

[WiX-users] Cannot submit a bug

Re: [WiX-users] CA not logging anything on button press

[WiX-users] CA not logging anything on button press

Re: [WiX-users] Authoring a Major & Minor upgrade in same package

16 matches

Site Navigation

Mail list logo

Footer information