Re: [WiX-users] Services + Vista + GAC
Sure, MSI should have the ability to combine complete MSI installation packages as phases of the installation, together with the transactional behaviour (including savepoints on the registry..)... is this something related to staged installation Windows Installer 4.5? Otherwise there might be several reasons for the lack of this feature, I know... would this have effects on security which make it better to forget about the whole misery? perhaps backward compatibility makes it impossible? or too much ado for something that can be avoided with hacks? 2007/11/15, Christopher Painter [EMAIL PROTECTED]: Why not blame MSI? Sure they are dependant on Fusion, but why did they make the choice to wait to the commit phase to call fusion? The stated reason is to provide rollback capabilities but the problem I have with that is GAC is SN ... while rollback is nice to have, the risk of system instability should be next to none due to the very nature of GAC/SN. So I have an extra assembly in storage or I have an assembly with a higher AssemblyFileVersion. That should not be the end of the world but if they are still worried about it, they really, really should have found some way to be true to the transacted nature and execution phases so that this type of problem was mitigated. And adding the CRT as a static link for C++ developers only solves some problems. It wouldn't solve my problems. I work .NET SOA SaaS installs and without getting into all the details I have about a dozen application framework blocks that have to be deployed to the GAC for consumption across WebUI, WebServices ( 80+ ) and WindowsServices. The ASP.NET http://asp.net/ is fine because the assemblies won't be needed until the sites are accessed and the content JIT'd. But the WindowsServices need the files ( it's basically a client that consumes the web services ) The customer pays the bills and they say 1) don't copy the assemblies local 2) start the service right away 3) avoid a reboot. So while I could argue to change the code to break the dependency on the GAC, it ain't going to be happening. *Rob Mensching [EMAIL PROTECTED]* wrote: I don't know where to reply to this thread so I thought I'd just start here. Personally, in the list of all the technologies to blame, I blame Fusion. Fusion is the technology under the GAC (Fusion is actually a code name for a few things but the GAC is very much Fusion's fault) and due to some (IMHO) really brain dead design decisions they created a system that doesn't interact really well with existing installation technologies. Then the C++ team did another brain dead thing (IMHO) and took a dependency on Fusion and made the C Run Time (CRT) Win32 SxS DLLs. Now we have deep, low-level, core functionality that pretty much everyone on the planet (that writes C++) needs dependent on a high level, poorly designed, data store (aka: GAC). The easiest way out of the mess and the one that I always recommend is to statically link the CRT. There are downsides (your executable is bigger for example) but your install gets so amazingly more simple that I personally can't imagine making the trade off the other way. For example, you'll notice all of the WiX custom actions statically link to the CRT so your install has no dependencies on the GAC (which are actually impossible to satisfy in the middle of an install). PS: Has anyone ever noticed how many custom actions the CRT merge modules pull in? Terrifying amounts of code to do something that should have remained simple, copy the CRT with your application. And to think, people use to argue that the GAC was going to make installation easier. Adam Majer wrote: Richard wrote: The problem isn't anything to do with Vista, its because your service has a dependency on something in the GAC and the files don't really appear in the GAC until after the Commit phase of the install. Just mark your service as starting automaticly and you shouldn't have any problem. Then Windows will start the service when its needed. Why do you think that you must start your service before the install finishes? First a general comment - thanks for all the replies! Regarding the service now, I think the problem has a lot to do with the installation of stuff into the GAC (the recommended way of doing things after all). All that the service needs is the C runtime, nothing special here. But that is not available. Now, wix has so, why have that? Coincidently, it works on *every* release of windows, but not Vista because of Vista's new way of handing assemblies. Therefore the bug is either in WiX, Windows Installer or Vista. By my understanding of how things work, GAC refresh/update/install/committing/whatever you want to call it, should just be an API call within Windows Installer so the installation sequence can be, .. install stuff (including to GAC) ..
Re: [WiX-users] Services + Vista + GAC
Why not blame MSI? Sure they are dependant on Fusion, but why did they make the choice to wait to the commit phase to call fusion? The stated reason is to provide rollback capabilities but the problem I have with that is GAC is SN ... while rollback is nice to have, the risk of system instability should be next to none due to the very nature of GAC/SN. So I have an extra assembly in storage or I have an assembly with a higher AssemblyFileVersion. That should not be the end of the world but if they are still worried about it, they really, really should have found some way to be true to the transacted nature and execution phases so that this type of problem was mitigated. And adding the CRT as a static link for C++ developers only solves some problems. It wouldn't solve my problems. I work .NET SOA SaaS installs and without getting into all the details I have about a dozen application framework blocks that have to be deployed to the GAC for consumption across WebUI, WebServices ( 80+ ) and WindowsServices. The ASP.NET is fine because the assemblies won't be needed until the sites are accessed and the content JIT'd. But the WindowsServices need the files ( it's basically a client that consumes the web services ) The customer pays the bills and they say 1) don't copy the assemblies local 2) start the service right away 3) avoid a reboot. So while I could argue to change the code to break the dependency on the GAC, it ain't going to be happening. Rob Mensching [EMAIL PROTECTED] wrote: I don't know where to reply to this thread so I thought I'd just start here. Personally, in the list of all the technologies to blame, I blame Fusion. Fusion is the technology under the GAC (Fusion is actually a code name for a few things but the GAC is very much Fusion's fault) and due to some (IMHO) really brain dead design decisions they created a system that doesn't interact really well with existing installation technologies. Then the C++ team did another brain dead thing (IMHO) and took a dependency on Fusion and made the C Run Time (CRT) Win32 SxS DLLs. Now we have deep, low-level, core functionality that pretty much everyone on the planet (that writes C++) needs dependent on a high level, poorly designed, data store (aka: GAC). The easiest way out of the mess and the one that I always recommend is to statically link the CRT. There are downsides (your executable is bigger for example) but your install gets so amazingly more simple that I personally can't imagine making the trade off the other way. For example, you'll notice all of the WiX custom actions statically link to the CRT so your install has no dependencies on the GAC (which are actually impossible to satisfy in the middle of an install). PS: Has anyone ever noticed how many custom actions the CRT merge modules pull in? Terrifying amounts of code to do something that should have remained simple, copy the CRT with your application. And to think, people use to argue that the GAC was going to make installation easier. Adam Majer wrote: Richard wrote: The problem isn't anything to do with Vista, its because your service has a dependency on something in the GAC and the files don't really appear in the GAC until after the Commit phase of the install. Just mark your service as starting automaticly and you shouldn't have any problem. Then Windows will start the service when its needed. Why do you think that you must start your service before the install finishes? First a general comment - thanks for all the replies! Regarding the service now, I think the problem has a lot to do with the installation of stuff into the GAC (the recommended way of doing things after all). All that the service needs is the C runtime, nothing special here. But that is not available. Now, wix has so, why have that? Coincidently, it works on *every* release of windows, but not Vista because of Vista's new way of handing assemblies. Therefore the bug is either in WiX, Windows Installer or Vista. By my understanding of how things work, GAC refresh/update/install/committing/whatever you want to call it, should just be an API call within Windows Installer so the installation sequence can be, .. install stuff (including to GAC) .. refresh GAC -- maybe this could be a custom step that doesn't run unless needed, like when starting services before installation is done. .. start services. Then if start services fails, you roll back by uninstalling the stuff from the GAC, (refreshing it again, if you have done it before) and rolling back the rest of the installation. Finally, the application here is installed as a service because it is not a user intractable application and it is the easiest way of doing things. But yes, there may be another way of running it... messy, but possible. But for general case, does windows have triggers that allow a service to be
Re: [WiX-users] File element and DiskId
I think that is a feature request somewhere. Peter said he wanted to make this work a long time ago... it just isn't at all very easy. Craig Miller wrote: Ah, I see. That isn't as flexible, and seems a bit confusing, but it should work. I expected the hierarchy to work the other way around. That is, that I would have a media element that would specify what features were contained in it. E.g. Property Id='DiskPrompt' Value=USGS Topographic Basemaps Arizona [1] / Media Id=1 Cabinet=az.cab DiskPrompt=TOPO_AZ_DISK1 FeatureRef Id=AZ_250k_MapPack/ /Media --Craig --- http://www.overlandnavigator.com Touchscreen Friendly GPS Mapping -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 14, 2007 5:26 PM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] File element and DiskId Craig Miller wrote: Why is the diskId associated with a file? Because at the end of the day, files go into .cabs or disks.g That said, you can also specify media IDs at the component or directory levels and they cascade down to their contained files. What you can't do at the moment is specify media IDs outside the fragment. I think you can do everything you talk about. Media IDs are just integers; you can create different Media elements at your product level; you just have to do a least common denominator approach (i.e., break up your media such that they fit on CD so you can reuse them on a DVD). Example 1: Assuming I have 3 files... All will fit on the DVD, but only one will fit on each CD. If I specify the DiskId at the file level, everything always goes onto Disk1 unless I edit the reusable fragment. Use three media IDs, one for each file. In your DVD product, each Media element points to the same layout. In your CD product, a different layout each. and it's GUID. Unfortunately, the file element specifies the DiskId and only the primary state being installed will fit on the DVD. The partial files need to go onto DVD 2 (DiskId 2). Same as example #1, really. Have as many Media IDs as you need to cover the different scenarios (three whole states, plus overlaps). In the Media elements for each Product element, you can lay them out however fits your CDs/DVDs. -- sig://boB http://joyofsetup.com/ No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.31/1130 - Release Date: 11/14/2007 9:27 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.31/1130 - Release Date: 11/14/2007 9:27 AM - 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 - 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] Services + Vista + GAC
That's actually a very good question and I've not tested this scenario in MSI 4.5.Right now I can create a redist prereq and chain it in my bootstrapper before my install so that the assemblies are already in the GAC. In MSI 4.5, if I have Package 1 with component A that deploys to the gac and Package 2 with component B that consumes the assembly deployed by component A when the service starts. will the assembly be available or will the overall transaction not commit the assembly to the GAC and the problem remains? János Brezniczky [EMAIL PROTECTED] wrote: Sure, MSI should have the ability to combine complete MSI installation packages as phases of the installation, together with the transactional behaviour (including savepoints on the registry..)... is this something related to staged installation Windows Installer 4.5? Otherwise there might be several reasons for the lack of this feature, I know... would this have effects on security which make it better to forget about the whole misery? perhaps backward compatibility makes it impossible? or too much ado for something that can be avoided with hacks? 2007/11/15, Christopher Painter [EMAIL PROTECTED]: Why not blame MSI? Sure they are dependant on Fusion, but why did they make the choice to wait to the commit phase to call fusion? The stated reason is to provide rollback capabilities but the problem I have with that is GAC is SN ... while rollback is nice to have, the risk of system instability should be next to none due to the very nature of GAC/SN. So I have an extra assembly in storage or I have an assembly with a higher AssemblyFileVersion. That should not be the end of the world but if they are still worried about it, they really, really should have found some way to be true to the transacted nature and execution phases so that this type of problem was mitigated. And adding the CRT as a static link for C++ developers only solves some problems. It wouldn't solve my problems. I work .NET SOA SaaS installs and without getting into all the details I have about a dozen application framework blocks that have to be deployed to the GAC for consumption across WebUI, WebServices ( 80+ ) and WindowsServices. The ASP.NET is fine because the assemblies won't be needed until the sites are accessed and the content JIT'd. But the WindowsServices need the files ( it's basically a client that consumes the web services ) The customer pays the bills and they say 1) don't copy the assemblies local 2) start the service right away 3) avoid a reboot. So while I could argue to change the code to break the dependency on the GAC, it ain't going to be happening. Rob Mensching [EMAIL PROTECTED] wrote: I don't know where to reply to this thread so I thought I'd just start here. Personally, in the list of all the technologies to blame, I blame Fusion. Fusion is the technology under the GAC (Fusion is actually a code name for a few things but the GAC is very much Fusion's fault) and due to some (IMHO) really brain dead design decisions they created a system that doesn't interact really well with existing installation technologies. Then the C++ team did another brain dead thing (IMHO) and took a dependency on Fusion and made the C Run Time (CRT) Win32 SxS DLLs. Now we have deep, low-level, core functionality that pretty much everyone on the planet (that writes C++) needs dependent on a high level, poorly designed, data store (aka: GAC). The easiest way out of the mess and the one that I always recommend is to statically link the CRT. There are downsides (your executable is bigger for example) but your install gets so amazingly more simple that I personally can't imagine making the trade off the other way. For example, you'll notice all of the WiX custom actions statically link to the CRT so your install has no dependencies on the GAC (which are actually impossible to satisfy in the middle of an install). PS: Has anyone ever noticed how many custom actions the CRT merge modules pull in? Terrifying amounts of code to do something that should have remained simple, copy the CRT with your application. And to think, people use to argue that the GAC was going to make installation easier. Adam Majer wrote: Richard wrote: The problem isn't anything to do with Vista, its because your service has a dependency on something in the GAC and the files don't really appear in the GAC until after the Commit phase of the install. Just mark your service as starting automaticly and you shouldn't have any problem. Then Windows will start the service when its needed. Why do you think that you must start your service before the install finishes? First a general comment - thanks for all the replies! Regarding the service now, I think the problem has a lot to do with the installation of stuff into the GAC (the recommended way of doing
[WiX-users] already installed launch condition?
Hi, I'm in the process of converting our installer source from Wise/WIS to Wix - a much simpler task than I thought it would be. Much thanks to all the Wix people for such a great piece of work. I have ARPNOMODIFY and ARPNOREPAIR set and what I want to do is:- if the product is already installed then display a message saying the product is alreay installed - remove from ARP first. At the moment if the product is installed and I run the installer it goes straight to the setup progress dialog, zips through that and comes up with the finished dialog. Any ideas greatly appreciated. Thanks Donal -- View this message in context: http://www.nabble.com/already-installed-launch-condition--tf4812155.html#a13768666 Sent from the wix-users mailing list archive at Nabble.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] License in wix-3.0.2925.0-sources.zip ?
Hi, I just downloaded the latest source drop of wix 3, wix-3.0.2925.0-sources.zip, and noticed that the CPL license information in the header of all files has been removed since wix-3.0.2420.0-sources.zip. Has the license for Wix 3 changed? I couldn't find any signs of this change in the CVS repository. //The use and distribution terms for this software are covered by the //Common Public License 1.0 (http://opensource.org/licenses/cpl.php) //which can be found in the file CPL.TXT at the root of this distribution. //By using this software in any fashion, you are agreeing to be bound by //the terms of this license. /Johan - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX MSI not removing REG entries during removal
Lanteigne, Alan wrote: What could cause this error? I've ensured there are no other installations using the GUID's in the error. What does it mean by another client? Another client means another setup uses those GUIDs. Can you reproduce this problem on a clean machine? It's a common problem during setup development, to leave droppings behind and run into problems like this. That's why I recommend testing in virtual machines (http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/). -- 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
Re: [WiX-users] WiX MSI not removing REG entries during removal
You're correct on that one. I see I used those same GUID's in my original Votive 2.0 project. I already use VMWare to test other scripts, so I'll just start testing my MSI on it as well. Thanks! From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Thursday, November 15, 2007 11:11 AM To: Lanteigne, Alan Cc: János Brezniczky; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX MSI not removing REG entries during removal Lanteigne, Alan wrote: What could cause this error? I've ensured there are no other installations using the GUID's in the error. What does it mean by another client? Another client means another setup uses those GUIDs. Can you reproduce this problem on a clean machine? It's a common problem during setup development, to leave droppings behind and run into problems like this. That's why I recommend testing in virtual machines (http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/). -- 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
Re: [WiX-users] Enable Wix3 Custom Action Trace
Please keep /wix-users/ on the thread. Mark Allanson wrote: I tried both methods of getting logging out with no luck, both adding the Logging registry entry, and passing in a LOGVERBOSE property on the command line with no luck. The registry entries certainly make windows installer log verbose output without having to specify it on the command line, but within the custom action execution parts nothing comes out. Which version of WiX are you using? There aren't many conditional log entries but one is RegisterPerfmon running command: '...' -- 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] WiX, MSMQ, Triggers, and Rules
Hi - I'm afraid I already know the answer to this, but is it possible, using WiX, to create Microsoft Message Queues, Triggers, and Rules? Thanks! - 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] License in wix-3.0.2925.0-sources.zip ?
Johan Appelgren wrote: I just downloaded the latest source drop of wix 3, wix-3.0.2925.0-sources.zip, and noticed that the CPL license information in the header of all files has been removed since wix-3.0.2420.0-sources.zip. Has the license for Wix 3 changed? I couldn't find any signs of this change in the CVS repository. No license change. In v3.0.3429.0, files have the CPL blurb, at least from a spot-check. -- 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
Re: [WiX-users] WiX MSI not removing REG entries during removal
What could cause this error? I've ensured there are no other installations
using the GUID's in the error. What does it mean by another client?
MSI (s) (14:A4) [14:56:29:803]: Disallowing uninstallation of component:
{193119C5-AF4B-4432-9406-FFB4C34DE70D} since another client exists
Alan
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 14, 2007 8:11 PM
To: Lanteigne, Alan
Cc: János Brezniczky; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX MSI not removing REG entries during removal
Lanteigne, Alan wrote:
Could these errors (from my removal log) be the cause of REG values and files
not being removed during uninstall?
If your registry values belong to the component that's not being uninstalled,
yes.
--
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] WIX Extension localization variable not defined errors.
I am getting the following errors when compiling with WIX extensions: errors in directory c:\src\setup\postbuild\msis\simplec:\delivery\dev\wix_public\src\ext\utilextension\wixlib\utilextension.wxs(37) : error LGHT0102 : The localization variable !(loc.msierrUSRFailedUserCreate) is unknown. Please ensure the variable is defined.c:\delivery\dev\wix_public\src\ext\utilextension\wixlib\utilextension.wxs(38) : error LGHT0102 : The localization variable !(loc.msierrUSRFailedUserCreatePswd) is unknown. Please ensure the variableis defined.c:\delivery\dev\wix_public\src\ext\utilextension\wixlib\utilextension.wxs(39) : error LGHT0102 : The localization variable !(loc.msierrUSRFailedUserGroupAdd) is unknown. Please ensure the variable is defined. ... Where do I get the wxl files for these? Do I build them like this? c:\wix\bin\light -nologo -loc missinglocfile.wxl -out ... Thanks, --Leo- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Doing a RegistrySearch and storing it into a Property - default value
Sabrina Werscheid wrote: But what about the case when RegistrySearch returns nothing? According to the specification, has INSTALLDIR the empty string or is INSTALLDIR untouched? The AppSearch table doc in the MSI SDK says: The property listed in the Property field may be initialized in the Property property_table.htm table or from a command line. If the AppSearch action locates the signature, the installer overrides the initialized property value with the found value. If the signature is not found, then the initial property value is used. If the property was never initialized, then the property will only be set if the signature is found. Otherwise, the property is undefined. -- 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] 供应：剪板机、折弯机、卷板机、冲床、校平机
供应：剪板机、折弯机、卷板机、冲床、校平机 安徽省三力机床制造有限公司，属安徽省名牌、免检产品生产企业，安徽省高新技术企业，马鞍山市“专、精、特、新”企业，马鞍山市下岗失业职工再就业基地，介于南京、芜湖之间，坐落在著名的钢城马鞍山市，丰富的钢铁资源为公司的发展提供了得天独厚的优势。公司占地面积108000平方米，主要生产“大盛”牌系列剪板机、折弯机、卷板机、快速压力机、冲床、开卷校平机、型材弯曲机刀模具等产品，专业为航空、轻工、冶金、化工、建筑汽车、电力、装潢等行业提供所需要的专用机械和成套设备，产品销往全国各地和欧盟及东南亚地区并远销南非。 公司用现代企业的管理方法、立足于产品管理，以其优秀的品质，新颖的设计，合理的价格，完善的售后服务赢得了广大客户的一致好评，被评为安徽省“重合同、守信用先进单位”、安徽省“著名商标”、安徽省“名牌产品”、“企业进出口资格证”、“CE国际认证”安徽省农行“AA+级信用企业”、安徽省“优秀诚信民营企业”、安徽省“诚信单位”、“马鞍山市先进集体”、“马鞍山市优秀私营企业”、“马鞍山市诚信纳税人”、“马鞍山市银行信贷诚信中小企业”、“全国用户产品质量满意，售后服务满意示范单位”、“AAA级质量诚信会员单位”、“中国质量过硬放心品牌”、“中国市场公认畅销品牌”、“全国机床十佳名优品牌”等荣誉称号 全体员工以先进的技术和现代化的管理手段为追求产品的完美而不懈努力。公司于2001年10月全面通过ISO9001：2000质量管理体系认证，2003年8月通过了三级计量确认，拥有自营进出口权，为提高产品科技的含金量及产品性能，2003年12月公司与合肥工业大学合作成立了“机床工程技术研究中心”。2004年WF67K数控板料折弯机新品生产线项目被全省发展改革委员会批准为省“三高”项目，并被列入省“861”计划重点建设项目。国家质量检验检疫总局于2006年9月对我公司的QC12Y-4＊3200液压摆式剪板机进行了产品质量国家监督抽查。我公司产品一次性通过各项指标检验，成绩全部格（检验报告编号：DJ-1055-D01-Q）。 三力产品精益求精，三力人将不断开拓，不断创新，并真诚地愿与各界朋友携手共进，共同发展。 单位：安徽省三力机床制造有限公司 电话：0555-6721249 传真：0555-6612848 www.cnjczz.com [EMAIL PROTECTED] ―― 【注意】上面的邮件内容与以下文字无关。本软件仅限于合法用途! 该邮件由《Volleymail邮件群发专家》软件发送；被网友评为最厉害 的邮件群发软件而多次要求破解！现免费下载，无限时间使用。 详情请访问我们的主页：http://www.cnysoft.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
Re: [WiX-users] Trying to force a reboot prompt after setupcompletes -Unexpected external UI message
It doesn't matter where you put the ScheduleReboot because it effectively just sets a flag causing a request for a reboot at the end. Also you don't really need to supply the UI prompt for a reboot, Windows does that, including the choice for the user to postpone it. If you want a checkbox, condition ScheduleReboot on the property associated with a checked box. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chad Petersen Sent: Thursday, November 15, 2007 1:02 PM To: Lanteigne, Alan; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Trying to force a reboot prompt after setupcompletes -Unexpected external UI message Unless I misunderstand, you should be able to put this in your InstallExecuteSequence ScheduleReboot After=InstallFinalize/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lanteigne, Alan Sent: Thursday, November 15, 2007 12:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Trying to force a reboot prompt after setup completes -Unexpected external UI message I'm trying to force a checkbox based restart (default being ON, for restart) after my installation is finished. To do so I've done this: CustomAction Id=Restart Property=REBOOT ExeCommand= Impersonate=yes Return=ignore / Property Id='REBOOT'FORCE/Property Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=Restart Order=1WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1/Publish I'm not sure if I'm going about this the right way but I'm having trouble finding documentation on how to cause a reboot. Currently, when I try to compile, I get this: An unexpected external UI message was received: You must restart your system for the configuration changes made to Blah Blah to take effect. Click Yes to restart now or No if you plan to manually restart later. Is my technique flawed here? If so, could someone indicate the area of my problem? Thanks, Alan S. Lanteigne | Channel Ready Solutions phone fax +1.317.715.8293| [EMAIL PROTECTED] Interactive Intelligence Inc. Deliberately Innovative www.inin.com http://www.inin.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Trying to force a reboot prompt after setup completes - Unexpected external UI message
I'm trying to force a checkbox based restart (default being ON, for restart) after my installation is finished. To do so I've done this: CustomAction Id=Restart Property=REBOOT ExeCommand= Impersonate=yes Return=ignore / Property Id='REBOOT'FORCE/Property Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=Restart Order=1WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1/Publish I'm not sure if I'm going about this the right way but I'm having trouble finding documentation on how to cause a reboot. Currently, when I try to compile, I get this: An unexpected external UI message was received: You must restart your system for the configuration changes made to Blah Blah to take effect. Click Yes to restart now or No if you plan to manually restart later. Is my technique flawed here? If so, could someone indicate the area of my problem? Thanks, Alan S. Lanteigne | Channel Ready Solutions phone fax +1.317.715.8293| [EMAIL PROTECTED] Interactive Intelligence Inc. Deliberately Innovative www.inin.com http://www.inin.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX, MSMQ, Triggers, and Rules
WiX v3 has the 'Msmq' extension - which allows for creation of queues as part of the installation. Triggers and Trigger Rules, however, are not supported. But you possibly already knew that ;-) Regards. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy, Richard Sent: Friday, 16 November 2007 4:35 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX, MSMQ, Triggers, and Rules Hi - I'm afraid I already know the answer to this, but is it possible, using WiX, to create Microsoft Message Queues, Triggers, and Rules? Thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Trying to force a reboot prompt after setup completes -Unexpected external UI message
Unless I misunderstand, you should be able to put this in your InstallExecuteSequence ScheduleReboot After=InstallFinalize/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lanteigne, Alan Sent: Thursday, November 15, 2007 12:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Trying to force a reboot prompt after setup completes -Unexpected external UI message I'm trying to force a checkbox based restart (default being ON, for restart) after my installation is finished. To do so I've done this: CustomAction Id=Restart Property=REBOOT ExeCommand= Impersonate=yes Return=ignore / Property Id='REBOOT'FORCE/Property Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=Restart Order=1WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1/Publish I'm not sure if I'm going about this the right way but I'm having trouble finding documentation on how to cause a reboot. Currently, when I try to compile, I get this: An unexpected external UI message was received: You must restart your system for the configuration changes made to Blah Blah to take effect. Click Yes to restart now or No if you plan to manually restart later. Is my technique flawed here? If so, could someone indicate the area of my problem? Thanks, Alan S. Lanteigne | Channel Ready Solutions phone fax +1.317.715.8293| [EMAIL PROTECTED] Interactive Intelligence Inc. Deliberately Innovative www.inin.com http://www.inin.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Services + Vista + GAC
I agree, it does seem to be an MSI thing rather than a Fusion thing here. IAssemblyCache is documented - there's IAssemblyCache:InstallAssembly and IAssemblyCache:UninstallAssembly, and there seems to be no obvious reason why InstallAssembly can't be called when MSI installs the other files, and UninstallAssembly if it rolls back later, the same as for files in a normal file system. That assumes of course that these are the APIs that are used. There's nothing about those interfaces that is two-phase. The documentation saying that the implementation is for rollback of unsuccessful installations seems completely irrelevant because the darn assembly is never in the GAC in the first place as far as any of us can tell. There might be some internal sense in which an assembly is somehow in the GAC, but the issue we're describing here doesn't involve any rollback at all because they are never there to get rolled back! Not knowing the inside story here, my guess is that there's something nasty about UninstallAssembly and restoring the GAC state that would not work during the kind of rollback that would be necessary. As a result, InstallAssembly isn't called until InstallFinalize/Commit, so in fact there is never really an installer rollback of an assembly installed in the GAC. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Thursday, November 15, 2007 4:23 AM To: Rob Mensching; Adam Majer Cc: WiX Users Subject: Re: [WiX-users] Services + Vista + GAC Why not blame MSI? Sure they are dependant on Fusion, but why did they make the choice to wait to the commit phase to call fusion? The stated reason is to provide rollback capabilities but the problem I have with that is GAC is SN ... while rollback is nice to have, the risk of system instability should be next to none due to the very nature of GAC/SN. So I have an extra assembly in storage or I have an assembly with a higher AssemblyFileVersion. That should not be the end of the world but if they are still worried about it, they really, really should have found some way to be true to the transacted nature and execution phases so that this type of problem was mitigated. And adding the CRT as a static link for C++ developers only solves some problems. It wouldn't solve my problems. I work .NET SOA SaaS installs and without getting into all the details I have about a dozen application framework blocks that have to be deployed to the GAC for consumption across WebUI, WebServices ( 80+ ) and WindowsServices. The ASP.NET is fine because the assemblies won't be needed until the sites are accessed and the content JIT'd. But the WindowsServices need the files ( it's basically a client that consumes the web services ) The customer pays the bills and they say 1) don't copy the assemblies local 2) start the service right away 3) avoid a reboot. So while I could argue to change the code to break the dependency on the GAC, it ain't going to be happening. Rob Mensching [EMAIL PROTECTED] wrote: I don't know where to reply to this thread so I thought I'd just start here. Personally, in the list of all the technologies to blame, I blame Fusion. Fusion is the technology under the GAC (Fusion is actually a code name for a few things but the GAC is very much Fusion's fault) and due to some (IMHO) really brain dead design decisions they created a system that doesn't interact really well with existing installation technologies. Then the C++ team did another brain dead thing (IMHO) and took a dependency on Fusion and made the C Run Time (CRT) Win32 SxS DLLs. Now we have deep, low-level, core functionality that pretty much everyone on the planet (that writes C++) needs dependent on a high level, poorly designed, data store (aka: GAC). The easiest way out of the mess and the one that I always recommend is to statically link the CRT. There are downsides (your executable is bigger for example) but your install gets so amazingly more simple that I personally can't imagine making the trade off the other way. For example, you'll notice all of the WiX custom actions statically link to the CRT so your install has no dependencies on the GAC (which are actually impossible to satisfy in the middle of an install). PS: Has anyone ever noticed how many custom actions the CRT merge modules pull in? Terrifying amounts of code to do something that should have remained simple, copy the CRT with your application. And to think, people use to argue that the GAC was going to make installation easier. Adam Majer wrote: Richard wrote: The problem isn't anything to do with Vista, its because your service has a dependency on something in the GAC and the files don't really appear in the GAC until after the Commit phase of the install. Just mark your service as starting automaticly and you shouldn't have any problem. Then Windows will start the service
[WiX-users] Power down and rollback
Sort of an odd-ball question not pertaining directly to WiX, but I couldn't find any docs on MSDN that specifically relate to this. If the power to a computer that is performing a MSI-based install is flipped off, will a roll-back be performed when the computer is powered back on? What does MSI do in this case? Thanks, Jason Swager - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom Action type 1042 and 18
Hi, Can any one give me example/How to write custom actions for following types - Type 1042. - Type 18 Thanks, -- View this message in context: http://www.nabble.com/Custom-Action-type-1042-and-18-tf4812070.html#a13768333 Sent from the wix-users mailing list archive at Nabble.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
Re: [WiX-users] Custom Action type 1042 and 18
I think you want Execute=deferred. Jim below is my custom action. CustomAction Id=LQMI_DisableInPlace FileKey=abc.exe HideTarget=no Impersonate=no TerminalServerAware=no ExeCommand=DisableBrowseInPlace Execute=immediate Return=check / When I open msi with orca, it is showing type as 2066. But I want type should be 1042 Could you tell me how to do this - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to set iis:WebVirtualDir Directory=X (Error CNDL0014 : The iis:WebVirtualDir/@Directory attribute's value, '[TARGETDIR]', is not a legal identifier)
Hello, How to set iis:WebVirtualDir Directory=X (Error CNDL0014 : The iis:WebVirtualDir/@Directory attribute's value, '[TARGETDIR]', is not a legal identifier) The problem I can't seem to get around is that anything other than TARGETDIR (which is preset to C:\something) will make the msi build fail with error like this one: C:\wix\Test.wxs(1791) : error CNDL0014 : The iis:WebVirtualDir/@Directoryattribute's value, '[TARGETDIR]', is not a legal identifier. Identifier's may contain ASCII characters A-Z, a-z, digits, underscores (_), or periods (.). Every identifier must begin with either a letter or an underscore. So my question is: How on earth do you set the Directory=TARGETDIR to anything other (a directory of my choice ;) than TARGETDIR ?? Actually I would like to go even futher and set it to [TARGETDIR]/subdir so that my virtual directories VIRTUALDIRECTORYNAME2 VIRTUALDIRECTORYNAME3 etc would point to [TARGETDIR]/subdir2 [TARGETDIR]/subdir2 etc Working config (with all virtualdirs pointing to C:/something ): iis:WebVirtualDir Id=ExistingTryOut_Test Alias=[VIRTUALDIRECTORYNAME2] Directory=TARGETDIR iis:WebDirProperties Id=IISWebVirtualDirPropertiesExisting2 Execute=yes Read=yes DefaultDocuments=default.aspx,index.aspx,index.htm,index.html, default.htm,default.html / iis:WebApplication Id=WebApplicationExisting2 Name=[WEBAPPLICATIONNAME] WebAppPool=WebAppPoolExisting iis:WebApplicationExtension Extension=* CheckPath=no Executable=[ASPNETISAPIDLL] Script=yes Verbs=GET,HEAD,POST / Shoud it be done through CustomActions? This is wix3.0 setup and ANY info is welcome. Thanks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
