Re: [WiX-users] Validation on UI dialogs
Unless there is a much more elegant method, you may try a good ole' Win32 method: - use Spy++ to find the dialog ID of the control (s): - use Setup Window title to find the dialog HWND (you may be doing this already to parent your message window) - get HWND of the control using GetDlgItem - call SetFocus(hwnd) -Original Message- From: Sankaranarayanan [mailto:loony...@yahoo.com] Sent: Wednesday, December 09, 2009 2:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Validation on UI dialogs Hi All, For validating the fields in Custom UI for empty / null values - I am calling a Custom action on "DoAction" event of the Next Button and spawing a new dialog if all the input values are correctly entered. Incase of any blank values - I popup a message box from the custom action code to notify the user but I am not able to set the focus back to the erroring field. Is there a way to set the focus from the Next Button to the erroring field from the Custom action code. Thanks, Loonysan http://mystutter.blogspot.com TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Quick Launch shortcut in Vista and Windows 7
The right substitute for Vista/XP like Quick Launch shortcut is to make the link pinned to the taskbar (IMO). It appears as simple as putting the shortcut in User Pinned\TaskBar subfolder of Quick Launch folder in Windows 7. Now, I can condition the installation of the component containing the Shortcut element. When OS is Windows 7 shortcut gets created in QL6 directory, otherwise in QL4. Since this would unnecessarily create User Pinned\TaskBar folders on Vista and XP, does anybody know if there is a more elegant way to accomplish the same goal? TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7
Hmm... I guess I would have a hard time to pass a concept here that I actually like the declarative way of doing things and am given to push it as much as possible, no matter how much attained functionality is approved of or looked down upon in certain circles. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Thursday, December 17, 2009 7:51 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7 It's not that simple, in fact it's not supported at all.. see http://blogs.msdn.com/oldnewthing/archive/2003/09/03/54760.aspx for some background. The Quick Launch shortcuts were never supported either, however it developers quickly figured out that dropping a shortcut in the folder did the trick. There are ways to do it, but that's outside the scope of this list. And anyway auto-pinning your application to the Windows 7 taskbar will an excellent way to quickly lose customers :) Sascha On Fri, Dec 18, 2009 at 7:53 AM, Tony Juricic wrote: > The right substitute for Vista/XP like Quick Launch shortcut is to make the > link pinned to the taskbar (IMO). > > It appears as simple as putting the shortcut in User Pinned\TaskBar subfolder > of Quick Launch folder in Windows 7. > > > > > > > > > > > > > > Now, I can condition the installation of the component containing the > Shortcut element. > When OS is Windows 7 shortcut gets created in QL6 directory, otherwise in QL4. > > Since this would unnecessarily create User Pinned\TaskBar folders on Vista > and XP, does anybody know if there is a more elegant way to accomplish the > same goal? > > TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: > TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member > NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading > software and subscription company, and TradeStation Europe Limited, a United > Kingdom, FSA-authorized introducing brokerage firm. None of these companies > provides trading or investment advice, recommendations or endorsements of any > kind. The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7
You want small, medium or large drink? You are having it on white, wheat or rye? Mustard or mayo? Honey mustard or spicy mustard? You can have one side with that , would you like ... Happy holidays to all WiX pms, devs and testers who brought us this great tool! -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Tuesday, December 22, 2009 11:58 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7 Tony Juricic wrote: > Hmm... I guess I would have a hard time to pass a concept here that I > actually like the declarative way of doing things and am given to push it as > much as possible, no matter how much attained functionality is approved of or > looked down upon in certain circles. > There's a reason it's not supported: The user should be in charge, not apps being pushy. -- sig://boB http://joyofsetup.com/ TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7
Because of various other factors, I require from users to have admin rights when installing and running the app. So this is not a problem for me (at least not for now). But you don't have to be admin to install the application. Administrator can approve of certain MSI to be installed by non-elevated users on his network and MSI takes care of elevating the rights so that, for example, folders and files can be created in Program Files. I tested this scenario once: I allowed all users on my machine to run MSI and as non-elevated user I had no problem installing the app. I had problems running it because some of installed apps write to Program Files subfolders, but that's another issue. -Original Message- From: Thomas Singer [mailto:w...@regnis.de] Sent: Wednesday, December 23, 2009 3:04 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7 Tony, how do you catch the case, that your user only can install applications elevated as administrator (don't assume everybody is admin on his/her machine)? Wouldn't the quick launch shortcut then only appear on the administrator's quick launch bar and hence is invisible for the normal user(s)? Tom On 17.12.2009 21:53, Tony Juricic wrote: > The right substitute for Vista/XP like Quick Launch shortcut is to make the > link pinned to the taskbar (IMO). > > It appears as simple as putting the shortcut in User Pinned\TaskBar subfolder > of Quick Launch folder in Windows 7. > > > > > > > > > > > > > > Now, I can condition the installation of the component containing the > Shortcut element. > When OS is Windows 7 shortcut gets created in QL6 directory, otherwise in QL4. > > Since this would unnecessarily create User Pinned\TaskBar folders on Vista > and XP, does anybody know if there is a more elegant way to accomplish the > same goal? TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7
I am not sure if I understood the question well and if my previous response
makes sense. But this is how would I try doing it if I had to do it and if WiX
didn't let me do declaratively:
Even if MSI (or more correctly parts of install) run with elevated privileges,
I think that immediate custom action runs non-elevated and I can find current
user's ApplicationData folder via Shell API call GetSpecialFolder. I can then
create shortcut links programmatically in custom action code as seen below (I
don't know where I got it from, probably some MSDN article).
//-
//
// CreateLink - uses the Shell's IShellLink and IPersistFile interfaces
// to create and store a shortcut to the specified object.
//
// Returns the result of calling the member functions of the interfaces.
//
// Parameters:
// lpszPathObj - address of a buffer containing the path of the object.
// lpszPathLink - address of a buffer containing the path where the
//Shell link is to be stored.
// lpszDesc - address of a buffer containing the description of the
//Shell link.
// lpszIconLink - address of a buffer containing the path where the
//Shell link icon can be found.
// index- index of the icon
//-
HRESULT CreateLink(LPCTSTR lpszPathObj, LPCTSTR lpszPathLink, LPCTSTR lpszDesc,
LPCTSTR lpszIconLink, int index)
{
HRESULT hres;
IShellLink* psl;
// Get a pointer to the IShellLink interface.
hres=::CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER,
IID_IShellLink, (LPVOID*)&psl);
if(SUCCEEDED(hres))
{
IPersistFile* ppf;
// Set the path to the shortcut target and add the description.
psl->SetPath(lpszPathObj);
psl->SetDescription(lpszDesc);
if(lpszIconLink!=0)
psl->SetIconLocation(lpszIconLink, index);
// Query IShellLink for the IPersistFile interface for saving the
// shortcut in persistent storage.
hres=psl->QueryInterface(IID_IPersistFile, (LPVOID*)&ppf);
if(SUCCEEDED(hres))
{
USES_CONVERSION;
// Ensure that the string is Unicode.
LPWSTR wsz=CT2W(lpszPathLink);
// Add code here to check return value from MultiByteWideChar
// for success.
// Save the link by calling IPersistFile::Save.
hres = ppf->Save(wsz, TRUE);
ppf->Release();
}
psl->Release();
}
return hres;
}
-Original Message-
From: Thomas Singer [mailto:w...@regnis.de]
Sent: Wednesday, December 23, 2009 3:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7
Tony, how do you catch the case, that your user only can install
applications elevated as administrator (don't assume everybody is admin on
his/her machine)? Wouldn't the quick launch shortcut then only appear on the
administrator's quick launch bar and hence is invisible for the normal user(s)?
Tom
On 17.12.2009 21:53, Tony Juricic wrote:
> The right substitute for Vista/XP like Quick Launch shortcut is to make the
> link pinned to the taskbar (IMO).
>
> It appears as simple as putting the shortcut in User Pinned\TaskBar subfolder
> of Quick Launch folder in Windows 7.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Now, I can condition the installation of the component containing the
> Shortcut element.
> When OS is Windows 7 shortcut gets created in QL6 directory, otherwise in QL4.
>
> Since this would unnecessarily create User Pinned\TaskBar folders on Vista
> and XP, does anybody know if there is a more elegant way to accomplish the
> same goal?
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these companies provides
trading or investment advice, recommendations or endorsements of any kind. The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entiti
[WiX-users] Patching custom actions
At which point in the patching process are custom actions that are executing the updated ones? I have custom actions that execute before and after PatchFiles action. Custom action executing before PatchFiles finds MSI DB already transformed. Based on that I would expect that table containing custom action dll binaries is also already updated and that custom action that is currently executing is the updated one. Since testing it is a bit too laborious in my case, I hope some expert can answer this question. Thanks in advance. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Does patch removal restore removed data files?
In my patch application I am removing one executable file and its corresponding config file like this: 0 0 When I remove this patch, My.exe gets restored but not My.exe.config. Is this to be expected? Using /lv*x to log patch removal I see nothing regarding the config file that would give me the clue why is it not restored. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does patch removal restore removed data files?
I marked all Files as Transitive with: 1 in my target build. So I expected all files to be transitive, all the time. It is only the condition that changes from 1 to 0 when and if I remove files. New files, if any, that get added to the patch are always added with: 1 It looked like it should work and that is why I have each file in its own component. -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: Thursday, January 21, 2010 1:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does patch removal restore removed data files? It's possible that transitive state ends up in the component state on the system, and uninstalling the patch won't restore it to non-transitive. There doesn't seem to be an API that actually tells you if a component is currently marked transitive. Phil Wilson -Original Message----- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Thursday, January 21, 2010 8:19 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Does patch removal restore removed data files? In my patch application I am removing one executable file and its corresponding config file like this: 0 0 When I remove this patch, My.exe gets restored but not My.exe.config. Is this to be expected? Using /lv*x to log patch removal I see nothing regarding the config file that would give me the clue why is it not restored. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does patch removal restore removed data files?
I think that now I understand what happened. My expectation about patching system behavior when component is transitive was wrong. During patch application, transitive component condition gets evaluated and, if it has changed from true to false, component gets deleted. However, to facilitate patch removal (which means that deleted component must be restored), the system doesn't cache the component somewhere. The patch that deletes the component cannot be removed in every case, without access to the original MSI. In one case when I had patch removal appear to restore the deleted component, it was because I have already patched the component once before its removal. So it existed in baseline cache and original MSI was not needed. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does patch removal restore removed data files?
That's right. I my experience it doesn't really matter if component remains transitive (my case) or loses transitive state when removing the patch. The question to ask is: if patch application removed file(s), when patch itself is removed how will those files come back? And the answer seems to be: unless they somehow ended up in MSI cache, you will need the original MSI file. I admit that by keeping components/files marked as transitive all the time, I expected that patching system will somehow get the signal to cache the file and in my tests it looked like that is really happening. Except that file was cached because of previous patch application. The real problem is that setup executables typically run in temporary folder and MSI file will probably be lost some time after the install. Instead, MSI should be put in a known location to be a source in addition to baseline cache. I still don't understand how would you pass that source location when patch is removed via the Control Panel ARP. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, January 23, 2010 3:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does patch removal restore removed data files? That does sound very much like the behavior described here: http://blogs.msdn.com/pmarcu/archive/2009/05/19/wix-removing-files-with-patches.aspx -- virtually, Rob Mensching - http://RobMensching.com LLC TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to add Patch table to MSI in order to change Sequence type I2 to I4?
I run into this problem when creating the patch: ERROR: Internal PatchWiz Error occurred. ERROR:The Last Error Received is: 1627 ERROR:The Last Error Received is: 1: 2210 2: which is caused by Patch table having default Sequence field of type I2 I used Orca to create default Patch table and modified Sequence field to be I4. Then I successfully created the patch. When applying the patch I get the following error: MSI (c) (CC:AC) [12:07:49:059]: Note: 1: 2255 2: 3: Patch 4: Sequence DEBUG: Error 2255: Database: Transform: Column with this name already exists. Table: Patch Col: Sequence 1: 2255 2: 3: Patch 4: Sequence This update package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer update package. Is there any way to get around this once RTM is already out in the field? TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] DTF ExternalUI free of System.Windows.Forms
Since my external UI is WPF I am really bothered, both by having to disambiguate several classes and by having to reference forms Dll just for a few enums, when calling Installer.SetExternalUI. Hopefully these enums will become UI-system-agnostic in the future. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question regarding the behaviour of custom actions during patch uninstall
I believe so. Custom action are in MSI database which is transformed before the install/uninstall (really repair in the case of the patch) starts running custom actions. So during patch install you get patched actions executing. During uninstall you get unpatched action or no action executing because that is the state of the database before it was transformed by the patch. Now it got transformed back and it lost added custom actions. -Original Message- From: Anurag Pahwa [mailto:apa...@microsoft.com] Sent: Tuesday, February 09, 2010 4:37 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Question regarding the behaviour of custom actions during patch uninstall Hi, I've scenario where I've added a couple of custom actions as part of the patch and sequenced them in during install as well as the uninstall. Now during patch install the custom actions are executed properly but during patch uninstall none of the patched custom actions are executed. Is this by design? Thanks Anurag TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] recommended way to uninstall previous small updates
My understanding is that QFE2 is created as the difference between the RTM and your current code base. Applying QFE2 will use RTM as the base whether you installed QFE1 or no. There should be no need to uninstall QFE1 short of wanting to prevent user from ever running that code (which would be the case if user uninstalls QFE2 and has QFE1 installed before that). -Original Message- From: Lian Jiang [mailto:lji...@microsoft.com] Sent: Friday, February 19, 2010 8:44 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] recommended way to uninstall previous small updates Hi, I am using windows update to release the small updates (QFEs) after V1 RTM. Suppose I have QFE1 (released earlier) and QFE2 (released later). QFE1 should be uninstalled before QFE2 is installed so that any new QFE can use the RTM image as base. What is the recommended way to uninstall QFE1? Should I add a custom action in QFE2 to detect and uninstall previous QFEs? Or I don't need to do anything and windows installer is smart enough to uninstall QFE1 before it installs QFE2? Or I can author some pre-processing commands in windows update to detect and uninstall QFE1, then install QFE2? Appreciate your guidance. Thanks Lian TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Removing the program fromrecently opened programs Start menu on uninstall
During uninstall items added to the Start menu are removed. However, recently opened programs entry is still on Start menu for a while. I know that it will eventually become the oldest entry and will go away, but is there any API to remove it right away during uninstall? TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reinstall not updating correct registry value.
One way of avoiding overwrite by the default value during Change is to store INSTALLDIR value in the Registry as the part of custom action that is conditionally executed only on fresh install (i.e. Installed property) -Original Message- From: Sachin Dubey [mailto:sachin.du...@live.com] Sent: Saturday, March 06, 2010 3:06 PM To: Wix Users Subject: [WiX-users] Reinstall not updating correct registry value. Hi All, I got this weird issue. My installer creates a registry key in HKLM and stores the INSTALLDIR value. It provides default INSTALLDIR, however user can change it and the changed value gets stored in registry. Installer also have Change option enabled that REINSTALL = ALL All works fine except on WIN2K8 with UAC enabled- Install goes fine in this case also, however at Change\Reinstall the INSTALLDIR gets set to default not the one user provided. E.g. Install - DefaultINSTALLDIR = Value1, UserChangedINSTALLDIR = Value2 --> Value2 goes to registry. Reinstall\Change - The registry value gets replaced with default Value1. Also the Change option doesn't prompt for Elevation unlike the Install or Remove. Appreciate any help on this. Thanks Sachin! _ Hotmail: Trusted email with Microsoft's powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469226/direct/01/ TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Finally a GUI solution with WiX
If it were using WPF, I would seriously consider it. -Original Message- From: Michael Clark [mailto:mcl...@fullarmor.com] Sent: Thursday, May 13, 2010 5:02 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Finally a GUI solution with WiX I was just getting ready to start a new WiX project except it was looking like I would have to do a lot of custom GUI, then I came across this http://sharpsetup.eu/ -Michael Clark TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Do UFOs visit Install land?
The title reflects the strangeness of the problem that I am trying to solve. It is not WiX specific but in the broader install community there is higher chance that somebody may have had similar experience. It starts with user installing vcredist_x86.exe on his Windows 7 64-bit. He is sharing his desktop and I see vcredist_x86.exe UI. Installation is declared successful and ARP also shows C++ redistributables as installed. MSI log shows successful install listing CRT, MFC and other Dlls as copied to Windows\winsxs folder on user's machine. Yet, the application won't run because of side-by-side error involving missing MFC dll. Opening winsxs folder we see that supposedly installed libraries are nowhere to be found. Uninstalling and installing C++ redistributables several times didn't change the situation. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Do UFOs visit Install land?
Hi Phil, Here are the missing context and details. The app is 32 bit. It was built with C++ redistributables version 9.0.30729.4148. Exactly the same vcredist_x86.exe, that was installed on a build machine before RTM build, is run on end user's machine, before the application-specific MSI install starts. Hundreds of hours of testing of this install was done on pristine OS installs, from 32-bit and 64-bit XP SP2 OS, to equivalent Vista, Windows 7 and Windows Server 2008 OS. Approximately 4000 users, using 7 OS versions, did run exactly the same setup executable without any problems. It is only about 2 dozen Windows 7 64-bit users that have either this exact, or a similar problem, with the end result that the main app can't find MFC DLL version 9.0.30729.4148 and reports it in Windows Application Event Log as a side-by-side error. Tony -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Monday, May 24, 2010 2:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Do UFOs visit Install land? The C++ runtimes are very specific about what they want. You didn't say what versions you're referring to, but there are people have installed VC++ 2008 redist thinking it will support their VC++ 2005 app (it won't), and, for example, if you have built with VC++ 2008 SP1 the RTM VC++ 2008 redist won't help. They're almost sde by side, just to confuse things more. The app is 32-bit, I assume, but apart from that the UFOs are just hiding the gory details ;=) Phil Wilson -----Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Monday, May 24, 2010 7:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Do UFOs visit Install land? The title reflects the strangeness of the problem that I am trying to solve. It is not WiX specific but in the broader install community there is higher chance that somebody may have had similar experience. It starts with user installing vcredist_x86.exe on his Windows 7 64-bit. He is sharing his desktop and I see vcredist_x86.exe UI. Installation is declared successful and ARP also shows C++ redistributables as installed. MSI log shows successful install listing CRT, MFC and other Dlls as copied to Windows\winsxs folder on user's machine. Yet, the application won't run because of side-by-side error involving missing MFC dll. Opening winsxs folder we see that supposedly installed libraries are nowhere to be found. Uninstalling and installing C++ redistributables several times didn't change the situation. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
Re: [WiX-users] Do UFOs visit Install land?
Not yet, for the following reasons: a) quite a few times on this forum I read people recommending vcredist_x86.exe over MSMs, claiming that MSMs are buggy and that vcredist_x86.exe does a lot more than MSMs. b) re-implementing the install to use MSMs, instead of an exe, may be a day or two of work for me, but testing it will require resources that are hard to come on a hunch that it may work. However, I may be forced to try them, not having any other choice when facing the customers who just can't run the app without required MFC version. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Tuesday, May 25, 2010 2:18 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Do UFOs visit Install land? Have you tried using merge modules rather than the redistributable? On Tue, May 25, 2010 at 4:35 AM, Tony Juricic wrote: > Hi Phil, > > Here are the missing context and details. > > The app is 32 bit. It was built with C++ redistributables version > 9.0.30729.4148. Exactly the same vcredist_x86.exe, that was installed on a > build machine before RTM build, is run on end user's machine, before the > application-specific MSI install starts. Hundreds of hours of testing of this > install was done on pristine OS installs, from 32-bit and 64-bit XP SP2 OS, > to equivalent Vista, Windows 7 and Windows Server 2008 OS. > Approximately 4000 users, using 7 OS versions, did run exactly the same setup > executable without any problems. It is only about 2 dozen Windows 7 64-bit > users that have either this exact, or a similar problem, with the end result > that the main app can't find MFC DLL version 9.0.30729.4148 and reports it in > Windows Application Event Log as a side-by-side error. > > Tony > > -Original Message- > From: Wilson, Phil [mailto:phil.wil...@invensys.com] > Sent: Monday, May 24, 2010 2:13 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Do UFOs visit Install land? > > > The C++ runtimes are very specific about what they want. You didn't say what > versions you're referring to, but there are people have installed VC++ 2008 > redist thinking it will support their VC++ 2005 app (it won't), and, for > example, if you have built with VC++ 2008 SP1 the RTM VC++ 2008 redist won't > help. They're almost sde by side, just to confuse things more. The app is > 32-bit, I assume, but apart from that the UFOs are just hiding the gory > details ;=) > > Phil Wilson > > -Original Message- > From: Tony Juricic [mailto:tjuri...@tradestation.com] > Sent: Monday, May 24, 2010 7:39 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Do UFOs visit Install land? > > The title reflects the strangeness of the problem that I am trying to solve. > It is not WiX specific but in the broader install community there is higher > chance that somebody may have had similar experience. > It starts with user installing vcredist_x86.exe on his Windows 7 64-bit. He > is sharing his desktop and I see vcredist_x86.exe UI. Installation is > declared successful and ARP also shows C++ redistributables as installed. MSI > log shows successful install listing CRT, MFC and other Dlls as copied to > Windows\winsxs folder on user's machine. Yet, the application won't run > because of side-by-side error involving missing MFC dll. Opening winsxs > folder we see that supposedly installed libraries are nowhere to be found. > Uninstalling and installing C++ redistributables several times didn't change > the situation. > TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Do UFOs visit Install land?
Thanks for the pointers Phil! I would just like to clarify that the root of the problem that I'm having seems to be in the fact that nothing gets installed, not even the policy files. I looked into the manifest of all of my executables, finding entries like: That is expected since I am indeed using #define _BIND_TO_CURRENT. This particular user, that I was monitoring, has no higher version of MFC on his system. I would hope that higher version would redirect to itself, failing to find earlier version 9.0.30729.4148. But this would be the first time that any 9.x version of MFC gets installed on his system. I assume he has CRT because some fresh Windows 7 64 installs that I've seen come with CRT 9.0.30729.4926, as also confirmed in this thread: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/4d710d89-de7f-4d1f-8148-0aee63bf396d In his MSI log I see entries like: MSI (c) (80:54) [10:50:01:362]: PROPERTY CHANGE: Adding WindowsFolder.30729.4148.policy_9_0_Microsoft_VC90_MFCLOC_x86.QFE property. Its value is 'C:\Windows\'. Action ended 10:50:01: WindowsFolder.30729.4148.policy_9_0_Microsoft_VC90_MFCLOC_x86.QFE. Return value 1. MSI (c) (80:54) [10:50:01:362]: Doing action: WindowsFolder.30729.4148.policy_9_0_Microsoft_VC90_OpenMP_x86.QFE At the end of the install there is not a single file or folder containing pattern *30729.4148* in his winsxs. -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, May 25, 2010 12:51 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Do UFOs visit Install land? The issues are typically: Debug vs Release builds with different CRT requirements in the manifest (debug not same as release). People using merge modules, but not the policy merge modules that redirect old versions of the CRT up to the newer one. That means that sometimes you get inconsistent policies. The VCRedists always install policy assemblies to redirect users to the newer versions (last time I looked anyway). Misleading messages. MFC says it won't load, but maybe it's really the C Runtime that won't load, that MFC depends on. The #define_BIND_TO_CURRENT... macros can make things awkward if you have something like the ATL security fix on your system or other updates that are not included in the standard redist. Basically it doesn't matter what MFC/CRT files are on the system when there are policy files redirecting you. You'd have to look at your manifest, then see what MFC policy files are there that might redirect you, and the same for the CRT. Phil Wilson -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Monday, May 24, 2010 11:36 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Do UFOs visit Install land? Hi Phil, Here are the missing context and details. The app is 32 bit. It was built with C++ redistributables version 9.0.30729.4148. Exactly the same vcredist_x86.exe, that was installed on a build machine before RTM build, is run on end user's machine, before the application-specific MSI install starts. Hundreds of hours of testing of this install was done on pristine OS installs, from 32-bit and 64-bit XP SP2 OS, to equivalent Vista, Windows 7 and Windows Server 2008 OS. Approximately 4000 users, using 7 OS versions, did run exactly the same setup executable without any problems. It is only about 2 dozen Windows 7 64-bit users that have either this exact, or a similar problem, with the end result that the main app can't find MFC DLL version 9.0.30729.4148 and reports it in Windows Application Event Log as a side-by-side error. Tony -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Monday, May 24, 2010 2:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Do UFOs visit Install land? The C++ runtimes are very specific about what they want. You didn't say what versions you're referring to, but there are people have installed VC++ 2008 redist thinking it will support their VC++ 2005 app (it won't), and, for example, if you have built with VC++ 2008 SP1 the RTM VC++ 2008 redist won't help. They're almost sde by side, just to confuse things more. The app is 32-bit, I assume, but apart from that the UFOs are just hiding the gory details ;=) Phil Wilson -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Monday, May 24, 2010 7:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Do UFOs visit Install land? The title reflects the strangeness of the problem that I am trying to solve. It is not WiX specific but in the broader install community there is higher chance that somebody may have had similar experience. It starts with user installing vcredist_x86.exe on his Windows 7 6
Re: [WiX-users] Patching Base Versions
I always use just one base but multiple bases (i.e. targets) are possible from what I understand from the documentation. I avoid them because that increases the size of the patch (differences from both bases must be stored in a patch) but it should work if you declare two targets. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Tuesday, June 01, 2010 4:22 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching Base Versions I had a question about whether a feature is supported and haven't seen any WiX documentation that really answers my question. Basically I was curious as to how patches could be installed and supersede each other based on the base used to create the patch. For example if I have Product v1.0.3 directly. I can create a patch for Product v1.0.3 using it as a base and patching to Product v1.0.4. My question is, would I be able to install a patch created using the base Product v1.0.1 which patches to Product v1.0.4, and successfully install it on Product v1.0.3. Currently this is effort is failing with a message saying the program to be upgraded may be missing or the upgrade patch may update a different version of the program. I'm not sure if this is because I have a problem with the patch or if this just isn't supported by WiX. If this is supported by WiX, what would be the best way to go about doing it? Thanks in advance, Big Jim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Base-Versions-tp5127849p5127849.html Sent from the wix-users mailing list archive at Nabble.com. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching Base Versions
Here is one example where you can try insert additional targets (bases) http://schemas.microsoft.com/wix/2006/wi";> http://www.myco.com"; Classification="$(var.CLASSIFICATION)" AllowRemoval="yes" OptimizedInstallMode="yes" /> -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Tuesday, June 01, 2010 4:22 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching Base Versions I had a question about whether a feature is supported and haven't seen any WiX documentation that really answers my question. Basically I was curious as to how patches could be installed and supersede each other based on the base used to create the patch. For example if I have Product v1.0.3 directly. I can create a patch for Product v1.0.3 using it as a base and patching to Product v1.0.4. My question is, would I be able to install a patch created using the base Product v1.0.1 which patches to Product v1.0.4, and successfully install it on Product v1.0.3. Currently this is effort is failing with a message saying the program to be upgraded may be missing or the upgrade patch may update a different version of the program. I'm not sure if this is because I have a problem with the patch or if this just isn't supported by WiX. If this is supported by WiX, what would be the best way to go about doing it? Thanks in advance, Big Jim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Base-Versions-tp5127849p5127849.html Sent from the wix-users mailing list archive at Nabble.com. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Do UFOs visit Install land?
Thanks Sascha! So far we had 40 users with vcredist_x86.exe install problem. All Windows 7 but not only 64 bit. It is interesting, but not yet enlightening to me, how some issues got solved. Quite a few users run vcredist_x86.exe manually, with full UI. Normally it is run silently by our setup chainer. Several users could install after following a rather strange suggestion that I found googling: make user the owner of Components Registry hive. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Friday, May 28, 2010 2:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Do UFOs visit Install land? We define _USE_RTM_VERSION when compiling all custom actions (well, our lone CA) and include the following MS merge modules ... haven't come across any issues to date with many thousands of customers... although we might just be lucky ;) Sascha TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C++ Dependency Help
As a long-time temporary setup guy I do help 'my' developers by loading exes and dlls in VS2008 and opening their manifests. I check module dependencies and tell devs if something is wrong. For example, normally (unless mandated by a binary third-party component) we don't want both 8 and 9 versions of CRT or MFC, but prefer to use just version 9. After that it is up to them to know how to compile correctly. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, June 09, 2010 9:16 AM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C++ Dependency Help I hadn't seen your post and didn't know about sxstrace. I've googled it and it looks like sxstrace isn't available on XP/2003 which just happens to be the platforms we are deploying on. Awesome! I'm starting to think my "setup guy" answer should be "We deploy the latest 2005 and 2008 C++ redists using Microsoft installers. It's up to you to compile your DLL's correctly to find them." Anyone disagree with that philosophy? - Original Message From: "kelly.le...@milliman.com" To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Sent: Tue, June 8, 2010 10:18:13 PM Subject: Re: [WiX-users] C++ Dependency Help I'll repeat it again, in case it got missed earlier. I'd recommend looking at the output of sxstrace to see why it's not locating the assemblies you expect. That should be enlightening. I'd expect it to tell you exactly where it looked and why it didn't find what it was looking for (including what exact versions and such it was searching for). Kelly "Wilson, Phil" 06/08/2010 05:08 PM Please respond to "General discussion for Windows Installer XML toolset." To General discussion for Windows Installer XML toolset. cc Subject Re: [WiX-users] C++ Dependency Help It's really a bit worse than that! What's in the manifest in the program is useful, but if there's a policy manifest in WinSxS that redirects it, beware of that. I believe that the VC Redists will install policy manifests that redirect callers up to the latest. If you install using merge modules you may or may not have included the policy merge modules. For example on my Server 2003 system I have this for the VC80 runtime in a policy file: Phil Wilson -Original Message- From: gree...@cox.net [mailto:gree...@cox.net] Sent: Tuesday, June 08, 2010 10:57 AM To: General discussion for Windows Installer XML toolset. Cc: Wilson, Phil Subject: Re: [WiX-users] C++ Dependency Help I would only add dependencies in the manifest for immediate dependencies only . Don't add dependencies for B to A. For the mixed mode C++ dlls, they'l depend on their .NET assemblies they consume along with the version of the C/C++ runtime that their flavor of Visual Studio depends on. For mixed mode .NET C++, there is always a manifest dependency to the C++ runtime DLL's, there is no static linking to the C++ runtime. Also, it is a Win SxS dependencies. Check the manifest (RT_MANIFEST) resource using the Visual C++ resource editor. Make sure that the C++ runtime you install matches that of the manifest in the .NET DLL (A or B). This is not the .NET manifest, it is a resource inside the DLL. The Win SxS assemblies are native assemblies. I have been burned by this before. You might want to review the MSDN docs on the Win SxS cache. They have been around since Windows XP. They will help out a lot. By looking at the RT_MANIFEST resource embedded in the C++ DLLS, you will find out EXACTLY which Win SxS dlls are being referenced. You may need to add stuff to the manifest for the C++ DLLs for C++ specific stuff. Regards, Aris "Wilson wrote: > If you have a recent version from http://www.dependencywalker.com (at least version 2.2, I think) it handles SxS. > > > Phil Wilson > > > > -Original Message- > From: Christopher Painter [mailto:chr...@deploymentengineering.com] > Sent: Tuesday, June 08, 2010 5:17 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] C++ Dependency Help > > Hmmm, I've not experienced depends / sxs issues in the past so I love to fill in the knowledge gap possibly exposed by that question. And no, all my CA's are written in C# using DTF. > > I'm told the application is broken. I did create a manifest for A.DLL telling it had dependencies of the versions that B.dll had it helped depends to resolve them. I haven't tried doing this in the actual application though. I've also noticed that if I just deploy the unresolved DLL's privately they end up being found. This of course introduces other concerns such as not being able to service those dll's through microsoft hotfixes. Perhaps this is acceptable though? > > My bigge
Re: [WiX-users] Uninstalling patch, requires orginal MSI
Often this happens when versions of the files are not correctly set. That is, your patch contains one file that has changed (i.e. binary comparison will show differences) but version number of dll or exe was not changed. However, if you read install documentation (and some blogs) in depth, you will find out that Microsoft can't guarantee that original MSI won't be required in some cases. For example, the cache allocated for patching is finite in size and if there is not enough space original MSI will be required to get so-called baseline. The safest solution is to have a setup chainer program that copies MSI to a well-known location (the copy that is run from temporary folders usually gets lost after some time) and register it as the alternate source. -Original Message- From: Jason Jibben [mailto:jason_jib...@starkey.com] Sent: Wednesday, July 28, 2010 2:09 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Uninstalling patch, requires orginal MSI Hello fine WiX-Users! Here's my dilemma, I'm testing patch creation with WiX. I take my setup.msi and make a patch (msp) for it. The patch is something simple, such as changing an .ico file. The patch works great. When I uninstall the patch, it prompts for the original MSI. If you target the msi, the patch uninstall works. Using a third-party product, I can make an msp patch that does the same thing, except it doesn't prompt for the original MSI. I also note the WiX msp is about 22kb, and the third-party msp is 117kb. My theory is the third-party msp is bringing a copy of the original .ico file and using it for uninstall. My question: Is there a way to have a pure WiX project that would do the same thing as the third-party msp (Uninstall without requiring the original MSI)? Steps I'm using: Patch.wxs http://schemas.microsoft.com/wix/2006/wi";> http://www.Acme.com/"; DisplayName="Patch A" Description="Small Update Patch" Classification="Update" > >candle Patch.wxs >light Patch.wixobj -out patch.wixmsp Make output dirs >mkdir rtm >mkdir newer >mkdir bin Create Admin image of installer to rtm folder. >msiexec /a "Setup.msi" TARGETDIR=C:\Patch\rtm Copy contents of RTM to Newer folder Make changes to the Install by moving new files (the .ico) into the Newer folder >torch -p -ax bin -xo rtm\Setup.msi newer\Setup.msi -out patch.wixmst >pyro patch.wixmsp -t RTM patch.wixmst -out patch.msp TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to debug CustomAction DLL
Good ole' MessageBox is the most reliable way to debug C/C++ CAs that I found. You may be able to set the breakpoint after the MessageBox and then attach to the running msiexec process. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, August 24, 2010 5:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to debug CustomAction DLL Dear Wix Experts: We have a CustomAction DLL written in C. How to debug it? There are a few posts about it: Post1: http://www.davidmoore.info/2010/06/28/how-to-debug-a-windows-installer-custom-action/ Post2: http://blogs.msdn.com/b/astebner/archive/2005/06/17/430320.aspx Post3: http://msdn.microsoft.com/en-us/library/aa368264(VS.85).aspx I tried it in Windows 7. I did set MsiBreak, but that famous "message box" never showed up. So I tried it in XP, the "message box" showed up. It says "To debug your custom action, attach your debugger to process 5632(0x1600) and press OK". I opened Windbg. Post1 says "attach the process", Post2 says "Open Executable...". I tried both, neither works for me. In both cases, I got "*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll - ntdll!DbgBreakPoint: 7c90120e cc int 3" in Windbg. Questions: 1. What's the problem here? 2. Should I attach process? Or should I "Open Executable..."? 3. If I should attach process, why it doesn't work? 4. If I should "Open Executable...", what the "File name" and "Arguments" fields should be? For example, the "File name" should be "C:\Temp\MyApp.msi" or "C:\Windows\system32\msiexec.exe"? How about arguments? Should it be "/i C:\Temp\MyApp.msi"? 5. Why it doesn't work in Windows 7? If you even debug DLL CustomAction, pls let me know. Thanks! TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Comparison of PatchWiz and WiX v3 Patch Build
Not to discourage you but in early 3.0 versions I have encountered bugs that prevented me from creating binary delta patches with Pyro. Patching the full file was fine. I was too busy to follow up on the bugs or check if they were fixed in later releases so I don't know what is the state right now. I had to settle for patchwiz for the time being. Eventually, I would like to switch to WiX path build since it has more features and will probably be better supported in the future. I don't know if there is any difference in technologies used for creation of binary delta differences. I read that there are two technologies of which the newer one is available on Vista and later. Patchwiz (really mspatcha.dll, I think) has bugs on XP systems that force you to include the entire binary file in many cases. -Original Message- From: Tobi Ha [mailto:tob...@gmx.net] Sent: Tuesday, August 31, 2010 4:52 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Comparison of PatchWiz and WiX v3 Patch Build Hello WiX users, Since I have just read this article http://blogs.msdn.com/b/heaths/archive/2010/08/24/comparison-of-patchwiz-and-wix-v3-patch-build.aspx and I need to create patches I have the question if they is any disadvantage of using the "WiX patching System" (with Pyro) in comparison to the MS patchwiz one? Especially interesting would be if someone stumbled over any limitations where it can not be used? I have searched the mailing list and read several blog post but could not find any limitations, but I may have missed one. As far as I have read from some blog post and the documentation it is also possible to create a patch if the installation (or even "both" installation"?) was not created with WiX. Are they any drawbacks when doing so? Any hints and answers are welcome. Best regards, Tobias -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapping and Burn
Yep. Primadonnas that "just write their glorious code" and expect that somebody else takes care of how it ends up installed on the end user system(s) are more norm than exception. In fact, I can understand that. For example, I wouldn't mind having a dedicated slave to press compile and fix my coding errors button. I could be thinking about the important things in the meantime. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Thursday, September 02, 2010 6:49 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapping and Burn I agree with you Bob except for one problem. I've found so few setup experts who also have the broader application development experience.Too few developers want to specialize in this space. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Bob Arnson To: wix-users@lists.sourceforge.net Sent: Thu, September 2, 2010 7:32:20 AM Subject: Re: [WiX-users] Bootstrapping and Burn On 02-Sep-10 06:13, Pally Sandher wrote: > I have personally fixed things like that myself. Last year one of our dev's >decided to implement the use of CAPICOM for some basic password encryption& >MD5 >checking& thought it was OK to tell me "just self-register the CAPICOM DLL in >the installer& it'll work". He was also recommending we use an out-dated >version of the discontinued CAPICOM containing some known security >vulnerabilities. I re-wrote his code using the CryptoAPI completely removing >the >need for the CAPICOM redistributable. Incidentally he no longer works for us >any >more. > > When the product developers make stupid decisions which impact upon setup >development, call them on it or be prepared to put up with more of the same >until the end of time. This is why it's important for "setup developers" to be developers in their own right, so they can speak with authority and, when necessary, write code outside of setup to "lend a hand." -- sig://boB http://joyofsetup.com/ -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How WiX resolve that file was changed when creates patch
MSI calculates the hash of data files and, if hash is different, patch will update the older file. However, that is only in the case that file creation and modification time&date are identical. When time & date are not identical, MSI assumes that file was touched by the user and won't patch it. Thus I believe that modified file is in the patch, it is just that MSI doesn't apply the patch because of time & date. Verbose log can also confirm this - it is good to do a verbose log of patching process whenever reporting issues in any case. -Original Message- From: Oleksandr Y. Nechyporenko [mailto:alexnc69...@gmail.com] Sent: Friday, September 17, 2010 2:32 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] How WiX resolve that file was changed when creates patch Hello, I've noticed one strange thing. When text file (for example html file) was changed but it's size wasn't changed it will not be included to patch. For example, if I change 2 symbols to other 2 symbols, WiX don't detect that file changed and not include it to patch. Are there way to force binary files compare? I use patch syntax like .. -- Best Regards, Oleksandr Y. Nechyporenko TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How does patching decide which files to include in msp?
These are not WiX rules but MSI rules and are documented on MSDN site, somewhere in install patching section. -Original Message- From: Travis Gaff [mailto:tra...@pc-doctor.com] Sent: Thursday, September 16, 2010 12:48 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How does patching decide which files to include in msp? Hello WiX users, I am trying to construct a .msp file to patch a several hundred file installation. However I am finding that a large number of files are not ending up in the final .msp file. Right now I suspect many of these are due to both the new and the old version of the file having the same version number; we're fixing this. However I have some files that do not have a version number and do have an internal change but are not in the msp. They appear to have little difference from most of the other files, they're all added with individual components to a .wxs by our build system. How does WiX decide which files to include in a patch using the pyro/torch method? By comparing several files I suspect it does the following: 1) if a file has a version number, check it, if same version skip file 2) if file doesn't have version number but there is a size difference: patch it? (I haven't verified this) 3) if no version number AND file is same size: diff the file or use creation date? What rules does WiX use to determine which files should be included in the msp? Background: All components are in 2 features. The 2nd feature is a sub-feature of the first and right now I am not even looking at its 2 shortcuts. The *patch.wxs file includes: (a component of the main feature) (to update the ARP program version) The patch is generated using .wixpdb files with torch and pyro: candle patch.wxs -dcodepage=1252 -ext WiXUtilExtension -dtop_projects_dir=C:\projects light -o out.wixmsp -cultures:en-us -ext WixUIExtension patch.wixobj -ext WiXNetFxExtension -ext WiXUtilExtension -dtop_projects_dir=C:\projects torch -t patch -p -pedantic -xi build1.wixpdb build2.wixpdb -out out.mst pyro out.wixmsp -out out.msp -t patch out1.mst I am using 3.5.1916.0, however I had similar issues in 3.0. Thank you for any help you can offer. Travis Gaff, Software Engineer PC-Doctor, Inc. 9805 Double R Boulevard, Suite 301 Reno, NV 89521 CONFIDENTIALITY The information contained in this message is confidential. It is intended to be read only by the individual or entity to whom it is addressed or by an authorized designee. If the reader of this message is not the intended recipient, be aware that distribution of this message in any form is strictly prohibited. If you have received this message in error, please immediately notify the sender and destroy any copy of this message. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How does patching decide which files to include in msp?
It may be a problem with a 'new' WiX patching, as opposed to WiX patching that is just a wrapper around the legacy PatchWiz.dll. I think I encountered similar issues in the past and decided to stick with PatchWiz.dll for the time being. Except for bugs in Windows XP versions (and these seem to be patch application, or MSPatcha.dll versions for XP, bugs) my experience is that PatchWiz.dll processes small binary differences well enough to be useful. -Original Message- From: Travis Gaff [mailto:tra...@pc-doctor.com] Sent: Friday, September 17, 2010 7:49 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does patching decide which files to include in msp? Thanks for the reply. Just to be clear this is not an install time issue in which certain files are not updated because their modification times have changed. I am able to extract the .msp file immediately after creation and confirm that files are not included that I wish to include. Applying the patch in Orca shows the same issues. It looks like this is occurring at the patch assembly level. -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Friday, September 17, 2010 3:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How does patching decide which files to include in msp? These are not WiX rules but MSI rules and are documented on MSDN site, somewhere in install patching section. -Original Message- From: Travis Gaff [mailto:tra...@pc-doctor.com] Sent: Thursday, September 16, 2010 12:48 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How does patching decide which files to include in msp? Hello WiX users, I am trying to construct a .msp file to patch a several hundred file installation. However I am finding that a large number of files are not ending up in the final .msp file. Right now I suspect many of these are due to both the new and the old version of the file having the same version number; we're fixing this. However I have some files that do not have a version number and do have an internal change but are not in the msp. They appear to have little difference from most of the other files, they're all added with individual components to a .wxs by our build system. How does WiX decide which files to include in a patch using the pyro/torch method? By comparing several files I suspect it does the following: 1) if a file has a version number, check it, if same version skip file 2) if file doesn't have version number but there is a size difference: patch it? (I haven't verified this) 3) if no version number AND file is same size: diff the file or use creation date? What rules does WiX use to determine which files should be included in the msp? Background: All components are in 2 features. The 2nd feature is a sub-feature of the first and right now I am not even looking at its 2 shortcuts. The *patch.wxs file includes: (a component of the main feature) (to update the ARP program version) The patch is generated using .wixpdb files with torch and pyro: candle patch.wxs -dcodepage=1252 -ext WiXUtilExtension -dtop_projects_dir=C:\projects light -o out.wixmsp -cultures:en-us -ext WixUIExtension patch.wixobj -ext WiXNetFxExtension -ext WiXUtilExtension -dtop_projects_dir=C:\projects torch -t patch -p -pedantic -xi build1.wixpdb build2.wixpdb -out out.mst pyro out.wixmsp -out out.msp -t patch out1.mst I am using 3.5.1916.0, however I had similar issues in 3.0. Thank you for any help you can offer. Travis Gaff, Software Engineer PC-Doctor, Inc. 9805 Double R Boulevard, Suite 301 Reno, NV 89521 CONFIDENTIALITY The information contained in this message is confidential. It is intended to be read only by the individual or entity to whom it is addressed or by an authorized designee. If the reader of this message is not the intended recipient, be aware that distribution of this message in any form is strictly prohibited. If you have received this message in error, please immediately notify the sender and destroy any copy of this message. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibite
Re: [WiX-users] How does patching decide which files to includein msp?
Yeah, I feel bad too. I mailed some initial trials errors to Peter Marcu and never found the time to investigate in more details and file an official bug report. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Thursday, September 23, 2010 5:31 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How does patching decide which files to includein msp? In my defence Bob I wrote my patching code when I was using WiX 2.0 thus the only method available to me was the PatchWiz method. When I moved over to using WiX 3.0 I looked at the Pyro method as the idea of using purely WiX appealed but as time isn't infinite when software releases are concerned I had to go with what I had already working. Palbinder Sandher Software Deployment & IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the ** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 23 September 2010 01:52 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How does patching decide which files to includein msp? On 20-Sep-10 06:44, Pally Sandher wrote: > IIRC I had similar issues when attempting to create patches using the > Pyro method in WiX 3.0 hence I've stuck with the PatchWiz method. I'm > sure if I stuck at it I could probably work out what's going wrong > when I try using the Pyro method but since I have a method which works > there's not much incentive. And without bug reports, it's hard finding and fixing bugs. > Travis have you tried using the PatchWiz method? It's described in the > WiX.chm (you'll require the Windows SDK installed to get the required > tools which is freely downloadable from microsoft.com). You may find > it works more reliably than the Pyro method for your situation. Until it doesn't and PatchWiz error messages are useless for diagnosing the problem... -- sig://boB http://joyofsetup.com/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Microsoft retires Visual Studio Installer and announces InstallShield a choice solution
Just found out that Microsoft is retiring current installer and this quote: "InstallShield 2011 should be an installation development environment of choice for Visual Studio users, ensuring that Visual Studio applications of any kind can be professionally installed and work with the latest Microsoft technologies and platforms." Jason Zander Corporate Vice President of Visual Studio - Microsoft I thought WiX would be a choice solution :( TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Random patching failures - pesky error 1328
For a while patching errors like: MSI (s) (28:48) [13:52:25:298]: Product: MyProduct -- Error 1328. Error applying patch to file C:\Config.Msi\PTCCC8.tmp. It has probably been updated by other means, and can no longer be modified by this patch. For more information contact your patch vendor. System Error: -1072807676 appeared only in XP installations which has a buggy MSPATCHA.DLL. The same patch would succeed on Vista and Windows 7, for example. Copying MSPATCHA,.DLL from Visa to XP would make patching succeed on XP too, therefore making it quite clear that the cause is indeed a bug in patch application dll. I managed to fix my XP users by including the entire offending file in the patch. However now I am getting the reports of the same problem on Windows 7 too. What makes matters worse is that it doesn't happen for one specific file, like it used on XP, but many different files were reported. Reinstalling the application from scratch and then applying the patch fixes the problem - the same patch that previously failed with error 1328 now succeeds. Naturally, this 'fix' drives customers pretty mad. Any similar experiences recently with Windows 7? Some people believe that patching issues started after one of Windows system updates. If I have to include each and every file in its entirety, that kills the motivation to use this update system in the first place. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX v3.5 released!
Yey!!! -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, January 31, 2011 10:07 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WiX v3.5 released! WiX v3.5 Released! Tell your friends. Read more here: http://bit.ly/wix35 -- virtually, Rob Mensching - http://RobMensching.com LLC TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Versioning interop assemblies for patching
In this particular case I am not interested in setting Company Name and version number for my interop assemblies (that is, files generated using tlbimp) just so that the name is not an empty string and that the version is not 1.0.0.0. In order to have un-installable patches I need assembly file version numbers to change whenever the code changes. How are other developers handling this problem? Are you just praying that you never have to patch interop assembly or have you settled for solution as explained here: http://blogs.msdn.com/ianhu/archive/2005/06/16/429903.aspx I there any better, newer solution? As a matter of fact, I could not get the solution described at the blog link above to work because ilasm.exe from MS SDKs just won't run without fusion.dll. I have a bunch of fusion dlls installed in SxS (a new Hell after DLL Hell) but, really, does anybody in this century even run ilasm.exe anymore? If you do, please help! TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question on Patching Mechanism - Patching checks all files copied during installation
One thing that you may try is the following: 1) put all the files that may get deleted inside their own component 2) Do not set any Guid for that component Windows Installer will ignore these files when it comes to patching so you will never be able to upgrade/downgrade them via patching mechanism, but they will get installed. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patch will not cache baseline or what is so special about interop assembles?
I have an interop assembly that breaks my patching. When patch is installed verbose log shows this: MSI (s) (78:E8) [16:12:06:987]: Baseline: INTEROP.SERVICELIB.DLL not touched in this transaction, verification required. MSI (s) (78:E8) [16:12:06:989]: Baseline: Existing INTEROP.SERVICELIB.DLL version 5.30.2.52 does not match any baseline. Will not be cached. There is no previous info in the log showing that this file is treated any differently than the other files that get cached. The information at Heath Stewart's Blog : http://blogs.msdn.com/heaths/archive/2006/12/08/source-resolution-during-patch-uninstall.aspx doesn't seem to apply to explain this case because this assembly is not installed in GAC and there are no corresponding MsiAssembly and MsiAssemblyName tables. Since the assembly gets created from the type library, in the beginning I thought the problem is simple and due to the resource version which was always set to 1.0.0.0, even if the code got changed. I fixed this by running the utility that updated file and product version resource after assembly was created. That didn't help. Then I realized that, even if I changed file and product version resource, the assembly version was still fixed at 1.0.0.0 in both RTM and QFE builds. Ok, that got fixed too with the little utility that invokes ildasm and, after editing the manifest version part ilasm. But that didn't help either. MSI insists on not caching the file. So my question is how can I understand what is making MSI treat this assembly so differently? There are no such problems with .NET assemblies that are not interop, but are built from C# source code. If I decide to provide the RTM source MSI, that will fix my current problem with uninstalling QFE1 patch and going back to RTM. But will I be able to apply and remove multiple patches of this assembly? What about dropping from QFE2 to QFE1 if MSI doesn't feel like caching anything about this assembly? TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Creating database table via DTF - SQL syntax
This is probably not DTF specific issue. I have code to add a table to MSP file:
using (Database db = new Database(file, DatabaseOpenMode.Transact))
{
ColumnInfo[] arrc = new ColumnInfo[2]
{
new ColumnInfo("Key", typeof(string), 32, true),
new ColumnInfo("Value", typeof(string), 256, false)
};
List pk = new List() { "Key" };
TableInfo ti = new TableInfo("_MyTable", arrc, pk);
db.Tables.Add(ti);
db.Commit();
}
This code throws exception:
Microsoft.Deployment.WindowsInstaller.BadQuerySyntaxException: SQL query syntax
invalid or unsupported. Database:
Invalid or missing query string: CREATE TABLE `_MyTable` (`Key` CHAR(32) NOT
NULL, `Value` CHAR(256) PRIMARY KEY `Key`).
My problem is that I am unable to see what is wrong with this query. It seems
fine according to this spec:
http://msdn.microsoft.com/en-us/library/aa372021(VS.85).aspx
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these companies provides
trading or investment advice, recommendations or endorsements of any kind. The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating database table via DTF - SQL syntax
It was the length of the string in second 'Value' column - it must be at most
255 characters.
-Original Message-----
From: Tony Juricic
Sent: Tuesday, September 01, 2009 2:09 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Creating database table via DTF - SQL syntax
This is probably not DTF specific issue. I have code to add a table to MSP file:
using (Database db = new Database(file, DatabaseOpenMode.Transact))
{
ColumnInfo[] arrc = new ColumnInfo[2]
{
new ColumnInfo("Key", typeof(string), 32, true),
new ColumnInfo("Value", typeof(string), 256, false)
};
List pk = new List() { "Key" };
TableInfo ti = new TableInfo("_MyTable", arrc, pk);
db.Tables.Add(ti);
db.Commit();
}
This code throws exception:
Microsoft.Deployment.WindowsInstaller.BadQuerySyntaxException: SQL query syntax
invalid or unsupported. Database:
Invalid or missing query string: CREATE TABLE `_MyTable` (`Key` CHAR(32) NOT
NULL, `Value` CHAR(256) PRIMARY KEY `Key`).
My problem is that I am unable to see what is wrong with this query. It seems
fine according to this spec:
http://msdn.microsoft.com/en-us/library/aa372021(VS.85).aspx
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these companies provides
trading or investment advice, recommendations or endorsements of any kind. The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer.
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these companies provides
trading or investment advice, recommendations or endorsements of any kind. The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patch failure on XP that doesn't happen on Vista
Applying the patch on one XP system produces the following error log for one file (edited here to shorten the path to MYFILE.EXE): MSI (s) (74:4C) [17:23:03:041]: Executing op: CacheBaselineFile(Baseline=0,FileKey=MYFILE.EXE,FilePath=C:\Program Files\..\ MYFILE.EXE,,Existing=0) MSI (s) (74:4C) [17:23:03:103]: Executing op: PatchApply(PatchName= MYFILE.EXE,TargetName=C:\Program Files\..\ MYFILE.EXE,PatchSize=6113,TargetSize=1001984,PerTick=0,,FileAttributes=512,PatchAttributes=0,CheckCRC=0) MSI (s) (74:4C) [17:23:03:135]: Re-applying security from existing file. MSI (s) (74:4C) [17:23:03:197]: Note: 1: 2318 2: C:\Config.Msi\PF4D1.tmp MSI (s) (74:4C) [17:23:03:244]: Note: 1: 2302 2: 0 MSI (s) (74:4C) [17:23:03:338]: Note: 1: 1328 2: C:\Program Files\... MYFILE.EXE 3: -1072807676 MSI (s) (74:4C) [17:23:03:400]: Note: 1: 2205 2: 3: Error MSI (s) (74:4C) [17:23:03:463]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1328 MSI (s) (74:4C) [17:23:03:494]: Note: 1: 2205 2: 3: Error MSI (s) (74:4C) [17:23:03:541]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (74:4C) [17:23:03:619]: Product: MYProd Error 1328. Error applying patch to file C:\Program Files\..\ MYFILE.EXE . It has probably been updated by other means, and can no longer be modified by this patch. For more information contact your patch vendor. System Error: -1072807676 However, applying the same patch on the same RTM on Vista computer works without any trouble. What more can I do to attempt to diagnose the source of the problem? TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
Hi Blair, Actually, the files are not bit-for-bit the same. The error message is probably too generic and misleading in this case. In the case of this particular file there are no changes in code and the only difference is in version resource which has 4-th version number different from the RTM version. IMO, that explains why PatchSize=6113,TargetSize=100198. This is nothing unusual considering the build system that I am using, which increments 4-th version number with each new build. Quite a few other files have the same differences - just version resource - and they don't exhibit this problem. I build MSP on Server 2003 system with MSI version 3.01.4000.3959 and I create only Release build patches. It seems that patch application MSI version is more important than the build system MSI version since patch applies without a glitch on Vista with version V 4.5.6002.18005 MSI, while it fails on XP with MSI components version 3.01. I guess I would have to enforce both build and application MSI versions to be the same (meaning I'll have to install 4.5 MSI on XP machines before staring install and patching process), but at this time it is just a guess. Thanks, Tony -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 01, 2009 6:20 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I assumed you verified that the files are bit-for-bit the same before attempting to apply the patch. Do you build your MSP on a Vista/Server 2008 system? We saw this one time and it happened only with Release (not Debug) for just one file, but didn't happen when building on XP/32-bit (I never investigated building on either 64-bit XP or Server 2003). Our products were not allowed on Server OSs but we did our official builds on them. It seems that the PatchAPI binaries (described here: http://msdn.microsoft.com/en-us/library/bb417345.aspx) are somehow different and the Patch Apply routines are somehow sometimes different between platforms. For a workaround we had to mark that one file as "whole file" instead of delta. It didn't happen every build, but it did happen for about two months around one of our major releases. -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 2:56 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patch failure on XP that doesn't happen on Vista Applying the patch on one XP system produces the following error log for one file (edited here to shorten the path to MYFILE.EXE): MSI (s) (74:4C) [17:23:03:041]: Executing op: CacheBaselineFile(Baseline=0,FileKey=MYFILE.EXE,FilePath=C:\Program Files\..\ MYFILE.EXE,,Existing=0) MSI (s) (74:4C) [17:23:03:103]: Executing op: PatchApply(PatchName= MYFILE.EXE,TargetName=C:\Program Files\..\ MYFILE.EXE,PatchSize=6113,TargetSize=1001984,PerTick=0,,FileAttributes=512,P atchAttributes=0,CheckCRC=0) MSI (s) (74:4C) [17:23:03:135]: Re-applying security from existing file. MSI (s) (74:4C) [17:23:03:197]: Note: 1: 2318 2: C:\Config.Msi\PF4D1.tmp MSI (s) (74:4C) [17:23:03:244]: Note: 1: 2302 2: 0 MSI (s) (74:4C) [17:23:03:338]: Note: 1: 1328 2: C:\Program Files\... MYFILE.EXE 3: -1072807676 MSI (s) (74:4C) [17:23:03:400]: Note: 1: 2205 2: 3: Error MSI (s) (74:4C) [17:23:03:463]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1328 MSI (s) (74:4C) [17:23:03:494]: Note: 1: 2205 2: 3: Error MSI (s) (74:4C) [17:23:03:541]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (74:4C) [17:23:03:619]: Product: MYProd Error 1328. Error applying patch to file C:\Program Files\..\ MYFILE.EXE . It has probably been updated by other means, and can no longer be modified by this patch. For more information contact your patch vendor. System Error: -1072807676 However, applying the same patch on the same RTM on Vista computer works without any trouble. What more can I do to attempt to diagnose the source of the problem? TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact th
Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
I am using PatchWiz. Also, I am afraid I don't understand if I should use IgnoreRange, if I could do it with PatchWiz. On XP the patching system thinks that file has been already patched which is simply wrong, even if the difference is probably only in version resource part of the file. It also aborts the patching process and rolls back all the changes. I can't patch the entire system anymore because of this error. I would rather see the same behavior as in Vista where the same file gets patched and I see it got a new version when looking at its properties in Explorer. Thus I am thinking either play with installer versions, of which XP one appears to be buggy, or take your suggestion to include the entire file in the patch, rather than using differences. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:13 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista TargetFile\IgnoreRange element(s) are "intended" for exactly your scenario (you tell the system one or more sections of the binary that "don't matter" for it to be able to assert that the file is the same before applying the patch it). If you are using Pyro instead of PatchWiz, the IgnoreRange element goes under the File element in building your "Updated" image (it seems to be missing from the schema/help doc). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 6:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Hi Blair, Actually, the files are not bit-for-bit the same. The error message is probably too generic and misleading in this case. In the case of this particular file there are no changes in code and the only difference is in version resource which has 4-th version number different from the RTM version. IMO, that explains why PatchSize=6113,TargetSize=100198. This is nothing unusual considering the build system that I am using, which increments 4-th version number with each new build. Quite a few other files have the same differences - just version resource - and they don't exhibit this problem. I build MSP on Server 2003 system with MSI version 3.01.4000.3959 and I create only Release build patches. It seems that patch application MSI version is more important than the build system MSI version since patch applies without a glitch on Vista with version V 4.5.6002.18005 MSI, while it fails on XP with MSI components version 3.01. I guess I would have to enforce both build and application MSI versions to be the same (meaning I'll have to install 4.5 MSI on XP machines before staring install and patching process), but at this time it is just a guess. Thanks, Tony -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 01, 2009 6:20 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I assumed you verified that the files are bit-for-bit the same before attempting to apply the patch. Do you build your MSP on a Vista/Server 2008 system? We saw this one time and it happened only with Release (not Debug) for just one file, but didn't happen when building on XP/32-bit (I never investigated building on either 64-bit XP or Server 2003). Our products were not allowed on Server OSs but we did our official builds on them. It seems that the PatchAPI binaries (described here: http://msdn.microsoft.com/en-us/library/bb417345.aspx) are somehow different and the Patch Apply routines are somehow sometimes different between platforms. For a workaround we had to mark that one file as "whole file" instead of delta. It didn't happen every build, but it did happen for about two months around one of our major releases. -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 2:56 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patch failure on XP that doesn't happen on Vista Applying the patch on one XP system produces the following error log for one file (edited here to shorten the path to MYFILE.EXE): MSI (s) (74:4C) [17:23:03:041]: Executing op: CacheBaselineFile(Baseline=0,FileKey=MYFILE.EXE,FilePath=C:\Program Files\..\ MYFILE.EXE,,Existing=0) MSI (s) (74:4C) [17:23:03:103]: Executing op: PatchApply(PatchName= MYFILE.EXE,TargetName=C:\Program Files\..\ MYFILE.EXE,PatchSize=6113,TargetSize=1001984,PerTick=0,,FileAttributes=512,P atchAttributes=0,CheckCRC=0) MSI (s) (74:4C) [17:23:03:135]: Re-applying security from existing file. MSI (s) (74:4C) [17:23:03:197]: Note: 1: 2318 2: C:\Config.Msi\PF4D1.tmp MSI (s) (74:4C) [17:23:03:244]: Note: 1: 2302 2
Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
I tried installing Windows Installer version 4.5 on XP machine but that didn't fix the problem. What fixed it is quite scary because of the hacky method that was used. In short, copying Vista version 6.0 of MSPATCHA.DLL (from System32 folder) to XP, which had version 5.1 of it, made patching succeed as it did on Vista machine. The file that previously crashed the patching process before was now correctly patched and as the result had a new version. However, MSPATCHA.DLL is a protected DLL and I had to disable XP file system protection in order to install newer Vista version 6.0. This means changing Registry value while kernel debugger is attached via null modem cable. Clearly, this is no way that I can fix the issue on customer's XP machines. I feel that Microsoft should provide a safe way of updating buggy MSPATCHA.DLL on XP machines. -Original Message----- From: Tony Juricic Sent: Wednesday, September 02, 2009 7:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I am using PatchWiz. Also, I am afraid I don't understand if I should use IgnoreRange, if I could do it with PatchWiz. On XP the patching system thinks that file has been already patched which is simply wrong, even if the difference is probably only in version resource part of the file. It also aborts the patching process and rolls back all the changes. I can't patch the entire system anymore because of this error. I would rather see the same behavior as in Vista where the same file gets patched and I see it got a new version when looking at its properties in Explorer. Thus I am thinking either play with installer versions, of which XP one appears to be buggy, or take your suggestion to include the entire file in the patch, rather than using differences. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:13 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista TargetFile\IgnoreRange element(s) are "intended" for exactly your scenario (you tell the system one or more sections of the binary that "don't matter" for it to be able to assert that the file is the same before applying the patch it). If you are using Pyro instead of PatchWiz, the IgnoreRange element goes under the File element in building your "Updated" image (it seems to be missing from the schema/help doc). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 6:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Hi Blair, Actually, the files are not bit-for-bit the same. The error message is probably too generic and misleading in this case. In the case of this particular file there are no changes in code and the only difference is in version resource which has 4-th version number different from the RTM version. IMO, that explains why PatchSize=6113,TargetSize=100198. This is nothing unusual considering the build system that I am using, which increments 4-th version number with each new build. Quite a few other files have the same differences - just version resource - and they don't exhibit this problem. I build MSP on Server 2003 system with MSI version 3.01.4000.3959 and I create only Release build patches. It seems that patch application MSI version is more important than the build system MSI version since patch applies without a glitch on Vista with version V 4.5.6002.18005 MSI, while it fails on XP with MSI components version 3.01. I guess I would have to enforce both build and application MSI versions to be the same (meaning I'll have to install 4.5 MSI on XP machines before staring install and patching process), but at this time it is just a guess. Thanks, Tony -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 01, 2009 6:20 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I assumed you verified that the files are bit-for-bit the same before attempting to apply the patch. Do you build your MSP on a Vista/Server 2008 system? We saw this one time and it happened only with Release (not Debug) for just one file, but didn't happen when building on XP/32-bit (I never investigated building on either 64-bit XP or Server 2003). Our products were not allowed on Server OSs but we did our official builds on them. It seems that the PatchAPI binaries (described here: http://msdn.microsoft.com/en-us/library/bb417345.aspx) are somehow different and the Patch Apply routines are somehow sometimes different between platforms. For a workaround we h
Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
I will try that. However, the sole reason for my using MSPATCHC.DLL 6.0 was because PatchWiz.dll version before 4.0 had other patching problems which were reported to be solved by PatchWiz.dll version 4.0 and above. So I used SDK 6.0 version of PatchWiz.dll which is 4.0 and it comes with 6.0 version of MSPATCHC.DLL. So, should I use PatchWiz.dll 4.0 and above with MSPATCHC.DLL 5.1 and hope for the best? Apparently, Microsoft considers that they have no responsibility to document, explain, fix or support any of these issues. Where was the testing? If I can break patching just in a few builds that mostly change version resources, how reliable was testing of that software? The message seems to be: It is up to you, dear foolish Microsoft developer, to try and use our patch/differencing/compression system, and if you end up in trouble there is nobody who gives a damn. Experiment and try this or that. Maybe it works, maybe it doesn't. Microsoft developers who developed this system and their managers feel no obligation to provide any support or guidance. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 4:52 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Alternately try building with version 5.1 of MSPATCHC.DLL (by building on an XP box?). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Wednesday, September 02, 2009 1:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I tried installing Windows Installer version 4.5 on XP machine but that didn't fix the problem. What fixed it is quite scary because of the hacky method that was used. In short, copying Vista version 6.0 of MSPATCHA.DLL (from System32 folder) to XP, which had version 5.1 of it, made patching succeed as it did on Vista machine. The file that previously crashed the patching process before was now correctly patched and as the result had a new version. However, MSPATCHA.DLL is a protected DLL and I had to disable XP file system protection in order to install newer Vista version 6.0. This means changing Registry value while kernel debugger is attached via null modem cable. Clearly, this is no way that I can fix the issue on customer's XP machines. I feel that Microsoft should provide a safe way of updating buggy MSPATCHA.DLL on XP machines. -----Original Message- From: Tony Juricic Sent: Wednesday, September 02, 2009 7:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I am using PatchWiz. Also, I am afraid I don't understand if I should use IgnoreRange, if I could do it with PatchWiz. On XP the patching system thinks that file has been already patched which is simply wrong, even if the difference is probably only in version resource part of the file. It also aborts the patching process and rolls back all the changes. I can't patch the entire system anymore because of this error. I would rather see the same behavior as in Vista where the same file gets patched and I see it got a new version when looking at its properties in Explorer. Thus I am thinking either play with installer versions, of which XP one appears to be buggy, or take your suggestion to include the entire file in the patch, rather than using differences. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:13 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista TargetFile\IgnoreRange element(s) are "intended" for exactly your scenario (you tell the system one or more sections of the binary that "don't matter" for it to be able to assert that the file is the same before applying the patch it). If you are using Pyro instead of PatchWiz, the IgnoreRange element goes under the File element in building your "Updated" image (it seems to be missing from the schema/help doc). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 6:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Hi Blair, Actually, the files are not bit-for-bit the same. The error message is probably too generic and misleading in this case. In the case of this particular file there are no changes in code and the only difference is in version resource which has 4-th version number different from the RTM version. IMO, that explains why PatchSize=6113,TargetSize=100198. This is nothing unusual considering the build system that I am using, which increments
Re: [WiX-users] Problem installing patch
Try verbose log to see which file has a problem. Use command line like: msiexec /update "mypatch path\MyPatch.msp" /lv*x .\Patch.log Then in the log you will find the entry saying that local source for some file can't be resolved and that it is trying to find the original MSI. In my case problems of this sort typically occurred when executable file was changed because code was changed, but the version has not been updated to reflect that. If it not executable but data file, you should probably set creation and modification date of them to be the same before they get packed into MSI. Distant possibility is that you have run out of the disk space allocated for caching MSI and patches. I have not encountered this problem yet but I fear it may appear one of these days forcing me to use bootstrapper to copy MSI to a known location, call install from there and leave MSI on drive. -Original Message- From: Oivind [mailto:oivind.fla...@visma.com] Sent: Thursday, September 17, 2009 9:33 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem installing patch Finally after a lot of struggling I succeed to make my patch ready and installable. I do have a problem when the original setup for my product is not avaiable during the installation of the patch. Does anyone know if it's possible to install a patch without claiming access to the original MSI file for the product? Thanks in advance. Oivind -- View this message in context: http://n2.nabble.com/Problem-installing-patch-tp3662824p3662824.html Sent from the wix-users mailing list archive at Nabble.com. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem installing patch
Also check that component rules are not broken (it can take time understanding them well): http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101 http://msdn.microsoft.com/en-us/library/aa372795(VS.85).aspx -Original Message- From: Oivind [mailto:oivind.fla...@visma.com] Sent: Thursday, September 17, 2009 9:33 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem installing patch Finally after a lot of struggling I succeed to make my patch ready and installable. I do have a problem when the original setup for my product is not avaiable during the installation of the patch. Does anyone know if it's possible to install a patch without claiming access to the original MSI file for the product? Thanks in advance. Oivind -- View this message in context: http://n2.nabble.com/Problem-installing-patch-tp3662755p3662755.html Sent from the wix-users mailing list archive at Nabble.com. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Does WcaLog parse square brackets in some special way?
Having this log entry in my C++ custom action: LPCWSTR cause = L"Something is [funky] here"; ::WcaLog(LOGMSG_STANDARD, "[MYLOG] program failed because %S", cause); This is the log that I get: "program failed because Something is here" TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] So how does one run installed executable after the install finishes?
While there are quite a few samples of appropriate Custom Action (including
some posted here) none of them work for me. I either get an error code 1631 or
no error code (see log example below where it appears that app was launched ok)
but I see no application UI (it is a WPF app).
Is there some definitive reference for this?
I would prefer immediate action but it appears it must be deferred. Thus
calling this CA in Finish button Publish in Exit Dialog seems excluded.
Some people still recommend setting manifest to require administrator rights,
some people think it does not matter.
Alex Shevchuk blog sample of Custom Action Type 18 seems to fit the bill but
results in no UI.
This means that I've put System.Windows.MessageBox.Show("Starting") in
app_Startup event of WPF app and I never get to see it.
Log extract:
Action 18:48:29: CA_MYAction.
MSI (s) (DC:BC) [18:48:29:453]: Executing op: CustomActionSchedule(Action=
CA_MYAction,ActionType=3282,Source=C:\Program
Files\TestAction\Action.exe,Target=/install,)
MSI (s) (DC:BC) [18:48:29:454]: Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing Product
Features,Template=Feature: [1])
Action 18:48:29: PublishFeatures. Publishing Product Features
...
PublishFeatures: Feature:All
1: CA_MYAction 2: 0
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these companies provides
trading or investment advice, recommendations or endorsements of any kind. The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] So how does one run installed executable after the install finishes?
It gets worse. Even if app is not a WPF app (or a .NET app), it is really not correct, regarding the expected UI, to run deferred action launching an exe as the part of InstallExecuteSequence, like: ... What happens is that executable is run but Exit Dialog sits there, waiting for user to press Finish button. Expected UI is that user presses Finish button and then installed executable is run. Running exes like NOTEPAD that were found during file search like: works just fine when used in a custom action called when user clicks Finish button. The problem is doing the same with (.NET) app that was just installed. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Tuesday, November 10, 2009 8:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] So how does one run installed executable after the install finishes? Tony Juricic wrote: > While there are quite a few samples of appropriate Custom Action (including > some posted here) none of them work for me. I either get an error code 1631 > or no error code (see log example below where it appears that app was > launched ok) but I see no application UI (it is a WPF app). > > Is there some definitive reference for this? > > I would prefer immediate action but it appears it must be deferred. I'd consider it unlikely that you can run a WPF app from a deferred custom action service. > FileKey="ACTION.EXE" ExeCommand="/install" Execute="deferred" > Return="asyncNoWait" /> > -- sig://boB http://joyofsetup.com/ TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to find which files cause patch to force the reboot?
I have verbose log and this is all the extra info that I find about the cause of the reboot: MSI (s) (4C:E8) [18:33:27:219]: RESTART MANAGER: Did detect that the client process of this installation holds file[s] in use, so a reboot will be necessary. Is there any way to find out which files MSI sees as being in use? My program is definitely not running as I can see in Task Manager. Message that is displayed in a MessageBox is not much more informative. I hoped to see the list of files in use but instead I just get this generic message saying: The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup. Reboot that ensues does not even give user the option (as normally happens otherwise) to close open applications. I have applied quite few patches so far and this problem did not occur. It started with the latest patch application and I am quite at loss, after making sure that my program is not running, what could have suddenly caused MSI to see it as holding files open. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Updating registry during Install/UnInstall/Change
Post log excerpts. I have an opposite issue. I have to force REINSTALLMODE="o" to *AVOID* Registry from being updated with original values. However, for me Change leads to either Repair or Uninstall. I don't really know what just Change by itself means or does. Repair should definitely restore Registry value that was set during the original installation. -Original Message- From: Vidya Kukke [mailto:vku...@microsoft.com] Sent: Tuesday, November 24, 2009 9:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Updating registry during Install/UnInstall/Change Anyone? -Original Message- From: Vidya Kukke [mailto:vku...@microsoft.com] Sent: Friday, November 20, 2009 11:44 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Updating registry during Install/UnInstall/Change Hi, My scenario needs to create/update registry values on Install/Change. My code to create the registry is:- The registry is created on install with the value of MYPUBLICPROP. However after install, if I choose 'Change' to update the public property the registry value is not updated. From the logs it appears that the Component at that point is considered as already installed and hence the registry value is not updated. What should I be doing to be able to update registry during Change? Any help is much appreciated. Thanks Vidya -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Two Custom Action entry points in one C++ Dll and WcaLog failure
At one point I was thinking that I have too many C++ Custom Action Dlls and started using existing Dlls. That is, I added a new entry point for a new CA in a Dll that already hosted code for existing CA. That appears to work just fine except for one issue: WcaLog() doesn't work - nothing gets output in a log! I don't know if the fact that I have 2 CA and 2 entry points in this DLL is relevant, but this is the only case where WcaLog doesn't work. I am using calls like: ::WcaLog(LOGMSG_STANDARD, "Install folder %S created.", Path); so there is hardly anything mysterious here that can fail when many similar calls in many other CA Dlls work. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Two Custom Action entry points in one C++ Dll and WcaLog failure
I verified that WcaInitialize() is called. This is immediate CA that is the target of a control event : 1 Is logging available to such custom actions? Thanks! -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Tuesday, December 08, 2009 12:05 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Two Custom Action entry points in one C++ Dll and WcaLog failure The WiX toolset has plenty of custom actions that are combined in the same DLL. Something else is wrong. Did you call WcaIitialize() at the beginning of each custom action? Is this custom action the target of a control event? On Mon, Dec 7, 2009 at 3:44 PM, Tony Juricic wrote: > At one point I was thinking that I have too many C++ Custom Action Dlls and > started using existing Dlls. That is, I added a new entry point for a new CA > in a Dll that already hosted code for existing CA. That appears to work just > fine except for one issue: WcaLog() doesn't work - nothing gets output in a > log! > I don't know if the fact that I have 2 CA and 2 entry points in this DLL is > relevant, but this is the only case where WcaLog doesn't work. I am using > calls like: >::WcaLog(LOGMSG_STANDARD, "Install folder %S created.", Path); > so there is hardly anything mysterious here that can fail when many similar > calls in many other CA Dlls work. > > > TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: > TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member > NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading > software and subscription company, and TradeStation Europe Limited, a United > Kingdom, FSA-authorized introducing brokerage firm. None of these companies > provides trading or investment advice, recommendations or endorsements of > any kind. The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > > -- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry Manipulation
Would this really work? I ask because I have never managed to get conditions to work for Registry components. In my experience Registry is handled in bulk. All the components (i.e. Registry keys and values) either get created/written or no. -Original Message- From: p...@hoaske.dk [mailto:p...@hoaske.dk] Sent: Monday, February 09, 2009 9:39 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Registry Manipulation Hi Brian, after doing the RegistrySearch the property "MYREGKEYPROP" will be assigned the value if the key exists. If the key doesn't exist, the property "MYREGKEYPROP" will be assigned the default value "YetNotSet". You can use that fact in the condition for the component that writes/creates the key as explained: Component Id="CreateKeyComponent" Guid="" KeyPath="yes"> MYREGKEYPROP~="YetNotSet" It should now create the key if the Registry value was not found (Which means "MYREGKEYPROP" was assigned the default value "YetNotSet". Kind regards, Hans On Mon, February 9, 2009 14:33, Yu, Brian wrote: > Thanks for this, I'll give it a try. > > Is it possible to add a flag in the RegistryValue to say don't > write/create if value exists? > Probably too late for me, but I think it'll be a useful feature in the > future. > > > -Original Message- > From: p...@hoaske.dk [mailto:p...@hoaske.dk] > Sent: 09 February 2009 13:09 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Registry Manipulation > > > Hi Brian, > > what about something along the lines of: > > > Root="HKLM" Type="raw"/> > > > > Name="RegValueName" Root="HKLM" Type="string" > Value="NewValue"/> > NOT (MYREGKEYPROP~="A-value" OR > MYREGKEYPROP~="YetNotSet") > > > > Regards, > > Hans > > On Mon, February 9, 2009 12:19, Yu, Brian wrote: >> Is it possible for wix to search for existing registry value and if it >> exists or equal to a certain value, then leave the registry untouched >> >> But if it does not exist, then create? >> >> >> >> Is it a combination of using RegistrySearch and RegistryKey? How would >> it work? >> >> >> >> Brian Yu >> >> >> >> >> _ >> This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are >> incorporated under the laws of England and Wales (company no. 05677531 > and >> VAT registration no. 872810613). Our registered office is at 155 >> Bishopsgate, London EC2M 3TQ. This e-mail and/or any attached > documents >> may contain privileged and confidential information and should only be >> read by those persons to whom this e-mail is addressed. Use by other > than >> intended recipients is prohibited. If you are not the addressee, you > must >> not copy, distribute, disclose or use any of the information in it. If > you >> have received it in error, please delete it and immediately notify the >> sender. EASYSCREEN reserves the right to monitor all e-mail messages >> passing through its network. As we cannot guarantee the genuineness, >> accuracy or completeness of the information contained in this message, > the >> statements set forth are not legally binding. >> > > -- >> Create and Deploy Rich Internet Apps outside the browser with >> Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and > code >> to >> build responsive, highly engaging applications that combine the power > of >> local >> resources and data with the reach of the web. Download the Adobe AIR > SDK >> and >> Ajax docs to start building applications >> today-http://p.sf.net/sfu/adobe-com >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> > > > > > -- > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and > code to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications > today-http://p.sf.net/sfu/adobe-com > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > _ > This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are > incorporated under the laws of England and Wales (company no. 05677531 and > VAT registration no. 872810613). Our registered office is at 155 > Bishopsgate, London EC2M 3TQ. This e-mail and/or any attached documents > may contain privileged and confidential information and should only be > read by those persons t
Re: [WiX-users] Registry Manipulation
Say you are upgrading existing installation and you want to leave the value as it is. Like, user selected yes for some option. Otherwise it is a fresh install and you want default initial value of 'no'. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Monday, February 09, 2009 12:47 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Registry Manipulation Yu, Brian wrote: > Is it possible for wix to search for existing registry value and if it > exists or equal to a certain value, then leave the registry untouched > > But if it does not exist, then create? > What's the difference between writing a value and leave it alone? The end result is still the same, no? -- sig://boB http://joyofsetup.com/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry Manipulation
I'll give it a try again as I am obviously missing something. I am specifically referring to reinstall where REINSTALLMODE has option u meaning: Rewrite all required registry entries from the Registry Table that go to the HKEY_CURRENT_USER or HKEY_USERS registry hive. You are saying that, if I condition the component out, this above won't apply to that particular Registry entry/component? -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Monday, February 09, 2009 12:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Registry Manipulation If you condition out a Component then nothing in that Component should be installed/uninstalled/repaired. -Original Message----- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Monday, February 09, 2009 08:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Registry Manipulation Would this really work? I ask because I have never managed to get conditions to work for Registry components. In my experience Registry is handled in bulk. All the components (i.e. Registry keys and values) either get created/written or no. -Original Message- From: p...@hoaske.dk [mailto:p...@hoaske.dk] Sent: Monday, February 09, 2009 9:39 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Registry Manipulation Hi Brian, after doing the RegistrySearch the property "MYREGKEYPROP" will be assigned the value if the key exists. If the key doesn't exist, the property "MYREGKEYPROP" will be assigned the default value "YetNotSet". You can use that fact in the condition for the component that writes/creates the key as explained: Component Id="CreateKeyComponent" Guid="" KeyPath="yes"> MYREGKEYPROP~="YetNotSet" It should now create the key if the Registry value was not found (Which means "MYREGKEYPROP" was assigned the default value "YetNotSet". Kind regards, Hans On Mon, February 9, 2009 14:33, Yu, Brian wrote: > Thanks for this, I'll give it a try. > > Is it possible to add a flag in the RegistryValue to say don't > write/create if value exists? > Probably too late for me, but I think it'll be a useful feature in the > future. > > > -Original Message- > From: p...@hoaske.dk [mailto:p...@hoaske.dk] > Sent: 09 February 2009 13:09 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Registry Manipulation > > > Hi Brian, > > what about something along the lines of: > > > Root="HKLM" Type="raw"/> > > > > Name="RegValueName" Root="HKLM" Type="string" > Value="NewValue"/> > NOT (MYREGKEYPROP~="A-value" OR > MYREGKEYPROP~="YetNotSet") > > > > Regards, > > Hans > > On Mon, February 9, 2009 12:19, Yu, Brian wrote: >> Is it possible for wix to search for existing registry value and if it >> exists or equal to a certain value, then leave the registry untouched >> >> But if it does not exist, then create? >> >> >> >> Is it a combination of using RegistrySearch and RegistryKey? How would >> it work? >> >> >> >> Brian Yu >> >> >> >> >> _ >> This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are >> incorporated under the laws of England and Wales (company no. 05677531 > and >> VAT registration no. 872810613). Our registered office is at 155 >> Bishopsgate, London EC2M 3TQ. This e-mail and/or any attached > documents >> may contain privileged and confidential information and should only be >> read by those persons to whom this e-mail is addressed. Use by other > than >> intended recipients is prohibited. If you are not the addressee, you > must >> not copy, distribute, disclose or use any of the information in it. If > you >> have received it in error, please delete it and immediately notify the >> sender. EASYSCREEN reserves the right to monitor all e-mail messages >> passing through its network. As we cannot guarantee the genuineness, >> accuracy or completeness of the information contained in this message, > the >> statements set forth are not legally binding. >> > > -- >> Create and Deploy Rich Internet Apps outside the browser with >> Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and > code >> to >> build responsive, high
[WiX-users] Microsoft.Deployment.Compression.Zip issue
I know that Jason sometimes reads this forum but otherwise I am not sure this is the right place to report the following: I was using version 3.0 of Microsoft.Deployment.Compression.Zip in an attempt to extract MSI from self-extracting executable. In particular I used the class ZipInfo, IsValid method. However, since the executable happened to be in some other archive format (don't know which one but 7zip extracted MSI from it) IsValid method never returned and my program was frozen. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Applying Small Updates by Reinstalling the Product
Is there anybody who had a chance to try the above, as per link: http://msdn.microsoft.com/en-us/library/aa367575(VS.85).aspx I was just unpleasantly surprised that it appears not to work for my MSIs. For example, I had version 5.0.0.12 of one DLL installed. After issuing command line as per link above: msiexec /fvomus [path to updated .msi file] the installed DLL still remained at version 5.0.0.12, even if fresh install of the updated MSI installs expected new version 5.0.0.13. The same problem occurred not just with one DLL but with all versioned files. What can I look for in MSI log to help me debug this? When I apply small update patch via mcp then log has info about files to be patched (or no) and why, but in this case MSI log didn't tell me anything that I could parse about the reason for the files to remained untouched. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Execute action during path installation
It is possible to put a file into a Component containing only that file, make it volatile and change the condition for installing the component from 1 to 0. -Original Message- From: Brian Rogers [mailto:rogers.br...@gmail.com] Sent: Tuesday, February 10, 2009 6:43 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Execute action during path installation Hey Grigory, I don't believe you are able to remove a file while patching. However, you can change the file that you want to delete to a 0byte file. This will be effectively the same. I don't have an example of how to run a custom action but believe you just add a new action to your patch. There is a lot more information to go with that. Please view Heaths blog. http://blogs.msdn.com/heaths/archive/2005/09/12/464047.aspx Thanks, Brian Rogers "Intelligence removes complexity." - Me http://icumove.spaces.live.com On Fri, Feb 6, 2009 at 3:39 AM, Grigory Konovalov < grigory.konova...@confirmit.com> wrote: > Hello All! > I need remove file and execute custom action during patch installation. Is > this possible? And if yes please give me small example. > -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Execute action during path installation
Right, transitive component, rather than volatile. It goes like: 0 -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: Wednesday, February 11, 2009 1:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Execute action during path installation Yes. That's a fairly common way of making sure that a file doesn't get installed on the system without breaking the component rules during patching. That's a transitive component. Phil Wilson -Original Message----- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, February 10, 2009 5:51 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Execute action during path installation It is possible to put a file into a Component containing only that file, make it volatile and change the condition for installing the component from 1 to 0. -Original Message- From: Brian Rogers [mailto:rogers.br...@gmail.com] Sent: Tuesday, February 10, 2009 6:43 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Execute action during path installation Hey Grigory, I don't believe you are able to remove a file while patching. However, you can change the file that you want to delete to a 0byte file. This will be effectively the same. I don't have an example of how to run a custom action but believe you just add a new action to your patch. There is a lot more information to go with that. Please view Heaths blog. http://blogs.msdn.com/heaths/archive/2005/09/12/464047.aspx Thanks, Brian Rogers "Intelligence removes complexity." - Me http://icumove.spaces.live.com On Fri, Feb 6, 2009 at 3:39 AM, Grigory Konovalov < grigory.konova...@confirmit.com> wrote: > Hello All! > I need remove file and execute custom action during patch installation. Is > this possible? And if yes please give me small example. > -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patch uninstall requires the original base MSI and I don't know why
The uninstallable patch is looking for the original MSI that was extracted from Setup.exe chainer into temporary folder and is since long gone. I re-read the docs but I am still clueless as to what caused it. Naturally, I want to uninstall the patch without requiring the access to the original RTM MSI. Here is wxs used to create the patch: http://schemas.microsoft.com/wix/2006/wi";> http://www.MeMeMe.com"; Classification="Hotfix" AllowRemoval="yes" OptimizedInstallMode="yes" /> -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch uninstall requires the original base MSI andI don't know why
Thanks, I managed to identify the problem in the log. The change that made patch uninstall ask for the source (it didn't before) is because I have a new DLL which gets installed in shared location. DLL is supposed to always increase in version so it can be patched up but it should never revert to previous version during patch uninstall. I assume that just marking the file component as Permanent would do this for me? -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Tuesday, February 24, 2009 10:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch uninstall requires the original base MSI andI don't know why Tony Juricic wrote: > The uninstallable patch is looking for the original MSI that was > extracted from Setup.exe chainer into temporary folder and is since long > gone. > > I re-read the docs but I am still clueless as to what caused it. > You uninstalled a patch: That performs a repair of the unpatched product, which usually requires source. Get a verbose log to verify what it's looking for. -- sig://boB http://joyofsetup.com/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch uninstall requires the original base MSI andIdon't know why
Marking the component as permanent didn't' work at all. I wrongly assumed that patch uninstall is a form of uninstall so it won't uninstall a permanent file. Instead, it is a reinstall and it overwrites higher version files with lower version from baseline cache. Also, I am not sure how will REINSTALLMODE affect this behavior. I never set it so it is presumably default omus. What REINSTALLMODE options would produce desired result: file version increments as patches get applied but does not drop when patches get uninstalled? IOW, the latest and greatest version ever installed always remains on the machine. Clearly, making component permanent will do this in install/uninstall scenario but can the same be done when applying/removing patches? I never see REINSTALLMODE value listed in patch application or patch removal verbose logs. At most I find "REINSTALLMODE specifies all files to be overwritten" for each file in patch removal log. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, February 25, 2009 3:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch uninstall requires the original base MSI andIdon't know why Tony Juricic wrote: > DLL is supposed to always increase in version so it can be patched up > but it should never revert to previous version during patch uninstall. Whether that's true depends on your original product's REINSTALLMODE property. > I > assume that just marking the file component as Permanent would do this > for me? > At the cost of leaving the component behind after an uninstall. -- sig://boB http://joyofsetup.com/ TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number?
Good to know, thanks! -Original Message- From: Heath Stewart [mailto:clubs...@gmail.com] Sent: Friday, April 03, 2009 3:16 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? In a verbose log Windows Installer 3.1+ will add a line line "SELMGR: A component *foo* is registered to feature *bar*, but was removed from the feature.", followed immediately by something like "SELMGR: Removal of components from a feature is not supported." But this will not fail the patch. Instead it will advertise the feature and the content of that feature will never be repaired again. See http://blogs.msdn.com/heaths/archive/2006/01/23/516457.aspx for more information. MSIENFORCEUPGRADECOMPONENTRULES merely turns that into an error, so instead of silently breaking the product the property (and the corresponding machine policy) will fail the install. So a small update or minor upgrade patch will apply if you break this component violation, but the feature will forever be broken until explicitly added back into the local state. See http://blogs.msdn.com/heaths/archive/2009/01/27/repairing-products-after-patches-advertised-features.aspxfor some suggestions of how to do that. On Wed, Aug 6, 2008 at 1:33 AM, Tony Juricic wrote: > It just goes to show how easy it is to commit gross component rules > violations even after months of reading articles and blogs on component > rules! > > However, it seems that I have also misunderstood the purpose of > MSIENFORCEUPGRADECOMPONENTRULES property. I was under the impression > that it would add to verbose log. I mean, if MSI *knows* that there is > component violation, it would be of great help if it could add a > sentence to the log saying at least something along the lines of: > There is component rules violation of some sort! > > After reading all that I could find on MSIENFORCEUPGRADECOMPONENTRULES > property I can't say that I am 100% sure about what is it that it really > does? How can the consequences of having this property defined or not be > seen on some practical example? I was certainly none the wiser in this > specific case since verbose logs were identical with or without it, for > all that I could see. > > It *seems* that a small update patch may be applied by MSI in some cases > even if there was a component rule violation and this property prevents > it. > > -Original Message- > From: Bob Arnson [mailto:b...@joyofsetup.com] > Sent: Saturday, August 02, 2008 1:10 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version > number? > > Tony Juricic wrote: > > but reading the install.log I cannot find anything a bit more explicit > > about this violation. It is certainly not saying something like "you > > changed the name of your root installation folder and you shouldn't" > :) > > > > Sorry, it's not that polite. The "Windows Installer Components" topic > > summarizes the magic of component rules with two bullets: > >In brief, these rules are: > >* Each component must be stored in a single folder. >* No file, registry entry, shortcut, or other resources should > ever be shipped as a member of more than one component. This > applies across products, product versions, and companies. > > So changing the directory violates 50 percent of the component rules. > > -- > sig://boB > http://joyofsetup.com/ > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and ma
Re: [WiX-users] New wix binary delta patching doesn't work
I am using old-style patchwiz.dll patching with success on daily builds and I
haven't updated WIX for 4 months already.
Nevertheless, there are several reason to prefer new style delta patching so I
will let you know how it works with the latest WIX version as soon as I get
some extra iteration time.
Thanks for info!
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: Friday, April 03, 2009 3:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] New wix binary delta patching doesn't work
Are you still having the same problem with recent builds? A month or two ago
changes were made to fix a couple of issues with delta patching.
On Tue, Aug 19, 2008 at 5:57 AM, Tony Juricic wrote:
> Ok, that makes sense. However, I can't get it to work either way. The
> problem is not in changing just the 4th version number either. I created
> a simple C# console executable that has one line of code:
>
> Console.Writeln("This is version 1.0.0.0");
>
> and assembly info AssemblyVersion("1.0.0.0")] and
> AssemblyFileVersion("1.0.0.0")].
>
> I build WiX test project referencing this program with -bf -xo linker
> options.
>
> The output is WixTest1.msi but it is not msi file since it can't be
> opened with Orca. Is it wixpdb or wixout? Torch doesn't like wixpdb
> extension (error TRCH0048) but accepts wixout.
>
> I then update console program by changing all the strings 1.0.0.0 above
> to 1.0.1.0, then rebuild exe and WiX project, changing also Product
> element, Version attribute to 1.0.1.0. This gives me the second wixout
> file for input to torch and I get 31 KB large Diff.wixmst.
>
> When I run Pyro it comes with PYRO0252 error meaning that it can't find
> any transform.
>
> Torch and Pyro invoking batch files content is the following:
>
> "%WIX%bin\torch.exe" -p -xi -v -val g -val l -val r -val z
> Version1000\WiXTest1000.wixout Version1010\WiXTest1010.wixout -out
> Patch\Diff.Wixmst
>
> "%WIX%bin\candle.exe" Patch.wxs
> "%WIX%bin\light.exe" Patch.wixobj -out Patch\Patch.WixMsp
> REM "%WIX%bin\pyro.exe" -delta Patch\Patch.WixMsp -out Patch\Patch.msp
> -t RTM Patch\Diff.wixmst
> "%WIX%bin\pyro.exe" Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM
> Patch\Diff.wixmst
>
> Note above REMarked -delta option.
>
> Patch.wxs content is:
>
>
> http://schemas.microsoft.com/wix/2006/wi";>
> ClientPatchId="WiXTest1" Id="*" DisplayName="WiXTest1 Update"
> Manufacturer="WiXTest1" MoreInfoURL="http://www.WiXTest1.com";
> Description="Minor Update Patch" TargetProductName="WixTest1">
> Source="FIRSTPATCH_PROP">
>
>
>
>
>
>
>
> Supersede="no">
>
>
>
>
>
>
> Obviously, I am doing something horribly wrong in my adaptation of Peter
> Marcu's blog example or there is a nasty bug somewhere in there.
>
>
> -Original Message-
> From: Blair Murri [mailto:bmu...@microsoft.com]
> Sent: Monday, August 11, 2008 1:56 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] New wix binary delta patching doesn't work
>
> The "-delta" switch of pyro builds on top of the whole-file patch
> support in pyro, so if that isn't working, the delta addition won't do
> anything to help you.
>
> If you get pyro to build a whole file patch that updates your binaries,
> then add the -delta switch and test the results.
>
>
>
> -
> 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
>
--
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these compa
[WiX-users] How much of patch pcp database makes it into msp?
In particular, can I somehow get MediaSrcPropName value, from *.pcp ImageFamilies table, using DTF on my patch *.msp file? I suspect that answer is, most probably and unfortunately, no, but just in case... thanks! TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How much of patch pcp database makes it into msp?
Thanks Bob but this, unfortunately, does not seem to be true.
I am using DTF and code very simple test code:
public void ShowPatches()
{
using (Session ses = Installer.OpenProduct(productCode))
{
Database db = ses.Database;
TableCollection tc = db.Tables;
if (tc.Contains("Media"))
{
IList res = db.ExecuteStringQuery("SELECT Source
FROM Media");
}
}
}
and I see that Source string from 2 of my applied patches is some string
constructed by installer and in the following format:
MSPSRC
This is certainly not what I had put in MediaSrcPropName.
What I am really trying to do is the following: say I have 3 patches
applied to my product. I want to know their sequence numbers. I could
read it from the patch msp files, if they were available, but in this
case they are not.
DTF has very useful public static IEnumerable
GetPatches() method but PatchInstallation object contains just about
everything about the patch except the sequence number.
Thus I am forced to create and maintain an external file mapping patch
Guids to corresponding sequence numbers.
All I want is to display applied patches in order of their sequence #
:(
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Monday, June 15, 2009 7:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How much of patch pcp database makes it into
msp?
Tony Juricic wrote:
> In particular, can I somehow get MediaSrcPropName value, from *.pcp
> ImageFamilies table, using DTF on my patch *.msp file?
>
The doc says:
The value entered into the Source field of the new Media table entry of
the upgraded image.
So it's available. But only very indirectly, since the Media table is in
your .msi packages and modified using a patch transform.
--
sig://boB
http://joyofsetup.com/
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these companies provides
trading or investment advice, recommendations or endorsements of any kind. The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer.
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How much of patch pcp database makes it into msp?
Thanks Jason!
That worked just fine and the same as if I had the original MSP file
available. I guess that was to be expected.
In this particular case, since I am authoring the patches, all are
guaranteed to have sequence table.
At this point I got what I wanted and the only unknown/concern is if
non-administrative users will be allowed to read cached MSP database.
-Original Message-
From: Jason Ginchereau [mailto:jason...@microsoft.com]
Sent: Monday, June 15, 2009 4:59 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How much of patch pcp database makes it into
msp?
The patch sequence information is stored in a table in the MSP directly;
unlike the rest of the stuff in the MSP it does NOT get applied to the
target product database. So, to get at that table for an installed patch
you first need to get the PatchInstallation.LocalPackage, open that
package as a Database, then query the MsiPatchSequence table if it
exists. (Some patches might not have this table).
Something like this (I have not tested this code)...
PatchInstallation p = ...
if (File.Exists(p.LocalPackage))
{
using (Database patchDb = new Database(p.LocalPackage))
{
if (patchDb.Tables.Contains("MsiPatchSequence"))
{
// Query the sequence table.
// Note there may be multiple rows for different
product codes/patch families.
}
}
}
-Original Message-----
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Monday, June 15, 2009 12:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How much of patch pcp database makes it into
msp?
Thanks Bob but this, unfortunately, does not seem to be true.
I am using DTF and code very simple test code:
public void ShowPatches()
{
using (Session ses = Installer.OpenProduct(productCode))
{
Database db = ses.Database;
TableCollection tc = db.Tables;
if (tc.Contains("Media"))
{
IList res = db.ExecuteStringQuery("SELECT Source
FROM Media");
}
}
}
and I see that Source string from 2 of my applied patches is some string
constructed by installer and in the following format:
MSPSRC
This is certainly not what I had put in MediaSrcPropName.
What I am really trying to do is the following: say I have 3 patches
applied to my product. I want to know their sequence numbers. I could
read it from the patch msp files, if they were available, but in this
case they are not.
DTF has very useful public static IEnumerable
GetPatches() method but PatchInstallation object contains just about
everything about the patch except the sequence number.
Thus I am forced to create and maintain an external file mapping patch
Guids to corresponding sequence numbers.
All I want is to display applied patches in order of their sequence #
:(
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Monday, June 15, 2009 7:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How much of patch pcp database makes it into
msp?
Tony Juricic wrote:
> In particular, can I somehow get MediaSrcPropName value, from *.pcp
> ImageFamilies table, using DTF on my patch *.msp file?
>
The doc says:
The value entered into the Source field of the new Media table entry of
the upgraded image.
So it's available. But only very indirectly, since the Media table is in
your .msi packages and modified using a patch transform.
--
sig://boB
http://joyofsetup.com/
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ
GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc.
(Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a
trading software and subscription company, and TradeStation Europe
Limited, a United Kingdom, FSA-authorized introducing brokerage firm.
None of these companies provides trading or investment advice,
recommendations or endorsements of any kind. The information transmitted
is intended only for the person or entity to which it is addressed and
may contain confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please
contact the sender and delete the material from any computer.
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
__
[WiX-users] What options activate verbose WcaLog?
In a C++ DLL custom action I have the following code: ::WcaLog(LOGMSG_VERBOSE, "%s", "My log text"); MSI install is started with the following log options: msiexec /i myinstall.msi /lv*x .\install.log However, log file doesn't contain the text as could be expected. In contrast, LOGMSG_STANDARD works in this scenario. Thanks for any input - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where does FilesInUse dialog get its names from?
Same problem here so I second a plea for help and more info -Original Message- From: Neil Enns [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 12:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from? Well, unfortunately, that's not what's happening. It's detecting that we're running, and if we say "next" on the dialog our application shuts down properly. But the list box is empty. How can we go about debugging why? Neil From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bob Arnson [EMAIL PROTECTED] Sent: Tuesday, July 15, 2008 6:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from? Neil Enns wrote: > It appears that our installer is magically detecting whether our application is running at the time of an install, and even correctly closes it. However, the FilesInUse dialog that comes with WiXUI isn't showing anything in the listbox of running processes. What magic do we need to do to populate the listbox with the name of our application? > MSI should be showing only apps with visible, top-level windows; the content of the list box item is the window title. So it should be automatic "free." If MSI doesn't find the right kind of windows or titles, it should skip them and, if none, not show FilesInUse at all (just reboot). -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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] Where does FilesInUse dialog get its names from?
Thanks for consideration Neil! Unfortunately my problem is killing some COM EXE servers that don't show a window, plus I don't always get my authored FilesInUse dialog. When uninstalling if programs are running I get some other system-provided dialog which doesn't successfully kill even the apps that have a window. -Original Message- From: Neil Enns [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 1:37 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from? Solved! Tony, if you are writing a managed application, you need to make sure it has the AssemblyTitle assembly attribute set on it. That's where the string comes from. Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Wednesday, July 16, 2008 7:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from? Same problem here so I second a plea for help and more info -Original Message- From: Neil Enns [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 12:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from? Well, unfortunately, that's not what's happening. It's detecting that we're running, and if we say "next" on the dialog our application shuts down properly. But the list box is empty. How can we go about debugging why? Neil From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bob Arnson [EMAIL PROTECTED] Sent: Tuesday, July 15, 2008 6:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from? Neil Enns wrote: > It appears that our installer is magically detecting whether our application is running at the time of an install, and even correctly closes it. However, the FilesInUse dialog that comes with WiXUI isn't showing anything in the listbox of running processes. What magic do we need to do to populate the listbox with the name of our application? > MSI should be showing only apps with visible, top-level windows; the content of the list box item is the window title. So it should be automatic "free." If MSI doesn't find the right kind of windows or titles, it should skip them and, if none, not show FilesInUse at all (just reboot). -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] A method for avoiding ICE38 error
During installation I create some per-user folders in Users\username\AppData\Roaming. Thus I get hit by ICE30 error. I don't really understand why would creating folders under CU profile cause problems for component un/installation in this particular case. Anyhow, I solved the problem with a trick as follows: I feel uneasy about this "solution" and would appreciate your comments. In particular what, if anything, may go wrong creating CU profile folders in this way. - 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] A method for avoiding ICE38 error
Yes, writing ICE30 instead of ICE38 was a typo. Example with the current %userprofile% path that gets enumerated at heal time answers my question, thanks. Writing wouldn't cause key not to be written on install, as I thought. Clearly to be used as a keypath, something has to be written to the Registry. Thus, it made sense for me to create a 'normal' Registry key (i.e. with company name, product name etc. in key path) and use it for component registry. -Original Message- From: jmcfadyen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 10:30 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] A method for avoiding ICE38 error ICE30 and ICE38 are two quite different errors. ICE38 seems pertinent in this case so I will assume you are talking about this. When deploying files to a users profile if the file is a keypath to the component the files fullpath will be written to the component's registry i.e. c:\users\%username%\appdata\xxx.xxx or more precisely c:\users\john\appdata\xxx.xxx as such during self healing it can get a little confused if your logged in as another user. particularly if that user doesnt have admin rights. By changing the keypath to an HKCU it ensures that it queries HKCU\software\ to determine if the component needs to be installed. because of this the current %userprofile% path gets enumerated at heal time. where a keypath is an HKCU reg key it ensures these keys are dropped for all successive profiles after the installation occurs (using self healing). im not sure if this answers all your question or not, let me know if you need more input. Tony Juricic wrote: > > During installation I create some per-user folders in > Users\username\AppData\Roaming. Thus I get hit by ICE30 error. > > I don't really understand why would creating folders under CU profile > cause problems for component un/installation in this particular case. > Anyhow, I solved the problem with a trick as follows: > > > > > > > > > > On="uninstall" /> > > > > > > I feel uneasy about this "solution" and would appreciate your comments. > In particular what, if anything, may go wrong creating CU profile > folders in this way. > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- View this message in context: http://www.nabble.com/A-method-for-avoiding-ICE38-error-tp18517038p18521 532.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help customizing FilesInUse Dialog
I was under the impression that runtime requires this dialog to have exactly FilesInUse name since it is invoked by installer, not by user. IOW, its name cannot be customized. -Original Message- From: Neil Enns [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help customizing FilesInUse Dialog Taking this approach will require literally pulling in everything, right? Including all the localization files for WiXUI_Minimal? Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Friday, July 18, 2008 1:58 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help customizing FilesInUse Dialog Are you using votive? And are you using the WixUIExtension? If so, I would imagine you can skip the extension, and just fully replace the FilesInUse name. Copy down all the rest of the UI wxs and just go to town. Chris On Fri, Jul 18, 2008 at 4:42 PM, Dan Giambalvo < [EMAIL PROTECTED]> wrote: > I'm in need of some help trying to customize the FilesInUse dialog for my > app's installer. Our designers want to customize the look and feel of the > entire installer, so starting with WIXUI_Minimal I've been making local > copies of each dialog wxs file and then making modifications. This worked > perfectly for all the non-required dialogs (like WelcomeEulaDlg) but I'm now > running into some issues with some of the "required" dialogs like > FilesInUse. Basically, if I change the name of my dialog to something like > MyAppFilesInUse and don't reference FilesInUse, then the installer complains > about a lack of a FilesInUse dlg. If I instead name my dialog FilesInUse, > then I get a conflict because there are duplicates. > > Given the above, I'm at something of an Impasse. I'm sure there's a way to > do this. Can someone offer some help? > > Thanks in advance! > -Dan > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help customizing FilesInUse Dialog
Disregard my previous comment. It is dialog ID which must remain "FilesInUse", of course, everything else can be customized. In my case which requires a lot of customization I have pulled in the entire WixUI_en-us.wxl and renamed it into CustomWixUI_en-us.wxl -Original Message- From: Neil Enns [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help customizing FilesInUse Dialog Taking this approach will require literally pulling in everything, right? Including all the localization files for WiXUI_Minimal? Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Friday, July 18, 2008 1:58 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help customizing FilesInUse Dialog Are you using votive? And are you using the WixUIExtension? If so, I would imagine you can skip the extension, and just fully replace the FilesInUse name. Copy down all the rest of the UI wxs and just go to town. Chris On Fri, Jul 18, 2008 at 4:42 PM, Dan Giambalvo < [EMAIL PROTECTED]> wrote: > I'm in need of some help trying to customize the FilesInUse dialog for my > app's installer. Our designers want to customize the look and feel of the > entire installer, so starting with WIXUI_Minimal I've been making local > copies of each dialog wxs file and then making modifications. This worked > perfectly for all the non-required dialogs (like WelcomeEulaDlg) but I'm now > running into some issues with some of the "required" dialogs like > FilesInUse. Basically, if I change the name of my dialog to something like > MyAppFilesInUse and don't reference FilesInUse, then the installer complains > about a lack of a FilesInUse dlg. If I instead name my dialog FilesInUse, > then I get a conflict because there are duplicates. > > Given the above, I'm at something of an Impasse. I'm sure there's a way to > do this. Can someone offer some help? > > Thanks in advance! > -Dan > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Two questions about new WiX patching
1) I don't understand how do wixpdb ouputs deal with binary delta patches? Looking at example commands it appears as if MSI (or binary files compressed inside MSI cab) are not needed, as if all relevant info is contained in wixpdb. Or is it that torch, while working on the differences between 2 wixpdbs, expects that MSIs are present in respective locations and decompresses them to find delta patches? 2) Regarding file sequences, if, for example, I have 200 files to install and possibly need to patch each and every one of them, am I supposed to increment media Id by 200? So I would start with say: Then the next patch would be: next and so on? Thanks for any input! - 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] Changing default UILevel for uninstall.
As Bob, of Joy of Setup fame, explained here once, there is no way to change the level used by ARP and UILevel is read-only during uninstall. However, you can add Change ARP option which would launch your authored Change dialog from which you can proceed to a full UI uninstall (or repair or the real change of features) -Original Message- From: Joe Coplen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2008 5:12 PM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Changing default UILevel for uninstall. The default UILevel for uninstall appears to be 3 (Basic). I need to run at UILevel 5 (Full) in all cases but 2 (None). I have tried adding a custom action to the InstallExecuteSequence that changes the UILevel property to 5 - checking the setup log, I can see my custom action runs and the UILevel property is successfully changed. However, my dialogs still don't appear. Does anyone have a good way of doing this? -J - 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] Changing default UILevel for uninstall.
I assumed you are talking about uninstalling via ARP. Otherwise the batch file with the following content works just fine in my daily testing: msiexec /x myproduct.msi /qf /lv*x .\install.log qf is for full UI and you can put product code instead of msi filename since you are not supposed to know where is installed/downloaded msi file. -Original Message- From: Joe Coplen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2008 5:12 PM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Changing default UILevel for uninstall. The default UILevel for uninstall appears to be 3 (Basic). I need to run at UILevel 5 (Full) in all cases but 2 (None). I have tried adding a custom action to the InstallExecuteSequence that changes the UILevel property to 5 - checking the setup log, I can see my custom action runs and the UILevel property is successfully changed. However, my dialogs still don't appear. Does anyone have a good way of doing this? -J - 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] Two questions about new WiX patching
Or am I, for the time being, still better off with the old-style administrative installs and PatchCreation? In my case binary delta is the requirement. Thanks -Original Message- From: Tony Juricic Sent: Monday, July 21, 2008 2:08 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Two questions about new WiX patching 1) I don't understand how do wixpdb ouputs deal with binary delta patches? Looking at example commands it appears as if MSI (or binary files compressed inside MSI cab) are not needed, as if all relevant info is contained in wixpdb. Or is it that torch, while working on the differences between 2 wixpdbs, expects that MSIs are present in respective locations and decompresses them to find delta patches? 2) Regarding file sequences, if, for example, I have 200 files to install and possibly need to patch each and every one of them, am I supposed to increment media Id by 200? So I would start with say: Then the next patch would be: next and so on? Thanks for any input! - 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] Setting standard action conditions
Examples: MyProperty=0 Not Installed -Original Message- From: jmcfadyen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2008 3:45 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Setting standard action conditions How can I set a condition on a standard action. i.e. "CreateShortcuts", "My new condition here", 4000 <-- made the sequence up. -- View this message in context: http://www.nabble.com/Setting-standard-action-conditions-tp18626877p1862 6877.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Close button in Progress dialog
I have Progress with disabled Close button so it prevents me from cancelling the installation while it is displayed. Yet, I have done nothing (that I am aware of) to cause that. Progress dialog is declared like this: controls with progress bar etc. I know that there is a MSI message used exclusively to disable Cancel while Progress dialog is displayed but I am sure that I'm not invoking it in any of my custom actions. So what is making Close button disabled? Thanks for any input. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] One more Vista ARP issue?
I have MSI file on my desktop that I just used to perform the install. When I click on MSI Change welcome dialog, authored by me, is shown - all is fine. When I click on ARP entry and select Change menu item some Installer message box appears and goes away so fast that I cannot read it, but I don't get my Change welcome dialog. Apparently installer launched via ARP aborts for some reason. This is on Vista Business and I am running as administrator. So what is the difference between starting MSI via ARP and by clicking on it that could cause such different behaviors? How would one debug this situation, if it is at all possible? This used to work once, that is, I was able to see authored Change dialog when clicking on ARP Change menu item. I haven't touched ARP-related WiX elements in my project in the meantime, but I have started signing my MSI. However, even MSIs that I don't sign now have a problem showing Change dialog from ARP. Thanks for any input. - 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] One more Vista ARP issue?
This has nothing to do with WiX since I have just found out that not a single product that offers Change option in my ARP list would work. A brief flash of some message box is all I see. -Original Message- From: Tony Juricic Sent: Thursday, July 24, 2008 3:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] One more Vista ARP issue? I have MSI file on my desktop that I just used to perform the install. When I click on MSI Change welcome dialog, authored by me, is shown - all is fine. When I click on ARP entry and select Change menu item some Installer message box appears and goes away so fast that I cannot read it, but I don't get my Change welcome dialog. Apparently installer launched via ARP aborts for some reason. This is on Vista Business and I am running as administrator. So what is the difference between starting MSI via ARP and by clicking on it that could cause such different behaviors? How would one debug this situation, if it is at all possible? This used to work once, that is, I was able to see authored Change dialog when clicking on ARP Change menu item. I haven't touched ARP-related WiX elements in my project in the meantime, but I have started signing my MSI. However, even MSIs that I don't sign now have a problem showing Change dialog from ARP. Thanks for any input. - 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] One more Vista ARP issue?
... and the solution is ... reboot! - 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] Close button in Progress dialog
All right, what is making Close button disabled is the fact that I don't
have Cancel button in Progress page!
I needed extra space for billboards so I removed it. Now it is back with
Hidden="yes" to keep it invisible and problem solved. It occurred to me
that this may be the cause at one time so the answer provided the boost.
Thanks!
-Original Message-
From: cemiles [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 12:03 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Close button in Progress dialog
What's your control look like?
1
.
.
.
This?
Tony Juricic wrote:
>
> I have Progress with disabled Close button so it prevents me from
> cancelling the installation while it is displayed.
>
> Yet, I have done nothing (that I am aware of) to cause that. Progress
> dialog is declared like this:
>
>
>
>
> controls with progress bar etc.
>
>
> I know that there is a MSI message used exclusively to disable Cancel
> while Progress dialog is displayed but I am sure that I'm not invoking
> it in any of my custom actions.
>
>
> So what is making Close button disabled?
>
>
> Thanks for any input.
>
>
>
>
-
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
View this message in context:
http://www.nabble.com/Close-button-in-Progress-dialog-tp18639034p1865469
8.html
Sent from the wix-users mailing list archive at Nabble.com.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Two questions about new WiX patching
Thanks Blair, that is exactly what I was looking for1 My problem is precisely in impossibility to recreate the same file locations between the builds. For a while I thought about building MSI, then doing administrative install and then fixing the paths in non-binary wixpdb to correspond to admin install. However, binary wixpdb is much easier and less error prone approach than that. Now, if I only knew how #2 works ... Tony -Original Message- From: Blair Murri [mailto:[EMAIL PROTECTED] Sent: Sunday, July 27, 2008 2:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Two questions about new WiX patching I don't know the answer to #2, but as to #1 (Pyro actually creates the deltas, based on what is in the wixmst(s) passed to it) (this is accurate as of ~ 6 months ago, Peter please correct me if I am wrong on any changes to the wixpdbs), there are two possibilities: 1) wixpdb is a binary wixout: Can be as a result of using dark, or as a result of binding using binary wixouts from linking with the -bf and -xo parameters. Torch passes the files used to create the deltas from the wixpdbs passed in to the wixmst (making a binary wixmst). Note that it is possible for one of the two wixpdbs to have been binary and the other to not be, in which case the wixmst contains the files from the binary wixpdb and filespecs from the non-binary wixpdb. Note further that it is possible to create wixpdbs (or any wixout, for that matter) with a mix of included and referenced binaries, but most of the time you get all one or all the other. 2) wixpdb is not a binary wixout: Results of linking and binding in one step. Torch passes the filespecs (path to the files) from the wixpdb in the wixmst. Pyro will use whatever it is passed (included files or filepaths) to get the two versions of the files it will create the delta patches for. What I recommend is: link with -xo and -bf to produce a binary (bound) wixout (using light). Bind with the binary wixout (using light again) to create the MSI if needed. Store the resulting wixpdb for use in creating MSPs in later builds. Otherwise, you will have to recreate or restore the old files in the exact same file locations as they were when you created the wixpdb, and the new wixpdb will have to be created in a different file location. Hard to do with most centralized build systems. In your later build, if you don't need to create both an MSI and an MSP configuring the same version (hope you don't) then you may not have to create a binary (bound) wixpdb for the upgrade case, otherwise build it the same way. Pass both wixpdbs to torch, and pyro will use the files in the generated wixmst file to generate the deltas. At least that is the way it was working when I added it to WiX. -Blair -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Tuesday, July 22, 2008 2:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Two questions about new WiX patching Or am I, for the time being, still better off with the old-style administrative installs and PatchCreation? In my case binary delta is the requirement. Thanks -Original Message----- From: Tony Juricic Sent: Monday, July 21, 2008 2:08 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Two questions about new WiX patching 1) I don't understand how do wixpdb ouputs deal with binary delta patches? Looking at example commands it appears as if MSI (or binary files compressed inside MSI cab) are not needed, as if all relevant info is contained in wixpdb. Or is it that torch, while working on the differences between 2 wixpdbs, expects that MSIs are present in respective locations and decompresses them to find delta patches? 2) Regarding file sequences, if, for example, I have 200 files to install and possibly need to patch each and every one of them, am I supposed to increment media Id by 200? So I would start with say: Then the next patch would be: next and so on? Thanks for any input! - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Op
[WiX-users] Votive enhancement suggestions
1) new patch project template 2) 2 new output types, binary and non-binary wixpdb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Preview of binary WIXPDB file
Non-binary ones are just XML so I use XML Notepad to look at them. For MSI's I use Orca. Is it that a tool for previewing binary WiXpdbs has yet to be written ? Thanks, Tony - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Torch error 0048
Giving command: "%WIX%bin\torch.exe" -xi rtm\Product.wixpdb upd1\Product.wixpdb -out Patch\Diff.Wixmst I get the following error: error TRCH0048 : The document element name 'wixOutput' is invalid. A WiX pdb file must use 'wixPdb' as the document element name. Clearly torch doesn't like something in the way my binary wixpdbs were created. I'm sure they are binary, first because of their size, second because they cannot be opened as MSIs with Orca, nor as XML if they were non-binary. Here are linker options used to create wixpdbs from wixproj: bin\$(Configuration)\ obj\$(Configuration)\ -out $(OutputPath)Project.wixpdb -bf -xo I simply added -out filename -bf and -xo options to Votive field for additional linker options as Votive was set up to produce msi by default. WiX version is 3.0.4220.0 What did I do wrong and how can I recover from this error? I mean, it shouldn't be possible to lose work in this way since I did get wixpdb output and wixpdb file is the right size - for ex. it must have bound all my binaries. Thanks - 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] Torch error 0048
With just -bf and -xo as additional linker options Votive creates this command line: C:\Program Files\Windows Installer XML v3\bin\Light.exe -loc CustomWixUI_en-us.wxl -out C:\path\Product.msi -pdbout C:\path\Product.wixpdb -bf -xo obj\Debug\BrowseDlg.wixobj ... dialog and other wixobjs ... obj\Debug\WelcomeDialog.wixobj This produces only Project.msi output file. However it is not really MSI because it can't be opened with Orca, so I guess it is wixpdb. This is quite confusing. For ex. what purpose does -pdbout C:\path\Product.wixpdb serve in this context? And than torch thinks it is wixout rather than wixpdb?! - 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] Torch error 0048
Ok, so renaming my wixpdb files, produced as described above, to wixout extension solved the problem for torch input and it produced wixmst output file. Thus, apparently, wixpdb can exist only in XML format, while wixout is binary. Based on Peter Marcu's blog I understood that wixpdb substitutes and subsumes wixout and can exist in both XML and binary format, depending on whether binaries are bound or not. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Does Pyro (or Torch) ignore 4-th version number?
I have 120 MB large Wixmst created by Torch and when I pass it to Pyro it comes back with the message PYRO1079 saying that patch cabinet contains no files. My DLLs in RTM and Update respectively differ in the last, 4-th version number, plus the binaries themselves are different. Using SDK tools for patch creation these DLLs would be updated when applying the patch. I tested that long before I started using WiX and I am 100% sure that SDK doesn't ignore fourth version number for file substitution rules. So I am wondering if Pyro is ignoring binary differences if first 3 version numbers are the same? Patch.wxs content is the following: http://schemas.microsoft.com/wix/2006/wi";> ... a bunch of components follows Thanks - 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] Does Pyro (or Torch) ignore 4-th version number?
Are you saying that there is some way to get better error diagnostics from Torch? I added -v option for verbosity but it has no effect. In fact, I can't even figure out how do validation flags validate?! For example, once I run Torch with -val y, next time with -val v, keeping the same wixout input files. I would expect some validation error to be reported: I mean, update versions of my DLLs can't be both larger and smaller than the target versions! However Torch reports no issues in either case, just silently outputs wixmst file which, according to Pyro, contains 120 MB of nothing. I certainly have-p option which is essential according to Peter's blog. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 11:04 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? There is a share proderrors or something Pete Yates Senior Systems Developer DDC - Distributed & Components Team HBOS I&I IT B/1/C/243 (7725) 34383 / (0117) 376 4383 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: 31 July 2008 15:56 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? I have 120 MB large Wixmst created by Torch and when I pass it to Pyro it comes back with the message PYRO1079 saying that patch cabinet contains no files. My DLLs in RTM and Update respectively differ in the last, 4-th version number, plus the binaries themselves are different. Using SDK tools for patch creation these DLLs would be updated when applying the patch. I tested that long before I started using WiX and I am 100% sure that SDK doesn't ignore fourth version number for file substitution rules. So I am wondering if Pyro is ignoring binary differences if first 3 version numbers are the same? Patch.wxs content is the following: http://schemas.microsoft.com/wix/2006/wi";> ... a bunch of components follows Thanks - 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 . -- HBOS plc, Registered in Scotland No. SC218813. Registered Office: The Mound, Edinburgh EH1 1YZ. HBOS plc is a holding company, subsidiaries of which are authorised and regulated by the Financial Services Authority. HBOS is a carbon neutral company. Help keep it that way. Please don't print this message unless you really must. == - 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] Does Pyro (or Torch) ignore 4-th version number?
I see, validation is used during patch application. Regarding the patch family I have defined only one family, following the example from Peter's blog and changing a few attributes like Manifacturer, DisplayName and similar. In my case that should be sufficient because the product has only one feature which contains all the components. I have simply copy-pasted the list of component references from the Feature element in Product.wxs to PatchFamily element in Patch.wsx. I have tested Torch and Pyro behavior when two input wixout files are identical and it is pretty much exactly the behavior that I get - except that binary comparison, sizes and creation dates on my wixouts show beyond doubt that I haven't committed such a stupid, albeit very easy to make, mistake. -Original Message- From: Heath Stewart [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 12:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? The -val switch is actually to set transform validation flags and has nothing to do with validation during generation. See http://blogs.msdn.com/heaths/archive/2007/09/13/transform-validation-in-wix-patch-build.aspx for more information about that feature. Have you defined patch families in your patch authoring? If you don't or if you don't reference all the right fragments, the content of those fragments is ignored. You can find more information about patch families at http://blogs.msdn.com/pmarcu/archive/2007/04/27/wix-patchfamily-patch-filtering.aspx, http://blogs.msdn.com/heaths/archive/2007/05/08/patch-families-can-only-ever-grow.aspx, and http://blogs.msdn.com/heaths/archive/2008/01/14/patch-families-in-wix-and-windows-installer.aspx . On Thu, Jul 31, 2008 at 9:22 AM, Tony Juricic <[EMAIL PROTECTED]>wrote: > Are you saying that there is some way to get better error diagnostics > from Torch? > I added -v option for verbosity but it has no effect. > > In fact, I can't even figure out how do validation flags validate?! > > For example, once I run Torch with -val y, next time with -val v, > keeping the same wixout input files. I would expect some validation > error to be reported: I mean, update versions of my DLLs can't be both > larger and smaller than the target versions! > > However Torch reports no issues in either case, just silently outputs > wixmst file which, according to Pyro, contains 120 MB of nothing. > > I certainly have-p option which is essential according to Peter's blog. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2008 11:04 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version > number? > > There is a share proderrors or something > > > > Pete Yates > Senior Systems Developer > DDC - Distributed & Components Team > HBOS I&I IT > B/1/C/243 > (7725) 34383 / (0117) 376 4383 > [EMAIL PROTECTED] > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tony > Juricic > Sent: 31 July 2008 15:56 > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? > > I have 120 MB large Wixmst created by Torch and when I pass it to Pyro > it comes back with the message PYRO1079 saying that patch cabinet > contains no files. > > > > My DLLs in RTM and Update respectively differ in the last, 4-th version > number, plus the binaries themselves are different. Using SDK tools for > patch creation these DLLs would be updated when applying the patch. I > tested that long before I started using WiX and I am 100% sure that SDK > doesn't ignore fourth version number for file substitution rules. > > > > So I am wondering if Pyro is ignoring binary differences if first 3 > version numbers are the same? > > > > Patch.wxs content is the following: > > > > > > http://schemas.microsoft.com/wix/2006/wi";> > > various other attributes> > > > > > > > > > > > > > > > > > > ... a bunch of components follows > > > > > > > > > > > > Thanks > > > > > > > - > 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=/ > __
Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number?
If Pyro is not ignoring 4th version number then it must be that I am breaking some component rules?! I haven't added or removed or renamed any component file or guid but I have changed the target install directory name from MyProduct to MyProductV1 (to be created under Program Files folder). Could that be it? - 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] Does Pyro (or Torch) ignore 4-th version number?
I tried using it during patch application like: msiexec /update Patch.msp /lv*x .\install.log MSIENFORCEUPGRADECOMPONENTRULES=1 LOGVERBOSE=1 but reading the install.log I cannot find anything a bit more explicit about this violation. It is certainly not saying something like "you changed the name of your root installation folder and you shouldn't" :) -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 5:42 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? Tony Juricic wrote: > If Pyro is not ignoring 4th version number then it must be that I am breaking some component rules?! > I haven't added or removed or renamed any component file or guid but I have changed the target install directory name from MyProduct to MyProductV1 (to be created under Program Files folder). > > Could that be it? > Yes, that's a component rules violation. You can tell from a verbose log, by setting the MSIENFORCEUPGRADECOMPONENTRULES property to 1. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number?
It just goes to show how easy it is to commit gross component rules violations even after months of reading articles and blogs on component rules! However, it seems that I have also misunderstood the purpose of MSIENFORCEUPGRADECOMPONENTRULES property. I was under the impression that it would add to verbose log. I mean, if MSI *knows* that there is component violation, it would be of great help if it could add a sentence to the log saying at least something along the lines of: There is component rules violation of some sort! After reading all that I could find on MSIENFORCEUPGRADECOMPONENTRULES property I can't say that I am 100% sure about what is it that it really does? How can the consequences of having this property defined or not be seen on some practical example? I was certainly none the wiser in this specific case since verbose logs were identical with or without it, for all that I could see. It *seems* that a small update patch may be applied by MSI in some cases even if there was a component rule violation and this property prevents it. -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Saturday, August 02, 2008 1:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? Tony Juricic wrote: > but reading the install.log I cannot find anything a bit more explicit > about this violation. It is certainly not saying something like "you > changed the name of your root installation folder and you shouldn't" :) > Sorry, it's not that polite. The "Windows Installer Components" topic summarizes the magic of component rules with two bullets: In brief, these rules are: * Each component must be stored in a single folder. * No file, registry entry, shortcut, or other resources should ever be shipped as a member of more than one component. This applies across products, product versions, and companies. So changing the directory violates 50 percent of the component rules. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
