[WiX-users] Constants For Control Width
I defined control width constants in a .wxi file as such: ?xml version=1.0 encoding=utf-8? Include ?define TinyControlWidth = 36 ? ?define SmallControlWidth = 70 ? ?define MediumControlWidth = 110 ? ?define LargeControlWidth = 180 ? /Include I then included it in a .wxs file containing a dialog. I used one of the above constants for the width of a control on that dialog like this: Control Id=MyControl Type=ComboBox X=160 Y=56 Width=$(var.TinyControlWidth) Height=16 ... / It builds successfully. But, Visual Studio 2012 gives this warning: Warning1The 'Width' attribute is invalid - The value '$(var.TinyControlWidth)' is invalid according to its datatype 'http://schemas.microsoft.com/wix/2006/wi:LocalizableInteger' - The Pattern constraint failed. Is there a way to suppress this warning or a different/better way to use constants for control width, height, x, and y? Josh Davis -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom bundle-loader UI
So where can I find WIX's own installer? I read through the NAnt build and I can see where it makes a zip file, but I didn't see it calling WiX to generate the setup files Thanks! - Josh On Thu, Jul 19, 2012 at 6:11 PM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: Since you are talking about multiple MSI's, then the answer would be using WiX and Burn to generate your UI. I would start by looking at WiX's own installer for a basic example of writing a custom UX if you want it in .Net, or looking at the existing C++ StdBA if you don't want to have the dependency on the .Net framework. I'm confused by your API question as I don't know what it is that you are trying to do that you can't accomplish with off the shelf components. I'm fairly certain everything can be done without an IDE, but I question why you wouldn't want to at least install the Express versions of the IDE. WPF is an option for a UI, as is WinForms or even MFC; pick based on the experience and the features you need. Windows Installer documentation won't be a huge help with burn as burn is a layer around multiple installation packages, however the documentation will help you create the MSI's that you intend on installing as part of your bundle. Extensions and custom actions are two entirely different things. Extensions are used at link time for putting in the proper information to allow the MSI to accomplish tasks that are either difficult to do manually, or require a custom action to do something that windows installer itself doesn't support. Custom actions should be the last resort, as all the standard functionality is something MS test and ensures works across versions of Windows installer and Windows in general. Jacob -Original Message- From: Josh Suereth [mailto:joshua.suer...@gmail.com] Sent: Thursday, July 19, 2012 1:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Custom bundle-loader UI tl;dr; What environment do I need to create my own UI? First - Please don't laugh if I'm asking silly questions. I'm a Scala developer working on the JVM. I've been using WiX for a few months and it's a great tool! I was very happy to be able to use pure XML, and I drive my builds through our Scala build tool. It's been over 10 years since I looked at anything .NET, although I did a bunch of C++ a few years back. Now, the background: For our installer, we're aggregating a few open-source MSIs into a stack exe installer. The open-source MSIs should be able to co-exist with the stack, in the sense that if someone installs the OSS version, the stack should not replace it. I'm using WiX 3.6 for this, and while setting it up was amazingly simple, the uninstall behavior is confusing for users. SO - what do I need to research/learn to make my own API? Consider me a total n00b when it comes to Windows technology. I just need to find the right person in the company to help me with this, or spend some money on books. Can I use freely available windows tools to compile? Can I build things completely on the command-line? Should I be looking into WPF? I've started reading the WIndows Installer documentation. Do I need to know this to write my own UI? I have also read through the entire help included in WiX 3.6. It's pretty helpful, but for writing extensions it just shows how to set up a C++ extern function for the DLL. I'm not really sure what that function is supposed to *do*. Thanks! - Josh Suereth -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware
Re: [WiX-users] Custom bundle-loader UI
Great, so the answer to the question I was really asking is, VS express. I need something I can go deploy out to our build servers to run these builds, or that our OSS community can download/use if they wish to help make patches. As far as custom UIs go, I'll check out the WiX installer itself and see if I have more questions, as well as looking into Burn. So far I've only used candle/light and pure XML. Thanks for the responses! Now I have a better clue what to actually ask/investigate! - Josh On Thu, Jul 19, 2012 at 6:11 PM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: Since you are talking about multiple MSI's, then the answer would be using WiX and Burn to generate your UI. I would start by looking at WiX's own installer for a basic example of writing a custom UX if you want it in .Net, or looking at the existing C++ StdBA if you don't want to have the dependency on the .Net framework. I'm confused by your API question as I don't know what it is that you are trying to do that you can't accomplish with off the shelf components. I'm fairly certain everything can be done without an IDE, but I question why you wouldn't want to at least install the Express versions of the IDE. WPF is an option for a UI, as is WinForms or even MFC; pick based on the experience and the features you need. Windows Installer documentation won't be a huge help with burn as burn is a layer around multiple installation packages, however the documentation will help you create the MSI's that you intend on installing as part of your bundle. Extensions and custom actions are two entirely different things. Extensions are used at link time for putting in the proper information to allow the MSI to accomplish tasks that are either difficult to do manually, or require a custom action to do something that windows installer itself doesn't support. Custom actions should be the last resort, as all the standard functionality is something MS test and ensures works across versions of Windows installer and Windows in general. Jacob -Original Message- From: Josh Suereth [mailto:joshua.suer...@gmail.com] Sent: Thursday, July 19, 2012 1:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Custom bundle-loader UI tl;dr; What environment do I need to create my own UI? First - Please don't laugh if I'm asking silly questions. I'm a Scala developer working on the JVM. I've been using WiX for a few months and it's a great tool! I was very happy to be able to use pure XML, and I drive my builds through our Scala build tool. It's been over 10 years since I looked at anything .NET, although I did a bunch of C++ a few years back. Now, the background: For our installer, we're aggregating a few open-source MSIs into a stack exe installer. The open-source MSIs should be able to co-exist with the stack, in the sense that if someone installs the OSS version, the stack should not replace it. I'm using WiX 3.6 for this, and while setting it up was amazingly simple, the uninstall behavior is confusing for users. SO - what do I need to research/learn to make my own API? Consider me a total n00b when it comes to Windows technology. I just need to find the right person in the company to help me with this, or spend some money on books. Can I use freely available windows tools to compile? Can I build things completely on the command-line? Should I be looking into WPF? I've started reading the WIndows Installer documentation. Do I need to know this to write my own UI? I have also read through the entire help included in WiX 3.6. It's pretty helpful, but for writing extensions it just shows how to set up a C++ extern function for the DLL. I'm not really sure what that function is supposed to *do*. Thanks! - Josh Suereth -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom bundle-loader UI
tl;dr; What environment do I need to create my own UI? First - Please don't laugh if I'm asking silly questions. I'm a Scala developer working on the JVM. I've been using WiX for a few months and it's a great tool! I was very happy to be able to use pure XML, and I drive my builds through our Scala build tool. It's been over 10 years since I looked at anything .NET, although I did a bunch of C++ a few years back. Now, the background: For our installer, we're aggregating a few open-source MSIs into a stack exe installer. The open-source MSIs should be able to co-exist with the stack, in the sense that if someone installs the OSS version, the stack should not replace it. I'm using WiX 3.6 for this, and while setting it up was amazingly simple, the uninstall behavior is confusing for users. SO - what do I need to research/learn to make my own API? Consider me a total n00b when it comes to Windows technology. I just need to find the right person in the company to help me with this, or spend some money on books. Can I use freely available windows tools to compile? Can I build things completely on the command-line? Should I be looking into WPF? I've started reading the WIndows Installer documentation. Do I need to know this to write my own UI? I have also read through the entire help included in WiX 3.6. It's pretty helpful, but for writing extensions it just shows how to set up a C++ extern function for the DLL. I'm not really sure what that function is supposed to *do*. Thanks! - Josh Suereth -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSI detected as virus.... RunOnce registry keys
I'm still getting more bug reports from users about this, even with our caveat/known issues... On Fri, May 25, 2012 at 8:17 PM, imran i_a_pa...@hotmail.com wrote: Did anyone resolve this issue? I am getting the same problem in Windows XP. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-detected-as-virus-RunOnce-registry-keys-tp7409683p7577248.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSI detected as virus.... RunOnce registry keys
Thanks guys! I feed some info back to the customer and am trying to get more details. We provide a zip version of the install that requires manual setup. He's using that as a workaround for now. I'll let you know if I learn anything more, but it sounds like we just won't support Trend's aggressive setting. - Josh On Tue, Mar 27, 2012 at 10:28 AM, Peter Hull peterhul...@hotmail.comwrote: This has been seen before and reported as a bug: http://sourceforge.net/tracker/?func=detailaid=3431068group_id=105970atid=642714 I believe it only affects Windows XP - is that what your customer has? I don't think there is a workaround. According to Trend's documentation, signed executables should be OK but they don't seem to be. If you have any contacts at Trend I would ask them! Peter -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] MSI detected as virus.... RunOnce registry keys
Hey everyone!
I'm getting the following issue reported from a user:
I tried to install the typesafe stack at work, but the virus checker
software we use (Trend Micro OfficeScan) blocked the installer.
I think the problem is that the installer uses registry key
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\{blabla...}.
RunOnce registry keys cause programs to run each time that a user logs on.
Is this a standard part of any WiX generated MSI or am I doing something to
cause this? I can link to all of the installer projects, since they're
all open source if that helps!
Thanks much!
- Josh
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundled MSI branding
AH! My image was much larger. It was truncating at 64x64 I think. I just shrunk down to 64x64 and it shows up correctly. Thanks much! On Mon, Jan 30, 2012 at 10:47 AM, ACKH forforumh...@hotmail.com wrote: My logo is 64 x 64 pixels, RGB color without transparency, safed as png -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundled-MSI-branding-tp7228010p7236961.html Sent from the wix-users mailing list archive at Nabble.com. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundled MSI branding
Thanks. I'll start manipulating the image. On Sun, Jan 29, 2012 at 8:22 AM, ACKH forforumh...@hotmail.com wrote: Hi I noticed that wixstdba does not support png files that utilize transparency, i.e. the transparent pixels are just black, not the color of the background. As soon as I changed the background color of my custom logo png to white the image looked like I wanted it. Besides this I discovered no other limitations. Hope this helps Regards, ACKH -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundled-MSI-branding-tp7228010p7234328.html Sent from the wix-users mailing list archive at Nabble.com. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundled MSI branding
What size is your logo? I'm still not seeing my logo anywhere. - Josh On Sun, Jan 29, 2012 at 11:00 PM, Josh Suereth joshua.suer...@gmail.comwrote: Thanks. I'll start manipulating the image. On Sun, Jan 29, 2012 at 8:22 AM, ACKH forforumh...@hotmail.com wrote: Hi I noticed that wixstdba does not support png files that utilize transparency, i.e. the transparent pixels are just black, not the color of the background. As soon as I changed the background color of my custom logo png to white the image looked like I wanted it. Besides this I discovered no other limitations. Hope this helps Regards, ACKH -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundled-MSI-branding-tp7228010p7234328.html Sent from the wix-users mailing list archive at Nabble.com. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bundled MSI branding
Hey everyone, I'm trying to build a bundled installer from several MSIs. I'm using the branding instructions here: http://wix.sourceforge.net/manual-wix3/wixstdba_branding.htm. The resulting logo is appearing very boxish and completely black (i.e. looks like it's not reading my png). Do I need to format my PNG in anyway for the default bundler UI? Thanks! - Josh -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WIX - Issue with filenames that have two $$ in them.
Hi everyone! I'm trying to bundle up Scala's documentation using WIX. Right now, the light program is exiting with error LIGHT0083 that it can't find the files I'm bundling. I have a file named Utility$$Escape$.html and it's printing in the error message that its source path is Utility$Escape$.html Is there some kind of escape character I can use for $ in WIX? I tried using #23; and that did not work. It appears to be truncating that one $ off the name, and this is killing the bundle. Thanks for the help, and wonderful product. I love using it. - Josh -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WIX - Issue with filenames that have two $$ in them.
Actually, I caught the pre-processor docs. Replacing every $ with $$ works. I just had to get my regex replacement correct. Sorry for the bum email. - Josh On Wed, Jan 25, 2012 at 9:36 PM, Bob Arnson b...@joyofsetup.com wrote: On 25-Jan-12 11:46, Josh Suereth wrote: I'm trying to bundle up Scala's documentation using WIX. Right now, the light program is exiting with error LIGHT0083 that it can't find the files I'm bundling. I have a file named Utility$$Escape$.html and it's printing in the error message that its source path is Utility$Escape$.html Oops. Yeah, please open a bug on SourceForge. -- sig://boB http://joyofsetup.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] performance counters are not being uninstalled
Thanks for the response. Here is what I found in the verbose uninstall log.
The guids match the guids for my performance counter components in wix. I
assume the message means that some other program or component on the computer
is referencing the performance counters, causing them to remain installed. Is
that correct? Is there any way in WIX to override this feature and force them
to uninstall?
MSI (s) (D4:60) [14:56:46:663]: Disallowing uninstallation of component:
{06E78A14-9297-49C0-8A41-52A686BCE5CE} since another client exists
MSI (s) (D4:60) [14:56:46:663]: Disallowing uninstallation of component:
{C20FBE98-FEE7-4C46-8617-73C60D2C7CC2} since another client exists
...
MSI (s) (D4:60) [14:56:46:694]: Component: perfCounters; Installed: Local;
Request: Absent; Action: Null
Joshua Holm
AdECN
805-566-2645
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Wednesday, September 23, 2009 2:00 PM
To: 'General discussion for Windows Installer XML toolset.'; Josh Holm
Cc: Peter Moresi; Aaron Allin
Subject: RE: [WiX-users] performance counters are not being uninstalled
When uninstalling, what does a verbose log say about the states of the
perfCounters component (look around CostFinalize in the log).
-Original Message-
From: Josh Holm [mailto:joh...@microsoft.com]
Sent: Wednesday, September 23, 2009 1:27 PM
To: wix-users@lists.sourceforge.net
Cc: Peter Moresi; Aaron Allin
Subject: [WiX-users] performance counters are not being uninstalled
I have a wix project that installs performance counters using the
util:PerformanceCategory and util:PerformanceCounter elements. The
performance counters are installed as expected. However, when uninstalling,
the performance counters are sometimes left installed on the machine.
Here is an example of the pattern we are using:
Component Id='perfCounters' Guid='C0D623E8-F04C-48A7-9F2D-5F996891AE24'
KeyPath='yes'
util:PerformanceCategory Id=PerfCounterCategory
Name=ProductPerfCounters MultiInstance=yes
util:PerformanceCounter Name=Requests per second
Type=rateOfCountsPerSecond64 /
util:PerformanceCounter Name=Request count
Type=numberOfItems64 /
/util:PerformanceCategory
/Component
Does anyone know why the performance counters are left installed sometimes?
Is there a way to 'force' them to be uninstalled using wix?
Joshua Thor Holm
SDE | AdECN | Microsoft
805-566-2645 | joh...@microsoft.com
--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
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] performance counters are not being uninstalled
I have a wix project that installs performance counters using the util:PerformanceCategory and util:PerformanceCounter elements. The performance counters are installed as expected. However, when uninstalling, the performance counters are sometimes left installed on the machine. Here is an example of the pattern we are using: Component Id='perfCounters' Guid='C0D623E8-F04C-48A7-9F2D-5F996891AE24' KeyPath='yes' util:PerformanceCategory Id=PerfCounterCategory Name=ProductPerfCounters MultiInstance=yes util:PerformanceCounter Name=Requests per second Type=rateOfCountsPerSecond64 / util:PerformanceCounter Name=Request count Type=numberOfItems64 / /util:PerformanceCategory /Component Does anyone know why the performance counters are left installed sometimes? Is there a way to 'force' them to be uninstalled using wix? Joshua Thor Holm SDE | AdECN | Microsoft 805-566-2645 | joh...@microsoft.com -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] WiX contractors?
Hi all -- I'm looking for someone to help us out with building a WiX installer that we can use for multiple applications at my company. I've already figured out enough WiX to copy files into the right place, and that's working, but we need to go a little further. It's all spec'd out and there's nothing too crazy involved (show a EULA, allow the user to opt-in to things, uninstall previous copies of the product automatically, etc). I'm hoping it's a weekend of work for someone who knows what they're doing. I'd like to get this done by the end of the month. If this is something you think you could help out with, please reply off-list. Thanks! -- s t i m u l a n t / Josh Santangelo, Technical Lead P 206 229 5674 / O 415 255 7081 / F 815 550 1203 / W http://stimulant.io -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ServiceInstall not removing service?
Thanks for the reply Chad. I have the Remove=uninstall set in the ServiceControl any other thoughts as to why it wouldn't remove the service on uninstall? I've included the relevant wxs below. Thanks Josh Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLLOCATION Name=WixProjectWindowsService Component Id=MyWiXServiceComponent Guid=21945E51-F096-46d7-8E09-43443D092391 File Id=WindowsService Name=$(var.WindowsService1.TargetName) Source=$(var.WindowsService1.TargetPath) / File Id=ClassLibrary Name=$(var.ClassLibrary1.TargetName) Source=$(var.ClassLibrary1.TargetPath) / ServiceInstall Id=MyWindowsServiceId Name=MyWindowsServiceName DisplayName=MyWindowsServiceDisplayName Type=ownProcess Start=auto ErrorControl=normal Description=This is a test service that only logs to the event log. Account=[SERVICEACCOUNT] Password=[SERVICEPASSWORD] / ServiceControl Id=StartWixServiceInstaller Name=WixServiceInstaller Start=install Wait=no / ServiceControl Id=StopWixServiceInstaller Name=WixServiceInstaller Stop=both Wait=yes Remove=uninstall / /Component /Directory /Directory /Directory Feature Id=ProductFeature Title=WixProjectWindowsService Level=1 ComponentRef Id=MyWiXServiceComponent / /Feature -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Wednesday, April 01, 2009 1:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstall not removing service? Hi Josh - Attachments don't come through on the mailing list, but I think you just need to add a ServiceControl element with a Remove=uninstall attribute. Check it out and see if that helps. Chad -Original Message- From: Josh Pepper [mailto:josh.pep...@microsoft.com] Sent: Wednesday, April 01, 2009 10:22 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ServiceInstall not removing service? Hi folks - I just made a very simple Hello World service install with ServiceInstall. It installed fine. But when I uninstalled, the service itself remained, despite the fact that the service exe was removed. It seems to be that the service should have been removed, or the MSI should have failed... I thought vital defaults to Yes, right? Or is that just for File? I've included my wxs file Thanks Josh -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using WiX to create a simple website under IIS
I have an application which is both a desktop app and a web app which runs locally. I've created a couple of basic WiX installers, but haven't yet used the IIS extension to create a virtual directory under IIS. I haven't been able to find a simple example of how to do this. All I need to do is create the virtual directory, set its port, and point it at a real directory which I'm creating with the rest of the installer. A bonus would be enabling IIS on the machine if it's not already enabled, but I'm guessing that's not possible, and isn't a dealbreaker for me anyway. If it matters, this installer will only be run on Vista machines. -- s t i m u l a n t / Josh Santangelo, Technical Lead P 206 229 5674 / O 415 255 7081 / F 815 550 1203 / W http://stimulant.io -- 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] Multiple Instance Transforms Walkthrough, Proposed Simple Addition to WiX to Make Them Easier
Shawny, I apologize for not seeing this post earlier. The wix-users list is pretty high-traffic. Unfortunately, I can't follow up completely right now because the whole file is proprietary to my company. I am, however, slowly working on some stuff which I will be release as open source probably around March. In the end, I built an extension against Wix 3.0.4102, which allows multiple extensions at the compile and bind stages, that implements a custom boolean attribute on a component called instance-transforms:Private (see usage below). The compiler extension class creates a new table called InstanceTransforms_PrivateComponents, and adds each private component to that table. A binder extension generates Component transform rows using a deterministic guid-changing algorithm (the same used internally by WiX for generating component guids, based on the UUID generation algorithm) in each embedded transform for each row joined from the WixInstanceTransforms table to the InstanceTransforms_PrivateComponents table. This extension replaces the proposed WiX change; in WiX 4102 I would have needed to change WiX, but at WiX 4102 it permitted multiple extensions to be loaded simultaneously, thus allowing my extension to coexist with other extensions. I use a loop over a predefined set of instance ids while ?include?-ing a per-instance file to generate the raw data in the .MSI file. Please note that I had to strip some things from these sources so it may not compile. Then other files specify instance-transforms:Private when they have private non-file data. The result is an MSI that when installed via the GUI automatically installs the next available instance id. InstanceTransforms.wxi: ?xml version=1.0 encoding=utf-8? Include xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:instance-transforms=http://XXX.com/wix/InstanceTransforms.xsd; !-- This property contains the instance id. If its value is Invalid, then this instance should NOT be installed! -- Property Id=InstanceId Value=Invalid / !-- We need some instance transforms. Twent-five oughtta do it. If you add or delete from this list, also add or delete from the foreach loop below. -- InstanceTransforms Property=InstanceId Instance Id=InstanceId01 ProductCode=xxx/ Instance Id=InstanceId02 ProductCode=xxx/ Instance Id=InstanceId03 ProductCode=xxx/ Instance Id=InstanceId04 ProductCode=xxx/ Instance Id=InstanceId05 ProductCode=xxx/ Instance Id=InstanceId06 ProductCode=xxx/ Instance Id=InstanceId07 ProductCode=xxx/ Instance Id=InstanceId08 ProductCode=xxx/ Instance Id=InstanceId09 ProductCode= xxx / Instance Id=InstanceId10 ProductCode= xxx / Instance Id=InstanceId11 ProductCode= xxx / Instance Id=InstanceId12 ProductCode= xxx / Instance Id=InstanceId13 ProductCode= xxx / Instance Id=InstanceId14 ProductCode= xxx / Instance Id=InstanceId15 ProductCode= xxx / Instance Id=InstanceId16 ProductCode= xxx / Instance Id=InstanceId17 ProductCode= xxx / Instance Id=InstanceId18 ProductCode= xxx / Instance Id=InstanceId19 ProductCode= xxx / Instance Id=InstanceId20 ProductCode= xxx / Instance Id=InstanceId21 ProductCode= xxx / Instance Id=InstanceId22 ProductCode= xxx / Instance Id=InstanceId23 ProductCode= xxx / Instance Id=InstanceId24 ProductCode= xxx / Instance Id=InstanceId25 ProductCode= xxx / /InstanceTransforms !-- We need a component to represent the installed state of the instance. We can later detect the installation state of this component to determine whether or not the particular instance exists. -- DirectoryRef Id=InstallDirectory Component Id=InstalledStateMarker Guid=xxx instance-transforms:Private=yes --- This is my addition to WiX RegistryValue Id=Registry.InstalledStateMarker Root=HKLM Key=[InstallKey] Name=[InstanceId] Type=string Value=[_NAME] / /Component /DirectoryRef !-- For each instance id, generate custom actions, properties, registry searches, etc., for that instance. Doing it this way cuts down on a large amount of duplication of code. -- ?foreach InstanceId in 01;02;03;04;05;06;07;08;09;10;11;12;13;14;15;16;17;18;19;20;21;22;23;24;25? ?include DefineInstanceTransform.wxi? ?endforeach? !-- This custom action sets the MSINEWINSTANCE property if we are installing. -- CustomAction Id=SetMsiNewInstance Property=MSINEWINSTANCE Value=1 / !-- This custom action sets the TRANSFORMS property to include the instance transform. It must be run after the SetInstanceId01 action to guarantee that InstanceId is already set. -- CustomAction Id=SetTransforms Property=TRANSFORMS
Re: [WiX-users] yep - back to being 100% frustrated
Mike, The way I approach this is to provide an extra feature to install the database scripts using the various defaults, but always to install the database scripts and installation options whether or not that feature is requested. Alternatively, I provide a Database scripts feature and a child Install the database scripts feature. A number of corporations have exactly the same beef you do, but we can't just fall back to requiring DBAs to edit scripts. The real problem with SQL scripts is their lack of a decent conditional execution environment. Sure, you can code the scripts with sp_executesql all over the place. This loses all the nice editor support available for SQL. So, because CREATE PROCEDURE must be the only statement in a batch, you lose conditional creation. Bah! Even with all this, you can't even get arguments into the damn SQL scripts in a simple-to-use way that is also standard across execution environments. It's insane that people still have to write their own code to separate SQL scripts into GO-keyword-separated batches. We really need a standard SQL installer framework that does the following things: * Create a database * Create each schema object * Upgrade each schema object if it already exists If there was a standard pattern (or better yet, library) to do this, then all the things you bring up could be addressed in this framework. jmr From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Friday, May 16, 2008 11:30 PM To: 'Tanikella, Rajanikanth (SCR US)'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] yep - back to being 100% frustrated ...cut... With my database administrator's hat on, I find applications that install their own databases tiresome. They inevitably seem to make mistakes in their installers. Reporting Services service packs don't quite line up with schema versions, so you seem to end up scrapping the existing database and recreating. SourceGear's Vault accidentally inserted a backslash before the data file name when there was already one at the end of the path, then SQL Server's Volume Shadow Copy Writer complained when trying to back that database up. Other tools don't give the administrator the option of where to place the database - any sensible SQL Server setup (not dedicated to a single database) will want to place the data files on a disk separate from any other files, and the log files on further separate disks, so the 'default' DB location may well not be useful. Given the amount of flexibility required, you may well want to just supply scripts and allow the DBA to run them after creating databases themselves, and that's the approach we're taking (the application server supports server farms with a SQL Server database for shared state). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
Actually, I'm not saying that at all. I'm just suggesting that these problems should be solved up front because they are difficult to solve. I'm also saying that by trying to solve deployment problems up front you may be able to successfully influence the architecture of an application to not include technologies that are ultimately difficult to use. If you wait to solve these problems until the last possible second then you will not be able to successfully influence the architecture of an already-implemented, working solution. The key point is that the deployment of a solution is very much part of the solution itself, and if that happens to be the risky part of a project then it should be tackled first. That's just good project / risk management. If you want to influence an upstream architect, you have to do so before the software has solidified. If you believe strongly enough that MSI or deployment in general is difficult, you should work on that part of the project first with one goal to influence the design to be easily deployable. When you don't have a choice, do what Christopher Painter says. I've had to write CAs for MSI, too. Because of those experience, when given the choice of writing CAs or changing the software to not require the CAs, I change the software. jmr From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Wednesday, May 14, 2008 10:06 AM To: Neil Sleightholm; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] yep - back to being 100% frustrated I think they are. Everytime you hear things like `solve the applicartion problem`, `custom actions are an admission of failure`, `we won't implement that feature`, `There are few setup experiences more stable than an application that simply needs a bunch of files installed`, I believe that very notion is being implied. On one hand I understand why you'd say it, and in theory I agree with it. But in practice it's not possible. The reality is even if you are lucky enough to be in a shop where the developers/architects believe that their design choices should be guided by integration ( read build/install ) implications, they rarely have the specialized domain knowledge to know what those implications are because they usually never touched a build or an install while they were cutting their programming teath.Setup is rarely taught, it's not included in books, it's not included in certifications and if you offer up a lecture at work or at a code camp you won't get anyone to come. The reality is they are much more interested in discussing the merits ofthe latest new thing. ( Agile, Scrum, ALT.NET, WCF, WPF, SliverLight, DSL's are very popular topics at my local DNUG ... no one is interested in MSI ). So from my perspective, I try to influence upstream design decisions but when it doesn't happen the way I'd like, I do what all good Marines do: Adapt and Overcome. Neil Sleightholm [EMAIL PROTECTED] wrote: In any reasonably professional shop you can't just say hey, MSI doesn't support doing that, we just can't have that in our application!. I don't think anyone was suggesting that but if you new it would need a custom action, for example, you could either not do it that way or schedule in writing one. Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
Agreed. Software Engineering is many times about risk management. Many projects leave understanding the deployment model of an application until just before it ships, and then because MSI often isn't well understood and the product wasn't written to work well with MSI people run into problems that cause the ship date to fall back because of an installer issue. If you reverse it, and do the install up front, this allows you to make updating the installer a development responsibility and include the install in your integration test suite. Doing an MSI integration test is trivially easy: just spawn the MSIEXEC.EXE process passing your .msi file and properties w/o a GUI in the way (msiexec /i x.msi /quiet ADDLOCAL=features MYPROPERTY=1 MYOTHERPROPERTY=2 is what I'm using, I think). Now, if a developer breaks the install, your automated tests should pick that up and that developer can fix it long before the ship date. Re. COM+ etc, I ran into exactly that problem and ended up writing a whole CA system in MSI to deploy our 20+ COM+ applications at my last job. It took weeks of effort to write deployment operations for our applications. We started with .vbs and .zip files, but soon progressed to needing the full functionality of MSI. It turns out that MSI really is quite simple, as long as you work within what it does well from the beginning rather than trying to back-port your existing application to be installed via MSI. We would have chosen a different software model that would have cost a little more coding time but a lot less deployment effort time if we had spent the time to understand the deployment model up front. The moral of the story is that deployment procedures really are part of the source code for an application. They are also risky, so implement them first to minimize risk. jmr From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm Sent: Tuesday, May 13, 2008 12:51 PM To: Scott Palmer; WiX Users Subject: Re: [WiX-users] yep - back to being 100% frustrated As this was my comment I thought I should respond. I believe you should write the install then the code - if you can't install it, don't code it. That's simply not the way it works, and that isn't going to change. I get where you are coming from though... the general installation layout of the product does need to be understood sooner rather than later. The reason that the installer isn't done first or in parallel with other development is simple - everyone hates it. Getting anyone to do it is like pulling teeth. Nobody on the team wants to be the installer guy, for good reason. (There is also the fact that it is intuitively backwards to write an installer for something that doesn't exist yet.) I like doing installs! I know it is a bit flippant to say write the install first but in my experience no one considers the install when choosing the latest and greatest development code. If they did (and I feel Microsoft is to blame here) they wouldn’t touch a lot of the technologies. COM+ was never properly supported for installs, moving up to date some of the WFP stuff is incredibly completed to configure. SQL server it still not properly scriptable without writing you own code. I don’t think it is intuitively backwards to write an installer first – my analogy is – hydrogen powered cars might be a good idea but if you can’t buy hydrogen or aren’t going to put the infrastructure in place there is no point building them. I think the same is true of code, make sure you can deploy it before you write any code. Together we can make it happen ☺ Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
Scott, I actually agree with you. Deployment SHOULD be trivial. It's usually risky and non-trivial because people tend to write programs that require special steps during deployment. By understanding the desired deployment model up-front you reduce the tendency to write software that operates with complex deployment models. If you want a deployment model that is a simple file copy, make sure your software doesn't require any more registration and deployment activities than simple file copies. Then, your WiX file becomes a simple list of components and files, maybe a feature or two. On the other hand, if your deployment steps require a lot of registration, feature choices, etc., those facts will be apparent from the increased complexity of the source code that represents those deployment steps. As people modify the software, they are responsible for understanding how they are changing the deployment model. Every piece of software has a deployment model. Somewhere, someone had to decide how software should be structured, how third party products integrate with a parent product, etc. When the base platform you are installing onto requires complicated deployment steps, I guess you're just screwed. Especially when things come up like: Icon files that are associated strictly with file extensions or CLSIDs can have any extension, such as .ico. However, Icon files that are associated with shortcuts must be in the EXE binary format and must be named such that their extension matches the extension of the target. The shortcut will not work if this rule is not followed. For example, if a shortcut is to point to a resource having the key file Red.bar, then the icon file must also have the extension .bar. Multiple icons can be stuffed into the same icon file as long as all of the target files have the same extension. I assume this is the madness you were referring to. Probably, this has more to do with how explorer works than with how MSI works, I don't really know. I do think that it is pathetic to not consider a technology for the development of an application because you can't write the installer for it. But instead of blaming WiX or MSI, I blame the author of the technology. If the developer of that technology made good decisions about how to deploy software that uses that technology, you wouldn't be forced into making those hard choices. For example, if COM+ registration was as simple as copying a .xml file to a specific directory, deployment of COM+ applications would be simple and none of us would be moaning about it. But the authors of the COM+ technology didn't consider how its clients would actually go about deploying a COM+ application or a whole suite of COM+ applications. Therefore, COM+ deployment sucks because MS didn't come up with a good story for it, not because MSI or WiX didn't handle it. This begs me to ask: why does the installer suck when people just wrote bad software? If all software followed simple file-based deployment models, would MSI still suck? I'm not sure that it would. If explorer shortcut files didn't use some crappy proprietary format would they be nearly as difficult to get installed? Probably not. But the explorer team didn't consider how deployments should work when writing explorer. Of course, hindsight is always 20/20, and it's really only recently that people are really paying much attention to deployment of software as compared to authoring it in the first place. For your own software: learn from MS's mistakes and don't write it the same way. jmr From: Scott Palmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 13, 2008 2:58 PM To: Josh Rowe Cc: WiX Users Subject: Re: [WiX-users] yep - back to being 100% frustrated On Tue, May 13, 2008 at 1:26 PM, Josh Rowe [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: snip The moral of the story is that deployment procedures really are part of the source code for an application. They are also risky, so implement them first to minimize risk. This is the problem. Deployment SHOULD be trivial. That it is a risky part is outrageous. Shouldn't the hard part be in your application's algorithms rather than how to install it? (Your statement also ignores the fact that there is risk in other parts of the development - should those parts also be done first to minimize risk? :-) ) Saying it's risky is fine to justify the point that installers should be dealt with sooner in the development process - Given the current state of installer technology I must sadly agree. But it belittles the fact that the installer technology sucks so bad and is the root problem that needs fixing. Am I the only one that thinks it is somewhat pathetic to not consider a certain technology for the development of my application because I wont' be able to write the installer? Doesn't that just say that A: the technology to be installed (e.g. COM+), and B: the installer technology
Re: [WiX-users] pre-defined variables?
How are you building the solutions? Can you wrap the whole thing in a new Ms build file and use that to control the variables to which you are trying to gain access? Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mark.modrall Sent: Tuesday, January 29, 2008 3:49 PM To: Tanikella, Rajanikanth (SCR US); wix-users@lists.sourceforge.net Subject: Re: [WiX-users] pre-defined variables? Thanks, Raj... That's a big help... Seems like I've inherited something that's done a bit backwards, though. The person who put the stuff together (long since departed) put the wix projects in a separate solution from the actual build, and I've been trying to figure out how to get them to communicate better. For example, if the build was done /rebuild Debug, I'd like to /rebuild Debug on the Wix solution as well (and then be able to discover the Debug from the pre-processor variables. From what I see here, almost all of the variables in the table presume the source project and the wix project live in one solution and the wix project has a reference to the source project. That organization (all steps in one solution) makes a certain amount of sense but it's not what I was handed. The ball of wax I've got simply takes an environment variable to say where the source solution deposited it's product and then goes over and picks the files for packaging in the msi. At the moment, the wix solution simply presumes /bin/Release/* for all product files, regardless of how either build is being run. Thanks Mark -Original Message- From: Tanikella, Rajanikanth (SCR US) [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 5:27 PM To: mark.modrall; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] pre-defined variables? Hi Mark, One reference I happened upon has a small table of Votove pre-processor variables: http://msdn2.microsoft.com/en-us/library/aa302186.aspx The table is about half-way down the scroll. Hope it helps. Raj -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mark.modrall Sent: Tuesday, January 29, 2008 5:20 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] pre-defined variables? Thanks, Julie... I was referring more the Wix pre-processor (the variables that exist when running Wix to build the msi). http://wix.sourceforge.net/manual-wix2/preprocessor.htm describes the basic structure and 1 or 2 pre-defined variables but is obviously not complete. After googling for a long time, I saw some people referencing $(var.Platform) as pre-defined, for example. I plugged that in my .wxs and didn't see an undefined var error. But there's no documentation I've found anywhere that says $(var.Platform) should/will exist. And drawing from the Visual Studio model, I was wondering if analogs to $(OutDir), $(ConfigurationName), etc exist since an analog for $(PlatformName) does. I tried $(var.Config), $(var.Configuration), $(var.ConfigurationName) but none of those names were recognized. Thanks Mark -Original Message- From: Julie Campbell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 5:11 PM To: wix-users@lists.sourceforge.net; mark.modrall Subject: RE: [WiX-users] pre-defined variables? Mark, My favorite trick is to run an existing or very basic .msi with full logging. Then you can search the log file for Property(C) and/or Property(S). To run with full logging, run from a command line: MyMsi.msi /lv*x MyMsiLog.txt There is also actual documentation: http://msdn2.microsoft.com/en-us/library/aa370905.aspx http://msdn2.microsoft.com/en-us/library/aa372057.aspx And a place I've been collecting information: http://wix.mindcapers.com/wiki/WiX_Properties Julie Campbell [EMAIL PROTECTED] -- Message: 2 Date: Tue, 29 Jan 2008 13:16:16 -0500 From: mark.modrall [EMAIL PROTECTED] Subject: [WiX-users] pre-defined variables? To: wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hi... I've been googling around to find a list of pre-defined variables that exist in Wix (any pre-existing $(var.) or $(env.) like VS has $(outdir), $(configurationname), etc), but so far no luck. Does such a reference exist? thanks mark _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com _ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https
Re: [WiX-users] Launching MSI from MSI
Hi Graham, I am a newbie here, but I don't think the bootstrapper items go in the wixproj. I am doing something similar to you, but packaging the smo prereqs using the same bootstrapper as a separate process. I build my application with wix, then use the bootstrapper utility to run the prereq msis (checks if already existing) and then install my app. In order to install the prereqs though, I had to create a package for each one and put the package in the packages folder at: Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper\Packages\ Then I just create my bootstrapper using msbuild, not wix. Here is my first sample build file for my bootstrapper: Project xmlns=http://schemas.microsoft.com/developer/msbuild/2003; ItemGroup BootstrapperFile Include=Microsoft.Net.Framework.2.0 ProductNameMicrosoft .NET Framework 2.0/ProductName /BootstrapperFile BootstrapperFile Include=Microsoft.MSXML.6.0 ProductNameMS XML 6/ProductName /BootstrapperFile BootstrapperFile Include=Microsoft.Sql.NativeClient ProductNameSql Native Client/ProductName /BootstrapperFile BootstrapperFile Include=Microsoft.SqlServer.2005.XMO ProductNameSMO Tools/ProductName /BootstrapperFile /ItemGroup Target Name=BuildBootstrapper GenerateBootstrapper ComponentsLocation=Relative ApplicationFile=my.msi ApplicationName=my app name BootstrapperItems=@(BootstrapperFile) OutputPath=.\output / /Target /Project There are sample packages in the folder already, but let me know if you want to see one of mine. Hope this helps, josh Josh Maletz [EMAIL PROTECTED] From: Graham Vickrage [EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 11:01 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Launching MSI from MSI Thanks for the advice to use a bootstrapper to achieve the below. Having decided to do this I am now trying to add the correct commands to the wixproj file. Below I am trying to install postgresql-8.2-int.msi before my own msi. However it doesn't know where to find the postgresql-8.2-int.msi file despite me putting it in every place I can think of including C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper. It seems this has to be created as a package in its own right, which after following MS instructions does not work because I am working off a wix project file rather than a standard VS2005 one. I feel as if I'm missing the point here as it seems extremely complex to achieve a simple process of installing one msi after another. Does anyone have any tips or examples that are doing something similar, as the ones I have seen are only working with standard prerequisites and not necessarily with a wix project. postgresql-8.2-int.msi Call Manger
Re: [WiX-users] Multi-file assembly problem
Have you tried putting them in separate components or just using the CopyFile element? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: Thursday, December 06, 2007 6:16 PM Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Multi-file assembly problem Yes, I'm creating the manifests myself. Or rather I'm taking the automatically generated manifests, modifying them if necessary, and signing them by hand using mt.exe, makecat and signtool. I started out with manifest dependencies in DLL1 for DLL2 and DLL3, but that doesn't help with a LoadLibrary call, which expects to load the files directly. (I could remove the LoadLibrary call, but the results of that are passed on to a couple different functions, which pass results on to a couple different functions, and in the end ripping it out would directly or indirectly effect a lot of the code.) Putting the multiple file references into a single manifest file was what I was trying at the end of the original email. If I embedded the manifest back into the DLL1 file then Wix threw an error on installation. If I just left the original unmodified manifest in the DLL1 file then all the files get installed to the correct place, but then the program can't locate DLL1 anymore. It seems like I may need to do something differently with the manifest embedding for multifile assemblies, but I'm not sure what. The _simple_ solution would be finding a way to just force Wix to copy the files over without futzing about with the manifests any more than I already have. On Dec 6, 2007 4:58 PM, Kelly Leahy [EMAIL PROTECTED] wrote: Are you creating the manifest yourself? You should be able to create a manifest that has dependency references in it for DLL2 and DLL3... See the dependency and dependentAssembly tags in Manifest reference: http://msdn2.microsoft.com/en-us/library/aa374219.aspx It also looks like you can put multiple files in a single 'assembly manifest', but I don't know how to get WiX to install them. I still don't understand why your LoadLibrary works when you have the files in the same folder though - I'd be curious to see what GetModuleFileName returns on those modules. Kelly Geoff Finger [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/06/2007 04:29 PM To wix-users@lists.sourceforge.net, [EMAIL PROTECTED] cc Subject Re: [WiX-users] Multi-file assembly problem The problem is that if I installed everything via the old method (each of the three files set up as its own assembly with its own WinSxS folder) and then copied the DLL2 and DLL3 files from their WinSxS folders into the WinSxS folder for DLL1 then everything ran correctly. If i can just recreate that situation with the installer then everything would be fine, but Wix/Msi seems to refuse to copy additional files into DLL1's WinSxS folder unless they're included in the assembly manifest. Despite the fact they're part of DLL1's Component block in Wix. On Dec 6, 2007 4:10 PM, Kelly Leahy [EMAIL PROTECTED] wrote: Or it _does_ cause them to get copied over to the DLL1 side-by-side folder, but then my program can't find DLL1 anymore for reasons I can't figure out. Uhh... I think I can explain this one. Consider the following case: DLL1 in folder not in path DLL2 in folder not in path DLL1 loads DLL2 using LoadLibrary (and relative path). Application loads DLL1 by absolute path (like the way SxS works). DLL1 won't successfully load DLL2. Also, if DLL1 'statically' binds to DLL2, it will fail to load DLL1 altogether, since DLL2 isn't on the path. The key thing here is that the only 'application folder' that is used to resolve DLL dependencies is the EXE path, not the DLL path. http://msdn2.microsoft.com/en-us/library/ms682586.aspx Under no circumstances is the location of the DLL that is loading the other DLL used in determining the DLL search path. This is why people have so many problems with COM in-process servers that try to load DLL dependencies from their application directory. Geoff Finger [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/06/2007 03:38 PM To wix-users@lists.sourceforge.net cc Subject [WiX-users] Multi-file assembly problem Short version: Is there any way to override what seems to be the default behavior and force Wix/msi to install additional file elements in an assembly Component into the WinSxS folder even though they aren't included in the main file's manifest? Or alternately are there any kind and generous souls out there who know how to correctly combine several dlls into one multifile assembly using mt.exe , makecat and signtool? Long version: I've got a couple legacy dlls that I'm trying to include as Side-by-side assemblies. I've gone through this
Re: [WiX-users] Setupbld produces file but doesn't do anything?
Thanks for the Process Monitor tip Bob. I didn't see anything showing up in Task Manager for the setup file, but it sure showed up in ProcMon, and yes, I was being sorta dumb. Leads me to a new question. The setup works fine if the application is not installed, but if it is already installed, the setup seems to just reinstall silently. Is there something I have to do to get the msi change/repair/remove screen using the setup, or is that just not supported yet? Josh _ From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Monday, August 20, 2007 9:13 PM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Setupbld produces file but doesn't do anything? Josh Maletz wrote: setupbld -out XsSetup.exe -mcst ExtendedServicesSetup.msi -setup setup.exe -title Extended Services Setup The -mt subswitch is looking for UI transforms but you aren't supplying any. That would break it, however. How big is your package? Extracting it might take a while. I'd suggest starting with ProcMon to see if XsSetup.exe is doing any i/o. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setupbld produces file but doesn't do anything?
Hi all, I am trying to create a bootstrapper and am having no luck. I use the command line utility and it creates the setup file successfully apparently (at least the file size has greatly increased), but when I run the XsSetup.exe, it doesn't do anything. I am assuming I am being stupid, but there isn't any documentation and only 4 posts on the mailing list. I have tried with several different options, and the file is created but doesn't do anything. My command line is: setupbld -out XsSetup.exe -mcst ExtendedServicesSetup.msi -setup setup.exe -title Extended Services Setup Thanks, Josh - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Modify/Remove dialog not always displayed
I think maybe he meant the Id property on the Package element.i.e. Package Id=... Josh From: Levon Levonian [EMAIL PROTECTED] Sent: Friday, August 03, 2007 2:36 PM To: Burke, James [EMAIL PROTECTED], wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Modify/Remove dialog not always displayed I have hard-coded GUIDs for ProductID and UpgradeCode. I couldn't find PackageCode that you mentioned. Any ideas? Thank you! From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Burke, James Sent: Friday, August 03, 2007 12:08 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Modify/Remove dialog not always displayed Check your GUIDs, in particular your PackageCode. Do you have ... for them or are you using a hard-coded GUID? If you're using the ??'s, it will generate a new one when you rebuild. When these differ, it believes it's an update. If you leave the GUIDs the same, you should just receive a Modify/Remove dialog. From: Levon Levonian [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:42 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Modify/Remove dialog not always displayed Hi All, I run a setup and install some files. When I run the same setup again, the Modify/Remove dialog is displayed. However, when I rebuild the setup and run it over a previously installed build then I get an error message saying that a previous version is installed and I have to remove it before installing the new one. How can I make it so that I always get the Modify/Remove dialog regardless of the actual setup build? Thank you, Levon ** READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure. Internet messages may be corrupted, incomplete, misdirected or may incorrectly identify the sender. Therefore, nothing in this message or attachments may be considered legally binding. THIS MESSAGE IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY BE PRIVILEGED. If you are not the intended recipient or their authorized agent, you may not forward or copy this information and must delete or destroy all copies of this message and attachments received. If you have received this communication in error, please notify Matrikon Inc. by telephone at (780) 448-1010. ** ** READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure. Internet messages may be corrupted, incomplete, misdirected or may incorrectly identify the sender. Therefore, nothing in this message or attachments may be considered legally binding. THIS MESSAGE IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY BE PRIVILEGED. If you are not the intended recipient or their authorized agent, you may not forward or copy this information and must delete or destroy all copies of this message and attachments received. If you have received this communication in error, please notify Matrikon Inc. by telephone at (780) 448-1010. ** - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BOLD
Have you ever wished for a pricey Watch? We have the answer for you! We stock all the expinsive brands for a low precentage of the cost. www.huhhberr.com - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Deleting .Net 2.0 user config files on uninstall.
Hi all, I am trying to remove the .net generated user settings files from my win form application on uninstall, and am having some problems. I checked the archive for this specific issue and id not find anything. I did find another post on another blog that said developers have no control over these files and if you needed it, to implement your own setting provider, which would give me control over the location of these files. I wanted to see if anyone has been able to manage this through wix natively before embarking on this task. Assuming my scenario creates random folders along the lines of C:\Documents and Settings\USER\Local Settings\Application Data\APPNAME\RandomFolderName\user.config And: USER is the user name of the user, APPNAME is the name of my application in the AssemblyCompany attribute in my AssemblyInfo file for the app, and RandomFolderName appears to be an ap generated random folder name. Am I correct in assuming the proper way to go about this is to nuke everything below and including the APPNAME folder? I have not figured out how to get the USER value. I thought it was with the 'PersonalFolder' property, but that does not seem to be doing anything for me. Any help or direction pointing would be greatly appreciated. Thank you very much. Josh - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deleting .Net 2.0 user config files on uninstall.
Sorry to waste your time. I will try the homedrive and homepath environment variables and hard code the other path and see if that works. And yeah, the username environment var will get me the user ;) Sorry, my first installer. Normally a web guy. Josh Josh Maletz [EMAIL PROTECTED] 2020 Vine Street Denver, CO 80205 From: Josh [EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 4:06 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Deleting .Net 2.0 user config files on uninstall. Hi all, I am trying to remove the .net generated user settings files from my win form application on uninstall, and am having some problems. I checked the archive for this specific issue and id not find anything. I did find another post on another blog that said developers have no control over these files and if you needed it, to implement your own setting provider, which would give me control over the location of these files. I wanted to see if anyone has been able to manage this through wix natively before embarking on this task. Assuming my scenario creates random folders along the lines of C:\Documents and Settings\USER\Local Settings\Application Data\APPNAME\RandomFolderName\user.config And: USER is the user name of the user, APPNAME is the name of my application in the AssemblyCompany attribute in my AssemblyInfo file for the app, and RandomFolderName appears to be an ap generated random folder name. Am I correct in assuming the proper way to go about this is to nuke everything below and including the APPNAME folder? I have not figured out how to get the USER value. I thought it was with the 'PersonalFolder' property, but that does not seem to be doing anything for me. Any help or direction pointing would be greatly appreciated. Thank you very much. Josh - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Trying to use a system property in a property
Thanks for the response! Why am I putting stuff in the SystemFolder? I am editing the usrlogon.cmd and usrlogn2.cmd scripts. We do some scripting upon logon. This is actually part of a deployment to spin up a Citrix server in a farm. I won't be shipping this product; this is an installer I am writing to help my comrades on the operations side of IT at our company out a bit. Great! OK, so I can put SystemFolder in the CopyFile/@SourceProperty ... ok ... doing that SourceProperty='SystemFolder' ... ok so I do that, run the install on my Virtual box, and I get the message The installer has encounted an unexpected error installing this package. This may indicate a problem with this package. The error code is 2727. Then, if I look in the log I see: ...stuff... Action start 11:43:18: InstallValidate. DEBUG: Error 2727: The directory entry 'SytemsFolder' does not exist in the Directory table ...other stuff... Hm. So it's looking in the Directory table? OK, so I ran Orca and looked at the Directory table. Of course, I only see there the things that I explicitly defined, SystemFolder not being one of them. To be this seems to be an issue of timing; am I trying to access SystemFolder before the nth level of magic is invoked to replace it with C:\\Windows\System32 (or whatever)? 3. You're going to have a fun time trying to put the files back on uninstall. Uh Is this what they call foreboding? When installer gurus say something is fun that usually translates to a trip to the loony bin for the rest of us. I hadn't quite figured it out yet, but all I am trying to do is on install, make a backup of some scripts, and on uninstall, grab those backups and put them back where I found them. There is no way to do this? Couldn't I make some (stretching here, beyond my knowledge) CustomAction, and have it only run on uninstall? On='uninstall' or something? No? Thanks! Josh Josh Pepper Software Developer MinuteClinic From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 11:18 AM To: Josh Pepper; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Trying to use a system property in a property 0. Why are you putting stuff in SystemFolder? That's part of the operating system. Generally not a place people outside of the Windows team should be messing with. 1. Property values do not resolve the Properties in them. In your case, your SysFolder property contains the actual value [SystemFolder]. That will not be resolved to C:\Windows\System32 (or whatever). To get the resolution behavior you need to use a CustomAction... Type51 is the easiest. 2. In your case, you shouldn't even need to set SysFolder. Just putting SystemFolder in the CopyFile/@SourceProperty should work... haven't tried it so there may be a gotcha in there. 3. You're going to have a fun time trying to put the files back on uninstall. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Pepper Sent: Friday, March 02, 2007 1:16 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Trying to use a system property in a property Hi all - I am having some trouble using a system property. My current goal is to make a backup copy of some *.cmd files in the System32 directory because on installation I will be overwriting them (and then on uninstall I will be restoring the backups, but I am not there yet). My current problem is that I get a Error 1314. The specified path '[SystemFolder]' is unavailable error when I run the MSI. I am just trying to use the CopyFile element to copy the file usrlogon.cmd to my install dir. Some questions: 1. It seems I can refer to a system property such as ProgramFilesFolder in an Id without enclosing it in braces. How is this the case? 2. When I run the msi that the following XML creates, I get Error 1314. The specified path '[SystemFolder]' is unavailable in the log. Is the property getting defined at a time when I cannot refer to system properties? 3. When and where can I refer to things like ProgramFilesFolder and SystemFolder? When should I enclose in braces and when should I not? 4. You can see below that I attempted to define a property with a value of [SystemFolder]. That didn't work. However, neither did putting SystemFolder or [SystemFolder] in any of the places that I wanted that value (such as SourceDirectory in the CopyFile element). Why is this? ?xml blahWix blahProduct blahPackage blah /Media blah / Property Id='DiskPrompt' blah / Property Id=SysFolder Value ='[SystemFolder]' / Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='MinuteClinic' Name='MCDir' LongName='MinuteClinic Folder Long Name' Directory Id='INSTALLDIR' Name='SLDir' LongName='Server Logon Folder Long Name' Component Id='BackupCmds' Guid='A004C7F0-0585-4728-9F3C-C2C402549D7A' CopyFile Id=CopyUsr Delete
Re: [WiX-users] Trying to use a system property in a property
Ah! Good eye Simon. I corrected it but still get the problem: DEBUG: Error 2727: The directory entry 'SytemFolder' does not exist in the Directory table So the problem remains How do I refer to the SystemFolder in a CopyFile element? (Also, how do I get a copyfile action to trigger on uninstall?) Josh Pepper Software Developer MinuteClinic From: Simon Dahlbacka [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 12:21 PM To: Josh Pepper Cc: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Trying to use a system property in a property does the 'SytemsFolder' present in the log message have anything to do with it..? (You might want to check the speling, if that is the actual log output) /Simon On 3/3/07, Josh Pepper [EMAIL PROTECTED] wrote: Thanks for the response! Why am I putting stuff in the SystemFolder? I am editing the usrlogon.cmd and usrlogn2.cmd scripts. We do some scripting upon logon. This is actually part of a deployment to spin up a Citrix server in a farm. I won't be shipping this product; this is an installer I am writing to help my comrades on the operations side of IT at our company out a bit. Great! OK, so I can put SystemFolder in the CopyFile/@SourceProperty ... ok ... doing that SourceProperty='SystemFolder' ... ok so I do that, run the install on my Virtual box, and I get the message The installer has encounted an unexpected error installing this package. This may indicate a problem with this package. The error code is 2727. Then, if I look in the log I see: ...stuff... Action start 11:43:18: InstallValidate. DEBUG: Error 2727: The directory entry 'SytemsFolder' does not exist in the Directory table ...other stuff... Hm. So it's looking in the Directory table? OK, so I ran Orca and looked at the Directory table. Of course, I only see there the things that I explicitly defined, SystemFolder not being one of them. To be this seems to be an issue of timing; am I trying to access SystemFolder before the nth level of magic is invoked to replace it with C:\\Windows\System32 (or whatever)? 3. You're going to have a fun time trying to put the files back on uninstall. Uh Is this what they call foreboding? When installer gurus say something is fun that usually translates to a trip to the loony bin for the rest of us. I hadn't quite figured it out yet, but all I am trying to do is on install, make a backup of some scripts, and on uninstall, grab those backups and put them back where I found them. There is no way to do this? Couldn't I make some (stretching here, beyond my knowledge) CustomAction, and have it only run on uninstall? On='uninstall' or something? No? Thanks! Josh Josh Pepper Software Developer MinuteClinic From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 11:18 AM To: Josh Pepper; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Trying to use a system property in a property 0. Why are you putting stuff in SystemFolder? That's part of the operating system. Generally not a place people outside of the Windows team should be messing with. 1. Property values do not resolve the Properties in them. In your case, your SysFolder property contains the actual value [SystemFolder]. That will not be resolved to C:\Windows\System32 (or whatever). To get the resolution behavior you need to use a CustomAction... Type51 is the easiest. 2. In your case, you shouldn't even need to set SysFolder. Just putting SystemFolder in the CopyFile/@SourceProperty should work... haven't tried it so there may be a gotcha in there. 3. You're going to have a fun time trying to put the files back on uninstall. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Pepper Sent: Friday, March 02, 2007 1:16 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Trying to use a system property in a property Hi all - I am having some trouble using a system property. My current goal is to make a backup copy of some *.cmd files in the System32 directory because on installation I will be overwriting them (and then on uninstall I will be restoring the backups, but I am not there yet). My current problem is that I get a Error 1314. The specified path '[SystemFolder]' is unavailable error when I run the MSI. I am just trying to use the CopyFile element to copy the file usrlogon.cmd to my install dir. Some questions: 1. It seems I can refer to a system property such as ProgramFilesFolder in an Id without enclosing it in braces. How is this the case? 2. When I run the msi that the following XML creates, I get Error 1314. The specified path '[SystemFolder]' is unavailable in the log. Is the property getting defined at a time when I cannot refer to system properties? 3. When and where can I refer to things like ProgramFilesFolder and SystemFolder? When should I
Re: [WiX-users] Trying to use a system property in a property
Thanks Rob - I will attempt to simplify this OR learn everything I can about CustomAction. Josh Pepper Software Developer MinuteClinic From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 12:07 PM To: Josh Pepper; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Trying to use a system property in a property 1. It doesn't surprise me that you need to define SystemFolder in the Directory table. That's easy enough to do. Just make it a child of the TARGETDIR Directory element and you're done. 2. Yes, fun for me can often equate to loony bin for others. The trick is getting the Windows Installer to do its native actions on uninstall (which it doesn't do in many cases). That does mean you're stuck with a CustomAction. The problem with CustomActions is that you then assume responsibility for install/uninstall/rollback/patching/upgrading/etc. You can condition out some of those cases (like install in your case) but what about rollback for uninstall? When anyone says, I'll just write a CustomAction! I usually end up smiling. Teams (mostly in Microsoft since those are the halls I haunt) that know me well know they are in deep trouble when I start smiling like that because they know they oversimplified something. Simplifying your applications installation needs is a very good thing. Oversimplifying your setup means customers feel the pain when things don't go simply (like the user hits an error or even the cancel button). smile/ From: Josh Pepper [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 9:53 AM To: Rob Mensching; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Trying to use a system property in a property Thanks for the response! Why am I putting stuff in the SystemFolder? I am editing the usrlogon.cmd and usrlogn2.cmd scripts. We do some scripting upon logon. This is actually part of a deployment to spin up a Citrix server in a farm. I won't be shipping this product; this is an installer I am writing to help my comrades on the operations side of IT at our company out a bit. Great! OK, so I can put SystemFolder in the CopyFile/@SourceProperty ... ok ... doing that SourceProperty='SystemFolder' ... ok so I do that, run the install on my Virtual box, and I get the message The installer has encounted an unexpected error installing this package. This may indicate a problem with this package. The error code is 2727. Then, if I look in the log I see: ...stuff... Action start 11:43:18: InstallValidate. DEBUG: Error 2727: The directory entry 'SytemsFolder' does not exist in the Directory table ...other stuff... Hm. So it's looking in the Directory table? OK, so I ran Orca and looked at the Directory table. Of course, I only see there the things that I explicitly defined, SystemFolder not being one of them. To be this seems to be an issue of timing; am I trying to access SystemFolder before the nth level of magic is invoked to replace it with C:\\Windows\System32 (or whatever)? 3. You're going to have a fun time trying to put the files back on uninstall. Uh Is this what they call foreboding? When installer gurus say something is fun that usually translates to a trip to the loony bin for the rest of us. I hadn't quite figured it out yet, but all I am trying to do is on install, make a backup of some scripts, and on uninstall, grab those backups and put them back where I found them. There is no way to do this? Couldn't I make some (stretching here, beyond my knowledge) CustomAction, and have it only run on uninstall? On='uninstall' or something? No? Thanks! Josh Josh Pepper Software Developer MinuteClinic From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 11:18 AM To: Josh Pepper; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Trying to use a system property in a property 0. Why are you putting stuff in SystemFolder? That's part of the operating system. Generally not a place people outside of the Windows team should be messing with. 1. Property values do not resolve the Properties in them. In your case, your SysFolder property contains the actual value [SystemFolder]. That will not be resolved to C:\Windows\System32 (or whatever). To get the resolution behavior you need to use a CustomAction... Type51 is the easiest. 2. In your case, you shouldn't even need to set SysFolder. Just putting SystemFolder in the CopyFile/@SourceProperty should work... haven't tried it so there may be a gotcha in there. 3. You're going to have a fun time trying to put the files back on uninstall. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Pepper Sent: Friday, March 02, 2007 1:16 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Trying to use a system property in a property Hi all - I am having some trouble using a system property
[WiX-users] Trying to use a system property in a property
Hi all - I am having some trouble using a system property. My current goal is to make a backup copy of some *.cmd files in the System32 directory because on installation I will be overwriting them (and then on uninstall I will be restoring the backups, but I am not there yet). My current problem is that I get a Error 1314. The specified path '[SystemFolder]' is unavailable error when I run the MSI. I am just trying to use the CopyFile element to copy the file usrlogon.cmd to my install dir. Some questions: 1. It seems I can refer to a system property such as ProgramFilesFolder in an Id without enclosing it in braces. How is this the case? 2. When I run the msi that the following XML creates, I get Error 1314. The specified path '[SystemFolder]' is unavailable in the log. Is the property getting defined at a time when I cannot refer to system properties? 3. When and where can I refer to things like ProgramFilesFolder and SystemFolder? When should I enclose in braces and when should I not? 4. You can see below that I attempted to define a property with a value of [SystemFolder]. That didn't work. However, neither did putting SystemFolder or [SystemFolder] in any of the places that I wanted that value (such as SourceDirectory in the CopyFile element). Why is this? ?xml blahWix blahProduct blahPackage blah /Media blah / Property Id='DiskPrompt' blah / Property Id=SysFolder Value ='[SystemFolder]' / Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='MinuteClinic' Name='MCDir' LongName='MinuteClinic Folder Long Name' Directory Id='INSTALLDIR' Name='SLDir' LongName='Server Logon Folder Long Name' Component Id='BackupCmds' Guid='A004C7F0-0585-4728-9F3C-C2C402549D7A' CopyFile Id=CopyUsr Delete=no SourceProperty='SysFolder' SourceName=usrlogon.cmd DestinationDirectory=INSTALLDIR DestinationName=usrlogon.bak DestinationLongName=usrlogon.cmd.bak/ /Component/Directory/Directory/Directory Feature Id='Complete' Level='1' ComponentRef Id='BackupCmds' / /Feature /Product/Wix Many thanks to all who respond! Josh Pepper Software Developer MinuteClinic This electronic mail message and attachments contain information which may be (a) LEGALLY PRIVILEGED, CONFIDENTIAL AND PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and is (b) intended only for the use of the Addressee(s) named herein. If you are not the Addressee(s), or the person responsible for delivering this message to the Addressee(s), you are hereby notified that reading, copying, or distributing this message is prohibited. If you have received this electronic mail message in error, please contact us immediately (by reply e-mail) to inform us of the error and take the steps necessary to delete the message completely from your computer system and any related data. Thank you. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] CustomAction failing on Vista
I am using a CustomAction to launch ngen at the end of my installation but its not working correctly in Vista with UAC. If I invoke the command manually from the command prompt as the logged in user, it fails because ngen requires the admin token. So I dont get any elevation prompts even if I run it manually. Is there a way to specify that the CustomAction needs to be elevated? Ive tried impersonate=no but it doesnt seem to help. Ive tried searching the web and newsgroups for some information about using CustomActions with UAC and I found Robs blog entry at http://blogs.msdn.com/robmen/archive/2006/02/22/537106.aspx and while he explains that it might fail, I dont see how to avoid it. Thanks in advance for any insight you guys can provide. Josh Einstein Einstein Technologies Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction failing on Vista
I havent looked at Wix Version 3 yet. I guess I was put off by the (unstable) after it. The reason I switched to Wix was for a more predictable installation experience than InstallShield. Is the schema compatible with version 2? I am a few days away from a launch so I might have to put it off for a little while. But thanks for the information about deferring the CustomAction. I will give that a try. I think I need to read up a bit more about deferred CustomActions because I think I recall that there were some other considerations with regard to properties and sequencing. Thanks again. Josh From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 04, 2006 7:07 PM To: Josh Einstein Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] CustomAction failing on Vista Josh Einstein wrote: I am using a CustomAction to launch ngen at the end of my installation but its not working correctly in Vista with UAC. If I invoke the command manually from the command prompt as the logged in user, it fails because ngen requires the admin token. So I dont get any elevation prompts even if I run it manually. Is there a way to specify that the CustomAction needs to be elevated? Ive tried impersonate=no but it doesnt seem to help. CAs need to be both deferred (@Execute=deferred) and non-impersonated (@Impersonate=no) to get the elevation prompt. Could you switch to WiX v3? It has NGen support. -- sig://boBhttp://bobs.org Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
