[WiX-users] Arbitrary size restrictions on Patches (Bug?)
Hi, While attempting to build larger than average patches with WiX 3.0.5308.0, and using Admin Images, Pyro crashes returning the following message: pyro.exe : error PYRO0296 : An error (E_FAIL) was returned while adding files to a CAB file. This most commonly happens when creating a CAB file 2 GB or larger. Either reduce the size of your installation package, raise Media/@CompressionLevel to a higher compression level, or split your installation package's files into more than one CAB file. I'm able to build patches successfully, by shrinking the PatchFamily's. I've tested this with: 1) Older versions of WiX. 2) Other Installations. 3) Other Workstations. A clear repeatible patern has emerged. Once the cabinet exceeds (about) 720MB, Pyro crashes. I sat watching WiX's temp files in the temp folder, and there is always one WiX file which balloons (Presumably it's the cabinet). Varying the Computer running WiX causes the ultimate size the temp file can reach to vary. Using older versions of WiX doesn't make much difference. I can't get the Patch to approach 2GB, which it should be able to achieve (I believe). To work around this I've tried generating Delta Patches (command-line switch -delta), which unfortunately causes Pyro to Crash very quickly. I think this is the same problem described in Sourceforge Bugs item #1708072, which concerns arbitrary size limits on cabinets in MSI's. Can anybody suggest something constructive? Shall I raise a Bug? Regards Martin Lavelle _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009 -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Preprocessor Questions (Christopher Painter)
Hi Chris, You could use Linker Variables in your source paths ( !(wix.Var) Variables ) I've used them this way in the past without problems. The linker still tells you if it can't find a file, etc. The Compiler (Candle.exe) won't allow linker variables everywhere, but they did/do work ok in Source Paths. You'll see examples of Linker Varaibles in the WiX UI source code if you need them (e.g. src\ext\UIExtension\wixlib\) or maybe the WiX help will suffice? At one point I had several libraries working like this, but I worried that the WiX team would make the Compiler disallow this, since they don't/didn't advertise that you can use linker variables like this. So I weaned my builds away from it. Also I didn't want to maintain yet another WiX source code variant, or get stuck again on an old version of WiX. I can't think why they would object to using Linker variables this way? Hope this helps. Regards Martin Lavelle I've noticed a couple things I wonder about: Let say I use: Source=$(env.WINDIR)\notepad.exe The wixlib gets formatted as C:\WINDOWS\NOTEPAD.EXE. If I type the file name wrong, it still compiles with no errors. It's not until I consume the library in a merge module that it reports a failure. Our current build process has dozens of service family builds. I plan on implemnting fragments and libraries in these builds and then consuming the libraries in downstream builds. I'm concerned that: 1) Incorrect file paths will manifest themselves too late in the process. 2) When using a different variable like $(env.INSTALLFILES) if the directory path is different for different builds the wixlib is already formatted and the files won't line up. Does anyone have any thoughts on this? _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009 -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Small size limit on .wixout files storingMedia (2GB?)
Thanks for always responding Bob. :) Bob Arnson wrote: How big is the .msi file? 1.38GB across 18 cabinets in high compression. Largest cabinet size is 234Mb, Cabinets are External to the .msi file, uncompressed size is 6.28 GB. Most of my installations are over 2GB. I was trying to use .wixout's and/or .pdb's for patch generation. The 'Base' images were intended to be a .wixout storing media, and the Update image was to be a .pdb or a .wixout that wasn't storing media (so it would pick files from disk). The media my installations include comes from unversioned folders and I need to use relative paths. Consequentially, I only see the latest version of the media. This is mainly why I wanted to store media in a .wixout. Regards Martin Lavelle martin lavelle wrote: I infer from this message, that wixout's store media internally in one .cab, without regard to the cabing arrangements in the target installation. Is this true? Bob Arnson wrote: Yes. A .wixout duplicates the data in a package, not the structure. martin lavelle wrote: Incidentally, this .wixout can be built if the -bf flag is not set, and an msi can then be built from the .wixout. I mention this to rule out actual .cab file sizing errors. Bob Arnson wrote: How big is the .msi file? Hi, When Building .wixout's for large installations and with the -df (Bind files) switch set, Light fails with the following message: light.exe : error LGHT0296 : An error (E_FAIL) was returned while adding files to a CAB file. This most commonly happens when creating a CAB file 2 GB or larger. Either reduce the size of your installation package, raise Media/@CompressionLevel to a higher compression level, or split your installation package's files into more than one CAB file. I infer from this message, that wixout's store media internally in one .cab, without regard to the cabing arrangements in the installation. Is this true? Incidentally, this .wixout can be built if the -bf flag is not set, and an msi can then be built from the .wixout. I mention this to rule out actual .cab file sizing errors. Should I raise a bug, for this or is there a reason for this behaviour? Regards Martin Lavelle _ Hotmail® has a new way to see what's up with your friends. http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009 -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Small size limit on .wixout files storing Media (2GB?)
Hi, When Building .wixout's for large installations and with the -df (Bind files) switch set, Light fails with the following message: light.exe : error LGHT0296 : An error (E_FAIL) was returned while adding files to a CAB file. This most commonly happens when creating a CAB file 2 GB or larger. Either reduce the size of your installation package, raise Media/@CompressionLevel to a higher compression level, or split your installation package's files into more than one CAB file. I infer from this message, that wixout's store media internally in one .cab, without regard to the cabing arrangements in the target installation. Is this true? Incidentally, this .wixout can be built if the -bf flag is not set, and an msi can then be built from the .wixout. I mention this to rule out actual .cab file sizing errors. Should I raise a bug, for this or is there a reason for this behaviour? Regards Martin Lavelle _ Hotmail® goes with you. http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009 -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Scheduling CreateFolders under AdminExecuteSequence (repost)
The Microsoft reference on the CreateFolders Actions says The installer creates folders both for components that run locally and run from source. Doesn't this mean CreateFolders is officially approved for use during Admin Installations? (See below for link) If the AdminExecuteSequence is inflexible as you imply, the word Suggested is inappropriate. Certainly, the CreateFolders Action should not be included in the AdminExecuteSequence by default. I see no mention of restrictions in the Microsoft topic Suggested AdminExecuteSequence. It's just a table dump actually. I'm becoming concerned that an expert of your stature, disaproves so strongly. Have you had problems with this sort of thing? Bob Arnson wrote: That's not how an admin installation works: It's essentially just your source media laid out. MSI enforces restrictions on actions in the AdminExecuteSequence table; see Suggested AdminExecuteSequence for details. Martin Lavelle wrote: My intention is to create empty folders during an Admin Installation. The deployed application can be ran by multiple users from a network location, or be deployed locally, and the application requires empty folders in both scenarios. I'm sorry if that was not clear. In my opinion the product I am attempting to deploy fits the Admin Image scenario quite nicely, I'd be happy to talk about the specifics if you harbour any concerns. Bob Arnson wrote: It doesn't matter if WiX permitted it: MSI doesn't. A run from source feature is installed normally via InstallExecuteSequence, not AdminExecuteSequence; that's just for admin installations. martin lavelle wrote: I wish to schedule CreateFolders to run in the AdminExecuteSequence, as I am deploying program whose behaviour is effected by empty folders.To quote from MSI documentation (http://msdn.microsoft.com/en-us/library/aa368052(VS.85).aspx) The installer creates folders both for components that run locally and run from source.. I have also tested that this works correctly. The current schema will not permit the CreateFolders element to exist in the AdminExecuteSequence like so: AdminExecuteSequence CreateFolders/ /AdminExecuteSequence Does anyone object to relaxing the schema to allow this? Is there another way that I can achieve this with WiX? _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Scheduling CreateFolders under AdminExecuteSequence (repost)
My intention is to create empty folders during an Admin Installation. The deployed application can be ran by multiple users from a network location, or be deployed locally, and the application requires empty folders in both scenarios. I'm sorry if that was not clear. In my opinion the product I am attempting to deploy fits the Admin Image scenario quite nicely, I'd be happy to talk about the specifics if you harbour any concerns. Bob Arnson wrote: It doesn't matter if WiX permitted it: MSI doesn't. A run from source feature is installed normally via InstallExecuteSequence, not AdminExecuteSequence; that's just for admin installations. martin lavelle wrote: I wish to schedule CreateFolders to run in the AdminExecuteSequence, as I am deploying program whose behaviour is effected by empty folders.To quote from MSI documentation (http://msdn.microsoft.com/en-us/library/aa368052(VS.85).aspx) The installer creates folders both for components that run locally and run from source.. I have also tested that this works correctly. The current schema will not permit the CreateFolders element to exist in the AdminExecuteSequence like so: AdminExecuteSequence CreateFolders/ /AdminExecuteSequence Does anyone object to relaxing the schema to allow this? Is there another way that I can achieve this with WiX?RE:Scheduling CreateFolders under AdminExecuteSequence (repost) _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Scheduling CreateFolders under AdminExecuteSequence
Hi, I wish to schedule CreateFolders to run in the AdminExecuteSequence, as I am deploying program whose behaviour is effected by empty folders. To quote from MSI documentation (http://msdn.microsoft.com/en-us/library/aa368052(VS.85).aspx) The installer creates folders both for components that run locally and run from source.. I have also tested that this works correctly. The current schema will not permit the CreateFolders element to exist in the AdminExecuteSequence like so: Does anyone object to relaxing the schema to allow this? Is there another way that I can achieve this with WiX? Many Thanks Martin Lavelle _ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009 -- 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
[WiX-users] Dropping the BOM
Hello, The Byte Order Mark is removed from xml text files when WiX XmlConfig editing is applied. I've just found this out the hard way, as it breaks some DotNet programs (I imagine it depends on the methods used to address the data). I've created bug 2101670 for this. Any chance of a quick fix? It's not a very obvious bug/feature, and users won't see this one coming. Incidentally, how are WiX extensions handling UNICODE file edits? Regards Martin Lavelle - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ClearCase Dynamic View issue
Hi, I didn't think bug APAR PK14674 was applicable, because some of the programs were working, and all permissions were set for Owner and Group (Not for Other). But you were right to ask, because that fixed it! So you can successfully embed WiX into a ClearCase VOB. Thanks very much for that Rene, and a big Thank you to everyone who took the trouble to think about my problem. Best Regards Martin Lavelle Subject: RE: [WiX-users] ClearCase Dynamic View issueDate: Sat, 26 Jan 2008 12:19:29 +0100From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net I assume you found this technote: http://www-1.ibm.com/support/docview.wss?ratlid=cctocbodyrs=984uid=swg21222178 Van: [EMAIL PROTECTED] namens martin lavelleVerzonden: vr 1/25/2008 14:37Aan: [EMAIL PROTECTED]: [WiX-users] ClearCase Dynamic View issue Hello,Whilst stored under ClearCase source control and running from a Dynamic View, some of the WiX V3 and V2 executables fail with the following error message:This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.The programs which fail are:Light.exe.Setup.exe.1) It fails on ClearCase Dynamic views, but succeeds on ClearCase static views. There is more latency on a Dynamic view and it uses a different file system (mvfs).2) All the programs are permissioned identically.3) Since some programs do work, Security (caspol, etc) is not the issue.4) If copied to another location, all programs start working.5) All the WiX files are present (this error message will appear if certain files are missing).Running the Compiler from a non-ClearCase location is an acceptable temporary workaround, but has irritating long-term issues.As ClearCase Dynamic views suffer an initial latency when accessing files, I wonder if Light.exe is not waiting long enough for its file checks to return?Is Light.exe able to tolerate long initial latencies when doing its initial WiX integrity checks?Does anyone have any useful suggestions? Best Regards Martin Lavelle Climb to the top of the charts! Play the word scramble challenge with star power. Play now! This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. _ Climb to the top of the charts! Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ClearCase Dynamic View issue
Hello,Whilst stored under ClearCase source control and running from a Dynamic View, some of the WiX V3 and V2 executables fail with the following error message: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. The programs which fail are: Light.exe.Setup.exe. 1) It fails on ClearCase Dynamic views, but succeeds on ClearCase static views. There is more latency on a Dynamic view and it uses a different file system (mvfs).2) All the programs are permissioned identically.3) Since some programs do work, Security (caspol, etc) is not the issue.4) If copied to another location, all programs start working.5) All the WiX files are present (this error message will appear if certain files are missing). Running the Compiler from a non-ClearCase location is an acceptable temporary workaround, but has irritating long-term issues. As ClearCase Dynamic views suffer an initial latency when accessing files, I wonder if Light.exe is not waiting long enough for its file checks to return? Is Light.exe able to tolerate long initial latencies when doing its initial WiX integrity checks? Does anyone have any useful suggestions? Best Regards Martin Lavelle _ Climb to the top of the charts! Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Release 3.0.3328.0 Assemblies won't bind
Hi, I get the following error when running the Candle.exe in the WiX Release 3.0.3328.0 : Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'wix, Version=3.0.3328.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'wix, Version=3.0.3328.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' I suspect it's caused by the recent Strong Name changes made by PMarcu, because Release 3.0.3307.0 doesn't give any such problems, and the candle.exe.config in that file has significantly less in it. Or I could be completely wrong... Please advise if you want a bug raised. Regards Martin. _ The information contained in this message, together with any attachments, may be legally privileged or confidential and is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify us immediately before deleting it. This message has been checked for all known viruses through MessageLabs Virus Control Centre, for and on behalf of the AVEVA Group. Although no viruses were found it is the recipient's responsibility to ensure that this message is safe for use on their system. AVEVA Group plc is a Public Limited Company registered in England with registered number 2937296. The registered office of AVEVA Group plc is High Cross, Madingley Road, Cambridge, England CB3 0HB- 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] File Search that returns a folder path
This simple example returns the folder path of notepad.exe to the property NOTEPAD_FOLDER (If it finds it). Appsearch Table Property | Signature NOTEPAD_FOLDER | NotepadFolderSignature DrLocator Table Signature | Parent| Path | Depth --- NotepadFolderSignature| NotepadFileSignature NotepadFileSignature| || 5 Signature Table Signature | FileName NotepadFileSignature|notepad.exe Bob Arnson wrote:If you have current MSI rows that work, you should post them; that might help. Martin Lavelle wrote:I'm trying to author a file search that returns the folder path of a file search. In other words, I don't want the file name on the end of the path.My Property / DirectorySearch / FileSearch attempts just won't create the right table entries, will someone show me how to do this please.Incidentally, I've tried using Dark.exe to reveal the WiX syntax, but without success. _ See what you’re getting into…before you go there. http://newlivehotmail.com- 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
[WiX-users] File Search that returns a folder path
Hello, I'm trying to author a file search that returns the folder path of a file search. In other words, I don't want the file name on the end of the path. My Property / DirectorySearch / FileSearch attempts just won't create the right table entries, will someone show me how to do this please. Incidentally, I've tried using Dark.exe to reveal the WiX syntax, but without success. The Dark.exe on the V2 stream makes WiX code which does not regenerate the original AppSearch, DrLocator and Signature tables, whilst Dark.exe on the V3 stream just crashes (because of this). Best Regards Martin Lavelle - 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
[WiX-users] Access Violation whilst cabing
Hello,I am getting the following error with WiX V3.0.2806.0 and V3.0.2716.0: Creating cabinet 'C:\WiX\SchemaV3\CabCache\Marine1.cab'.light.exe : error LGHT0001 : Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Exception Type: System.AccessViolationException Stack Trace:at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.CabInterop.CreateCabFinish(IntPtr contextHandle)at Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Dispose()at Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.CreateCabinet(CabinetWorkItem cabinetWorkItem)at Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.ProcessWorkItems()Generating database. It succeeds if I reduce the number of files in the particular cabinet which is failing.All the files will cab, but not all at once.Substituting several small files, with one or two larger (overall) files, does not solve the problem.The problem is repeatable:1) On different OS's and Hardware.2) With 1 or 2 threads, or without specifying threads (e.g. -ct 2).3) With Cabinet Cache (-cc) specified or not.4) With a different [EMAIL PROTECTED] Number (Not tried Media=1).5) With different versions of the .Net framework runtime.I've ran the whole build from my C:\ drive to eliminate Network and Source repository possibilities.I can't get the Cabinet larger than 577,667,792 Bytes. I can't see a bug for this one, though bug 1672584 might be connected.If you think it merits a bug, please advise. Regards Martin Lavelle. _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE- 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] Getting current shared application data folder
Hi Richard, Read this article, specifically the CommonAppDataFolder property. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/s ystem_folder_properties.asp Regards Martin Lavelle From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Foster, Richard - PAL Sent: Tuesday, June 27, 2006 8:58 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Getting current shared application data folder Greetings all, I'm sure this question has been asked many times... but I can't find it in the archives so I guess I'm searching for the wrong thing. The application we are installing references a database (MDB) file. It is required that the user has the option to install a preconfigured sample database. Because the database is both read, and written, and is shared across all users on the machine, it seems appropriate that the file be installed to a sensible location. According to the Designed for Windows XP spec, the location in question should be determined using a request to SHGetFolderPath specifying CSIDL_COMMON_APPDATA, then appending the correct company and product folders. How do I make the call to SHGetFolderPath in WiX? (Presumably it's a custom action somewhere, but an example would be appreciated!) On a related note, is there any way to ensure that the folder in question is writeable by all users, or is that automatically the case (unless overridden by an administrator). Regards, Richard attachment: winmail.datUsing 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
[WiX-users] job postings...
Hello, Why not refer professional requests to a neutral freelancing resource. http://www.freelancers.net/ is one such possibility, I'm sure there are others. As long as you publicise where you are referring Job requests, WiX Professionals will converge on it. Your instincts to keep commercial self interest out of the forums are Jokeright on the money/Joke. In time the mailing lists will turn into a self promoting bun fight, and community spirit will suffer. WinkAlternatively, just send them all to me, problem solved!/Wink Martin. -- Date: Tue, 20 Jun 2006 16:35:28 -0700 From: Rob Mensching [EMAIL PROTECTED] Subject: [WiX-users] job postings... To: WiX-users@lists.sourceforge.net I recently had some people ask me if it would be okay for them to send out job requests to this mailing list. I thought about it and I was conflicted. On one hand, this is place to talk about the WiX toolset, how to use it, and how to improve it. Job postings don't belong here. On the other hand, the people that hang out here would likely be very good matches for some of the positions I've heard queries for. I'm still leaning towards my initial feeling (No) but I thought I might as well just ask here to see what everyone else felt. ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
