Re: [WiX-users] Not able to install votive
It's been a while since I've touched Votive 2 code so my memory may be hazy, but I don't think Votive 2 is supported under VS 2008. It's designed for VS 2003/2005. If you want to use VS 2008, I recommend upgrading to Votive 3. Even if Votive 2 works under VS 2008, there has been so much added to Votive 3 (bug fixes and features) that it's definitely worth your while trying it out. Justin -Original Message- From: Murtaza Chowdhury [mailto:murta...@microsoft.com] Sent: Wednesday, January 21, 2009 2:21 AM To: wix-users@lists.sourceforge.net Cc: Mayank Chhajed Subject: [WiX-users] Not able to install votive When I try to install Votive 2.0.5805.0 on Visual Studio 2008, I get the following error message : WIX Toolset Visual Studio Package requires the Standard, Professional, or Team editions of Visual Studio; Express editions are not supported. I have the Team edition and not the express edition but somehow votive thinks that the other way. Has anybody come across this problem. What is the resolution ? Any pointers will be highly appreciated. Regards, Murtaza Chowdhury -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive (3.0.4318.0) with VS2005
This looks like a Votive bug and not a configuration issue. Please log a bug for this on the SourceForge site: https://sourceforge.net/tracker2/?group_id=105970atid=642714 Thanks, Justin -Original Message- From: David KILLICK [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2008 11:04 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive (3.0.4318.0) with VS2005 Is anyone able to help me with this ? Votive is listed in the Product details section of the WiX entry of the VS2005's Help / About MS VS ... pop-up dialog that lists Installed products. Here's the snippet I see ... Windows Installer XML Version 3.0 Votive - Windows Installer XML (WiX) Toolset, Version 3.0.4318.0 Copyright (c) Microsoft Corporation. All rights reserved. So is this a Votive bug I'm dealing with rather than a dev env setup problem ? From: David KILLICK Sent: Wednesday, 19 November 2008 13:37 To: 'wix-users@lists.sourceforge.net' Subject: Votive (3.0.4318.0) with VS2005 I am wondering if I have missed any steps to install Votive for use with VS2005 ... ProjectAggregator2.msi was installed first, then Wix-3.0.4318.0.msi. Other than not getting descriptive error messages (just error code numbers - the subject of my earlier posting), things seem to be working until I decided to try to specify the output directory for the generated *.msi file ... Since the WiX project properties only allows the base output file name to be specified (no directory path permitted), I added the following Post-build Event Command Line: copy /y $(TargetPath) $(SolutionDir) Now when I press the Build Solution button in VS2005, the output window reports the following (see the copy command line): -- Build started: Project: IPDS_Installer, Configuration: Debug x86 -- C:\Program Files\WIXv3\bin\candle.exe -dDebug -dDevEnvDir=*Undefined if not building from within Visual Studio* -dSolutionDir=*Undefined if not building a solution or within Visual Studio* -dSolutionExt=*Undefined if not building a solution or within Visual Studio* -dSolutionFileName=*Undefined if not building a solution or within Visual Studio* -dSolutionName=*Undefined if not building a solution or within Visual Studio* -dSolutionPath=*Undefined if not building a solution or within Visual Studio* -dConfiguration=Debug -dOutDir=bin\Debug\ -dPlatform=x86 -dProjectDir=C:\IPDS\Dev\DI3_Installer\ -dProjectExt=.wixproj -dProjectFileName=IPDS_Installer.wixproj -dProjectName=IPDS_Installer -dProjectPath=C:\IPDS\Dev\DI3_Installer\IPDS_Installer.wixproj -dTargetDir=C:\IPDS\Dev\DI3_Installer\bin\Debug\ -dTargetExt=.msi -dTargetFileName=IPDS_Installer.msi -dTargetName=IPDS_Installer -dTargetPath=C:\IPDS\Dev\DI3_Installer\bin\Debug\IPDS_Installer.msi -out obj\Debug\Product.wixobj -arch x86 -ext C:\Program Files\WIXv3\bin\WixNetFxExtension.dll -ext C:\Program Files\WIXv3\bin\WixUtilExtension.dll Product.wxs C:\Program Files\WIXv3\bin\Light.exe -ext C:\Program Files\WIXv3\bin\WixNetFxExtension.dll -ext C:\Program Files\WIXv3\bin\WixUtilExtension.dll -out C:\IPDS\Dev\DI3_Installer\bin\Debug\IPDS_Installer.msi -pdbout C:\IPDS\Dev\DI3_Installer\bin\Debug\IPDS_Installer.wixpdb obj\Debug\Product.wixobj copy /y C:\IPDS\Dev\DI3_Installer\bin\Debug\IPDS_Installer.msi *Undefined if not building a solution or within Visual Studio* The syntax of the command is incorrect. C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(1859,5)Error MSB3073: Done building project IPDS_Installer.wixproj -- FAILED. Build FAILED. == Build: 0 succeeded or up-to-date, 1 failed, 0 skipped == Why are so many of the macros defined as *Undefined if not building [a solution or] from within Visual Studio* when I am building a solution from within the VS2005 IDE ? It seems that Votive is not properly registered with VS2005 ... the VS2005 Tools / Add-In Manager does not report the presence of WiX or Votive (should it?). I can't find any additional information about this in either the wix.chm file or on the WiX/Votive web home pages to continue debugging where things are going awry. Thanks. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
Re: [WiX-users] Add reference to setup project in Visual Studio 2008
Unfortunately .vcproj references aren't supported because they're not MSBuild compliant. There is a feature request out there to add this support, but my guess is that it won't happen for a while. Sorry. :( Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ding Sent: Monday, September 08, 2008 3:53 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Add reference to setup project in Visual Studio 2008 Hello, I am using Wix v3 in Visual Studio 2008 and trying to add my application project to the reference of my setup project by using Add Reference on the Reference node under My Setup project. The Wix 3 documentation gives an example on this by creating an new application with choosing the Add to Solution option in the Solution drop-down list, so under the Add Reference on the Reference node under MySetup project, I can see the application project under the Project tab, then select and add it in. But in my case, my application is an existing project, there is nothing listed under Project tab, so I go to Browse to select the .vcproj, but it gives me the error msg after click the Ok button to leave the dialog: not a wix reference file type. Any idea why this happens and how to add the Wix to my application build process? Any help would be appreciated. Jason, a first time Wix user - 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 - 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] Integration of WiX v3 on team build server
I believe that WiX should just work with TFS since we use MSBuild. Admittedly, I haven't tried TFS builds before, but from what I understand, they're also driven by MSBuild. My guess is that you're not defining $(WixTargetsPath) early enough - you Import Project=yourproject.wixproj / before defining $(WixTargetsPath). If that's the case, you just need to make sure you define $(WixTargetsPath) before importing the wixproj file. Perhaps I'm misunderstanding your question, however. I do know that there are teams that successfully use TFS with building wixproj files, though, so it should work. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Berkovich Sent: Monday, July 07, 2008 1:41 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Integration of WiX v3 on team build server Jonh, This is a reason that I am trying to inegrate WiX on build server in this way, Thanks that you wrote those reason. Did anybody have any idea how to do it? I have found some ugly way to pass parameters: I just write some task that add all my required properties to task.BuildEngine.GlobalProperties collection, but I am doing it by reflection, since task.BuildEngine implement IBuildEngine inerface, where class that implement this interface is : Microsoft.Build.BuildEngine.EngineProxy. So I am looking for more nice way to integrate WiX to team build. Dima On Mon, Jul 7, 2008 at 11:33 PM, John Nannenga [EMAIL PROTECTED] wrote: 2 big benefits I can think of: 1) Machine maintenance If you have 5 build machines, you don't have to update WiX on all 5 of the build machines. The synch process pulls down the appropriate WiX version during the build process. 2) Large projects that share Build machines don't need to all share the same version of WiX. Individual projects within a greater product build process could use different /specific versions of WiX. If 1 of your 50 projects needs to move to a later version of WiX (bug fixes, feature enhancements, etc...) it can do so without wondering what side effects might be introduced to the other projects should they all have moved to the later version of WiX. Etc... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Monday, July 07, 2008 3:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Integration of WiX v3 on team build server How would you expect the build server to be able to use the WiX tools without them being installed? I mean, strictly speaking you don't need to install them, just make them available. But what would be the benefit? Chris On Mon, Jul 7, 2008 at 4:01 PM, Dmitry Berkovich [EMAIL PROTECTED] wrote: Hi, I want compile WiX projects on team build server, but I don't want install WiX on build server, so I am planning add all needed files to source control. I have some problem when I am compile wixproj file. wixproj file contains those 2 lines: WixTargetsPath Condition= '$(WixTargetsPath)' == '' $(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets/WixTargetsPath Import Project=$(WixTargetsPath) / Since WiX not installed on build machine I override CoreCompile target of Microsoft.TeamFoundation.Build.targets in my TFSBuild.proj file, so I can transfer WixTargetsPath to MSBuild task. The problems that build failed since I have error: Solution file warning MSB4122: Scanning project dependencies for project MyProj.wixProj failed. Blablabla since WixTargetsPath not exist. What I need to do to resolve this problem? Thanks in advance, Dima - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential
Re: [WiX-users] Wixlibs and Votive
Please report bugs for both of these issues. They're separate issues. For #1 are you adding the .wixlib as a reference or the project that builds the .wixlib as a reference (one is a file reference the other is a project reference)? The code is slightly different between the two, which is why I ask - you don't have to answer this email, you can just include that information in the bug. Thanks for the bug report! Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm Sent: Thursday, July 03, 2008 12:09 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Wixlibs and Votive I have a couple of problems with Votive and wixlibs: 1. I have created a wixlib file with the files embedded in to it. When I try to add this as a reference to a votive project it says A reference to myfile.wixlib could not be added. Please make sure that the file is accessible, and that it is a valid reference. If I add the command line to the wixlib to the linker additional parameters the setup builds correctly. Should it be possible to add my own wixlib to a project? Am I adding it correctly? 2. For the wixlib project the bind files into the library file doesn't seem to do anything. Looking it at the project file nothing is set and the lit command line doesn't include the -bf option. Is this a known problem or should I report a bug? Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Mixed-case guids
Can you explain what you mean by proper GUIDs? I wasn't aware that Votive was generating bad GUIDs. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Shevchuk Sent: Thursday, June 12, 2008 3:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Mixed-case guids Votive generates Product ID and UpgradeCode GUIDs which, from the Windows Installer point, are wrong. That may not be an issue if we assume that nobody will enhance msi files manually or using Windows Installer API and using GUID from Votive-generated template. I'd rather see a warning from the compiler when GUIDs are not upper-cased and Votive to generate proper GUIDs. That way people will come to a habit of using proper GUID values and that might save them time later on fighting some strange problems in their installers because of bad GUID. Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ginchereau Sent: Thursday, June 12, 2008 12:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Mixed-case guids Candle upper-cases the guids for you. But many other MSI tools and APIs don't, so one could make a pedantic argument that it's better to have them upper-case in the source code for better copy-pasting. -Jason- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns Sent: Thursday, June 12, 2008 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Mixed-case guids Does Votive do the actual conversion or is it candle.exe? Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Shevchuk Sent: Thursday, June 12, 2008 12:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Mixed-case guids Does anyone know why mixed-case guids generate and error from candle if you turn on the -pendantic flag? Is it just a coding style or is there a problem with them? (It looks like candle forces them uppercase in the wixobj file.) That's because GUID type in windows installer (http://msdn.microsoft.com/en-us/library/aa368767(VS.85).aspx) requires letters to be uppercase. The fact that Votive creates GUIDs in mixed case and silently converts them to upper case during compilation is another story. Alex PS. Weird. I had to subscribe again to be able to send this response. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Mixed-case guids
Votive does not do any conversion. We tried to get all uppercase letters for the GUID, but Visual Studio automatically generates those when it creates the project templates. There may be a way around it by using the Wizard infrastructure, but it was a low priority item. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns Sent: Thursday, June 12, 2008 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Mixed-case guids Does Votive do the actual conversion or is it candle.exe? Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Shevchuk Sent: Thursday, June 12, 2008 12:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Mixed-case guids Does anyone know why mixed-case guids generate and error from candle if you turn on the -pendantic flag? Is it just a coding style or is there a problem with them? (It looks like candle forces them uppercase in the wixobj file.) That's because GUID type in windows installer (http://msdn.microsoft.com/en-us/library/aa368767(VS.85).aspx) requires letters to be uppercase. The fact that Votive creates GUIDs in mixed case and silently converts them to upper case during compilation is another story. Alex PS. Weird. I had to subscribe again to be able to send this response. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error accessing Visual Studio project settings
Are you having these problems in VS 2005 or VS2008? The code is different between the two, so it really helps us if we know which version. I assume it's 2005. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Bleckner Sent: Tuesday, June 03, 2008 11:51 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error accessing Visual Studio project settings Has anyone seen anything like this before? I have a WiX project that used to behave correctly in Visual Studio. However, when I now try to view the project settings now I get an error that says Could not load type 'System.ComponentModel.PropertyChangingEventHandler' from assembly 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a4c561934e089'. This error loads on every panel I try to view (Installer, Build, Build Events, etc). If I try to go back to one of my previously selected panels I get a new error: An error occurred trying to load this page. Unable to create the designer. File is already opened in an incompatible editor. I tried creating a new project but immediately got the same errors there too. I think (and hope) this is the main problem for a bunch of ugliness with my Visual Studio project. I can do a single a successful build, but after that all builds say Unhandled Exception: The build was aborted because of an unexpected logger failure. I need to restart Visual Studio before it starts working again (for one more build). And, just to make things even more fun, attempting to close Visual Studio after a successful build causes Visual Studio to crash instead of close... Any ideas? - 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 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ 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
Interesting discussion so far. I just wanted to chime in a little here. I think Mathias is correct here in stating that there are some real problems with Windows Installer (and thereby Wix in its current form). I work on the dang thing but I still get frustrated at Windows Installer. It's just too hard to do simple things. Right now, Wix is a wrapper on top of MSI, and while we are trying to make things simpler by bundling in custom actions, providing some guidance on how to write correct installers, providing a development environment via Votive, etc. we still have a long, long way to go before it's really easy for devs not conversant in all of the intricacies of MSI. We'll get there eventually, but slowly. As always, we are open to constructive feedback and will try our best to pass on some of your feedback to the Windows Installer group. Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin MacPherson Sent: Thursday, May 15, 2008 2:14 AM To: Holmgren Mathias Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] yep - back to being 100% frustrated http://johnmcfadyen.spaces.live.com/ 2008/5/15 Holmgren Mathias [EMAIL PROTECTED]: Don't blame the tools as there are plenty of people out there using these tools and making them work seemlessly and quickly on a day to day basis. Well, you can't just disregard the large majority of people who are struggling a lot with this. And you can't disregard the developer perspective, because developers are the people that have to deal with this. Sure, one part of the story is about expectations and the learning curve of installation. Before building an installation package, you expect it to be pretty easy, like a couple of days work. Then when you start doing it you find out that the level of investment necessary to complete a working real world installer is not 10 but maybe 100 times greater than what you expected, or more (yes, for real, I'm not making this up). And we are talking very experienced people here, not rookie devs. Having to invest your time so heavily to get so little tangible result back is a shock to most people. And when all the bumps, twists and turns of the technology are added on top of that learning process there will be frustration. Now, I'm not much for nursing cry baby mentality either. It will get you nowhere. But I do feel that there is a case to be made here about not putting up with things that are overburdening. This is the other part of the story. If the tools can be improved to make installation simpler, why settle for less? Or are installer technology and the tools already as good as they can ever become? No. Identify the stuff that can be made easier with better tools. Reduce some of the burden of that complexity you are referring to and streamline the more common stories to ease the learning curve. That's what should be done. http://john.mcfadyen.spaces.live.com http://john.mcfadyen.spaces.live.com/ Domain lookup of that comes up blank. Do you have another link? I sure could use some info on those undocumented features. /Mathias - 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 - 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] Did WiX V3 projects break compatibility with earlier builds?
That's a pretty good summary of the MPF. J To answer your question more completely. VB/C#/C++ were all written using the native C++ project system that was in existence years before MPF even came about. MPF is part of the Visual Studio SDK and was written originally as a port of the C++ code. The problem (IMHO) is that the native code project system was flawed in its design to begin with. It was overly complex and burdensome to work with. The VS SDK team had a golden opportunity to clean it up and make it so much easier to use when creating a new SDK for Visual Studio based on managed code. Unfortunately, I don't think they got it right. Interestingly, in Votive 2.0 I had written my own SDK that was a lot easier to use than the MPF (it was before the MPF was around). I think knowing what I do now about the MPF and the bugs/lack of features, I might not have switched over to it. At any rate, I don't foresee VB/C#/C++ being rewritten to use the MPF since it is not up to par (yet). Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Caton Sent: Wednesday, May 14, 2008 9:53 PM Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? Scott: MPF stands for 'Managed Package Framework', an incomplete and buggy framework for building project systems that integrate into Visual Studio. It's part of the Visual Studio SDK. Consider yourself lucky that you don't have to deal with it. Don From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Wednesday, May 14, 2008 9:43 PM To: Justin Rockwood Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? It seems the real bug then is that there are two code paths... VB/C/C++ should be implemented via the MPF stuff as well... then this never would have happened. I say this still not knowing what MPF stands for or anything about it though. Scott On 14-May-08, at 10:45 AM, Justin Rockwood wrote: No, other projects that are not based on the MPF (which includes VB/C#/C++) do not lock because they do not have that bug. However, projects that are based on the MPF (IronPython, if I remember correctly) do exhibit the same bug that WiX has. This bug, in my mind, is one of the most annoying ones that should have higher priority (along with the other one that you pointed out - same line output). Thanks for the bug reports! Justin From: Scott Palmer Sent: Wednesday, May 14, 2008 7:14 AM To: Justin Rockwood Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? On Tue, May 13, 2008 at 7:05 PM, Justin Rockwood wrote: I hate the locking as well. Unfortunately, this is a bug in the MPF (the Visual Studio SDK) that they have not fixed yet. We will have to just fix it on our own instead of waiting for a fix from them. Note that it's not a trivial fix either because it requires a separate thread to do the build. Are you saying that other tasks like compiling and linking C/C++ code lock things the same way.. but I assume for short enough periods of time that it isn't noticeable? I'm just wondering why I only notice this with WiX projects. ... - 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] Did WiX V3 projects break compatibility with earlier builds?
No, other projects that are not based on the MPF (which includes VB/C#/C++) do not lock because they do not have that bug. However, projects that are based on the MPF (IronPython, if I remember correctly) do exhibit the same bug that WiX has. This bug, in my mind, is one of the most annoying ones that should have higher priority (along with the other one that you pointed out - same line output). Thanks for the bug reports! Justin From: Scott Palmer [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 14, 2008 7:14 AM To: Justin Rockwood Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? On Tue, May 13, 2008 at 7:05 PM, Justin Rockwood [EMAIL PROTECTED] wrote: I hate the locking as well. Unfortunately, this is a bug in the MPF (the Visual Studio SDK) that they have not fixed yet. We will have to just fix it on our own instead of waiting for a fix from them. Note that it's not a trivial fix either because it requires a separate thread to do the build. Are you saying that other tasks like compiling and linking C/C++ code lock things the same way.. but I assume for short enough periods of time that it isn't noticeable? I'm just wondering why I only notice this with WiX projects. That's not too bad, but then you have to jump through some hoops to communicate progress back to the UI thread and get the COM marshalling to work correctly with the Visual Studio shell. I worked on this for quite a bit way back in Votive 2.0 and didn't end up finding an adequate solution. I'm not saying there isn't a fix (there obviously is), it's just not an easy fix. Ah yes - COM hell. Been there many times. Scott - 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] Did WiX V3 projects break compatibility with earlier builds?
I hate the locking as well. Unfortunately, this is a bug in the MPF (the Visual Studio SDK) that they have not fixed yet. We will have to just fix it on our own instead of waiting for a fix from them. Note that it's not a trivial fix either because it requires a separate thread to do the build. That's not too bad, but then you have to jump through some hoops to communicate progress back to the UI thread and get the COM marshalling to work correctly with the Visual Studio shell. I worked on this for quite a bit way back in Votive 2.0 and didn't end up finding an adequate solution. I'm not saying there isn't a fix (there obviously is), it's just not an easy fix. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Tuesday, May 13, 2008 1:10 PM To: Scott Palmer Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? I know what you are saying here. I don’t know enough about the Visual Studio architecture to understand why this happens but I’ll ask the guys working on Votive again. PS: I know what is taking forever in light.exe, two things. 1. Cabinet creation is I/O intensive and can take a while. 2. ICE validation is very intensive. ICE03 is the big offender and we’re still trying to determine if we can just turn ICE03 off and let light.exe do all of the same checks. Verifying “conditional syntax” is still a problem. From: Scott Palmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 13, 2008 12:37 To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? I take it back 4102 crashes visual studio... The huge lock ups I could tolerate... barely. Why doesn't someone address the issue where running Light.exe locks up the entire dev environment (let alone bring the entire machine to a crawl) for several minutes? I always laugh at the little pop-up that says Visual Studio is not responding. If this happens frequently contact Microsoft. - Is always frequently enough? Scott On Tue, May 13, 2008 at 3:00 PM, Scott Palmer [EMAIL PROTECTED] wrote: 4102 works better.. though it still has problems with Light output. The text description of errors is missing - you just get a code, and it's all on one line in visual studio. Scott On Tue, May 13, 2008 at 12:02 PM, Scott Palmer [EMAIL PROTECTED] wrote: Cool thanks. Another thing... I dropped in an older wix.targets file so I could do a build and noticed that output from Light didn't have the right line-endings.. everything showed up on one line in the dev studio output window.. The build was done and I didn't even know it because the message was *way* off to the right. Regards, Scott On Tue, May 13, 2008 at 11:51 AM, Rob Mensching [EMAIL PROTECTED] wrote: I just saw a bug get opened about the build targets having issues. Try 4102 and if that fixes the problem then you probably are seeing the same bug. I'll make sure the bug gets fixed by the next build. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Tuesday, May 13, 2008 08:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? I just updated WiX from the 2925 build (still the last beta posted to SF) to the May 9 weekly build 4109. Now all of my WiX project don't build. They don't even get started. I instantly get this error when trying to build: 3-- Build started: Project: Stream, Configuration: Release Any CPU -- 3C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error MSB4067: Done building project MyInstallerProject.wixproj -- FAILED. 3 3Build FAILED. Reverting to build 3907 appears to fix the problem. What am I doing wrong? I searched the email list and didn't find MSB4067 anywhere. Scott - 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] Did WiX V3 projects break compatibility with earlier builds?
The long lines in VS 2005 has been around for a while. This is due to a bug in Visual Studio 2005 that was fixed in Visual Studio 2008. There are some ways around this bug, but none of them are pretty. We'll have to take another look at it and see what we can come up with. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Tuesday, May 13, 2008 1:43 PM To: Scott Palmer Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? Yeah, unfortunately “1200” == “one year”. Okay, I’m going to kick Justin to go back and look at VS2005. I’m more and more certain that behavior is regressing badly on that codebase and not being tested except by people picking up new drops. I appreciate any bug fixes you can open and please do note if you're are using VS2005. From: Scott Palmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 13, 2008 13:19 To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds? Yes, I am using VS2005. The 2925 build on SourceForge works properly with the line endings. That narrows it down to only around 1200 builds :-) Regards, Scott On Tue, May 13, 2008 at 4:12 PM, Rob Mensching [EMAIL PROTECTED] wrote: The line endings is a different bug that has been open for a long while. Again, I don't understand Visual Studio integration well enough to know what is causing this. Are you by chance running on VS2005? I'm beginning to think that because pretty much everyone working on WiX has moved to VS2008 that we're creating a huge number of regressions in VS2005. - 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] Using WixUI_InstallDir with Visual Studio 2005
It's been so long since I've looked at Votive 2.0, but I seem to remember that it doesn't support it. Just a note that Votive 2.0 was more of a preview release and we disbanded support for it when we moved to Votive 3.0. Before Christopher Painter jumps in and tells us that this is a bad customer solution J, I'll freely admit it. However, with the limited amount of developers (at the time it was just me), we decided it was best to put my efforts into making Votive 3.0 include new features than to flesh out and support Votive 2.0. That's a long-winded answer to your question. J Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Andersen Sent: Friday, April 25, 2008 8:32 AM To: Jon Andersen; Mark Line; Willie Burton Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using WixUI_InstallDir with Visual Studio 2005 Can a Votive expert help me with this? At the moment, it appears that Votive does not support the UI extension WixUI_InstallDir, but I would be happy to be proven wrong. I am using 2.0. I need to include a localization XML file for WixUI_InstallDir, but I can find no way to accomplish this entirely within Visual Studio. Is there some way to change the light.exe command-line flags WITHIN Visual Studio or the various XML files involved? Does the Votive installation include these XML files or do I ALSO need to install Wix separately? I need to add: -loc C:\Program Files\wix-2.0.5805\WixUI_en-us.wxl or the equivalent within Visual Studio. I don't want to have a parallel build system outside Visual Studio. -Jon Andersen Guardian Team: Securing CPS Citrix Systems, Inc (954) 940-7737 or x27737 This email was sent using RTST Outlook. From: Jon Andersen Sent: Thursday, April 24, 2008 4:15 PM To: 'Mark Line'; 'Willie Burton' Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Using WixUI_InstallDir with Visual Studio 2005 Is there some way to tie in the localization XML file using the Visual Studio plug in? I haven't been using makefiles, etc. -Jon Andersen Guardian Team: Securing CPS Citrix Systems, Inc (954) 940-7737 or x27737 This email was sent using RTST Outlook. From: Mark Line [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 2:44 PM To: Jon Andersen; 'Willie Burton' Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Using WixUI_InstallDir with Visual Studio 2005 Your need something like this: light -nologo -out myMSI.msi sca.wixlib, wixca.wixlib, and WixUI.wixlib C:\Program Files\wix-2.0.5805\wixui.wixlib -loc C:\Program Files\wix-2.0.5805\WixUI_en-us.wxl From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Andersen Sent: 24 April 2008 07:40 PM To: Willie Burton Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using WixUI_InstallDir with Visual Studio 2005 I'm using Wix 2.0. Currently my references listed are sca.wixlib, wixca.wixlib, and WixUI.wixlib. -Jon From: Willie Burton [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 2:37 PM To: Jon Andersen Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Using WixUI_InstallDir with Visual Studio 2005 Did you add the WixUIExtension.dll reference? _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Andersen Sent: Thursday, April 24, 2008 2:33 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using WixUI_InstallDir with Visual Studio 2005 I'm trying to use WixUI_InstallDir inside Visual Studio 2005 (with integration installed) and have run into an issue. Apparently the light linker needs to be given a localization XML file, but I can't figure out how to give it to it. The error message is: light.exe : error LHGT0122: The localization string 'WixUIOK' is unknown. Ensure that the localization variable $(loc.WixUIOK) is defined. (followed by many other similar error messages). The tutorial suggests setting the Culture property of the Linker in the project properties; however, I can't find that property. Any suggestions? Thanks, -Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX Build Bug?
The 4 registry errors are known and normal. NAnt issues errors when it can't find the registry key even when we have failOnError=false in the NAnt files. If you know of a way to get rid of those non-fatal errors we'd gladly take the fix. I've gotten used to seeing the errors, so I just ignore them. J The warning, however, is something we should fix and is what is causing your build to fail. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Friday, April 25, 2008 11:49 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX Build Bug? I've downloaded the latest WiX source package. I've got Visual Studio 2008 Pro from MSDN ( SW_DVD9_Visual_Studio_Pro_2008_English_Core_MLF_X14-26326.ISO ) and the latest Server 2008 PSDK installed aswell as the latest beta NAnt build. I try to run make.bat and I get the following error. When I look in the registry I have a Setup key with 12 subkeys... none of which are the ones the build script is looking for. C:\wix3-sourcesmake NAnt 0.86 (Build 0.86.2962.0; nightly; 2/10/2008) Copyright (C) 2001-2008 Gerry Shaw http://nant.sourceforge.net Buildfile: file:///C:/wix3-sources/wix.build file:///C:\wix3-sources\wix.build Target framework: Microsoft .NET Framework 2.0 Target(s) specified: inc [property] Read-only property dir.src.dutil cannot be overwritten. [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSDB\';hive='Microsoft.Win 32.RegistryHive[]'; [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTD\';hive='Microsoft.Win 32.RegistryHive[]'; [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTS\';hive='Microsoft.Win 32.RegistryHive[]'; [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTT\';hive='Microsoft.Win 32.RegistryHive[]'; [echo] VS Test Tools are installed. The Tests will be built. prereqcheck: BUILD FAILED - 4 non-fatal error(s), 1 warning(s) C:\wix3-sources\wix.build(120,6): Building WiX requires the Windows Server 2008 and .NET Framework 3.5 SDK or Visual Studio 2008 Total time: 0.7 seconds. C:\wix3-sources Christopher Painter, MCSE, Author of: Deployment Engineering Blog http://blog.deploymentengineering.com/ Factory Provider for ADO.NET 2.0 http://www.codeplex.com/MSIProviderI (Work In Progress) Bottles http://99-bottles-of-beer.net/language-windows-installer-1310.html Of Beer - Windows Installer _ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8H DtDypao8Wcj9tAcJ%20 it now. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Project references to unmanaged DLLs
Unfortunately, this is expected behavior. Votive does not support non-MSBuild project references, of which VC++ is one. We considered adding this support, but it's a big work item and haven't gotten around to doing it yet. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan O'Neill Sent: Thursday, April 17, 2008 9:43 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Project references to unmanaged DLLs Just tried adding a project reference to a non .Net .dll file (my C++ custom action) and Votive does not append the pre-processor definitions for it to the Candle command line. Is this expected behaviour? Makes it awkward to included non .Net dlls, the .Net references work fine. Regards Ryan - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Project references to unmanaged DLLs
Unfortunately, this is expected behavior. Votive does not support non-MSBuild project references, of which VC++ is one. We considered adding this support, but it's a big work item and haven't gotten around to doing it yet. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan O'Neill Sent: Thursday, April 17, 2008 9:43 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Project references to unmanaged DLLs Just tried adding a project reference to a non .Net .dll file (my C++ custom action) and Votive does not append the pre-processor definitions for it to the Candle command line. Is this expected behaviour? Makes it awkward to included non .Net dlls, the .Net references work fine. Regards Ryan - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] is there a way to access wixproj macro values from within wix sources
Those are good scenarios. Just a note that you can accomplish the same thing today by defining the variables yourself. You would just change the DefineConstants in your .wixproj file (either directly or via the property pages in the IDE). You can use an MSBuild defined variable, which will do what you want. So, your authoring would look like this in your .wxs file: Source=$(var.OutDir)\... In your .wixproj, you'd have the following in a PropertyGroup DefineConstantsOutDir=$(OutputPath)/DefineConstants This will work today without any bug fixes. Note that $(OutputPath) is already defined by the project systems in MSBuild. Justin From: Robert O'Brien Sent: Wednesday, April 09, 2008 6:06 PM To: Justin Rockwood; Jason Ginchereau; 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] is there a way to access wixproj macro values from within wix sources Fyi - I just updated http://sourceforge.net/tracker/index.php?func=detail http://sourceforge.net/tracker/index.php?func=detailaid=1934684group_id=1 05970atid=642717 aid=1934684group_id=105970atid=642717 with the following additional scenario for a solution/project macro variable that if it were exposed would enable wix Source= values that has not source tree hierarchy dependencies. One Solution and/or Project macro that would be great to have access to enabled if possible is $(var.OutDir) and $(var.OutputPath). The reason being is that in the case of Tfs automated building of msbuild .proj defined build types it sets the OutDir macro for all projects being built to the same destination which would make it possible to use wix Source=$(var.OutDir)\referenced assembly != var.projectName.TargetPath and have that work in both IDE and Tfs automated build cases. Also when tfs automated build executes it creates this interesting folder in the OutDir destination called _PublishedWebsites which contains a property structured drop of any web application type build output. Therefore having OutDir macro access would make it possible to do non source tree hierarchy specific wix source= references Source=$(var.OutDir)_PublishedWebsites\SomeWebApp\web.config and Source=$(var.OutDir)_PublishedWebsites\SomeWebApp\SomeWcfService.svc. From: Robert O'Brien Sent: Friday, April 04, 2008 10:57 AM To: Justin Rockwood; Jason Ginchereau; 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] is there a way to access wixproj macro values from within wix sources Done. http://sourceforge.net/tracker/index.php?func=detail http://sourceforge.net/tracker/index.php?func=detailaid=1934684group_id=1 05970atid=642717 aid=1934684group_id=105970atid=642717 From: Justin Rockwood Sent: Friday, April 04, 2008 10:38 AM To: Robert O'Brien; Jason Ginchereau; 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] is there a way to access wixproj macro values from within wix sources Sounds like a nice thing to have. Would you mind logging a feature request including the text of your message (you explained it very well)? You can do it here: http://sourceforge.net/tracker/?group_id=105970 http://sourceforge.net/tracker/?group_id=105970atid=642717 atid=642717 Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien Sent: Friday, April 04, 2008 8:55 AM To: Jason Ginchereau; 'wix-users@lists.sourceforge.net' Subject: Re: [WiX-users] is there a way to access wixproj macro values from within wix sources Having access to the Wix project project-related variables would be very helpful.The way we setup our sources is that we have every .csproj use the following project settings, and hopefully now .wixproj given msbuild support in the 3.0 work. Project ToolsVersion=3.5 DefaultTargets=Build xmlns=http://schemas.microsoft.com/developer/msbuild/2003; Import Condition='$(OpeningProjectSettings)' == '' Project=..\BuildSupportFiles\anyCpu\OpeningProjectSettings.targets / . . . Import Condition='$(ClosingProjectSettings)' == '' Project=..\BuildSupportFiles\anyCpu\ClosingProjectSettings.targets / /Project The thing we do in OpeningProjectSettings is Set the $(OutputPath) property setting for all projects so that dll, exe, msi, other output all gets placed in same folder it will get placed in when we setup tfs automated execution of per checkin and daily build msbuild .proj files.The great thing about tfs automated execution of per checkin and daily build msbuild .proj files is that it automatically sets OutDir to the build setup enlistment root/Binaries/$(Configuration). This makes authoring wix30 msi sources nice because if we could access wix project related variables we could then set the Source attribute for all File entries to use Source=$(var.OurDir) and not have to worry about baking source tree build output hierarchy knowledge into our wix sources. For the cases where the wix project itself has source files that need to be referenced, e.g. ReadMe.txt and Other
Re: [WiX-users] is there a way to access wixproj macro values from within wix sources
Sounds like a nice thing to have. Would you mind logging a feature request including the text of your message (you explained it very well)? You can do it here: http://sourceforge.net/tracker/?group_id=105970atid=642717 Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien Sent: Friday, April 04, 2008 8:55 AM To: Jason Ginchereau; 'wix-users@lists.sourceforge.net' Subject: Re: [WiX-users] is there a way to access wixproj macro values from within wix sources Having access to the Wix project project-related variables would be very helpful.The way we setup our sources is that we have every .csproj use the following project settings, and hopefully now .wixproj given msbuild support in the 3.0 work. Project ToolsVersion=3.5 DefaultTargets=Build xmlns=http://schemas.microsoft.com/developer/msbuild/2003; Import Condition='$(OpeningProjectSettings)' == '' Project=..\BuildSupportFiles\anyCpu\OpeningProjectSettings.targets / . . . Import Condition='$(ClosingProjectSettings)' == '' Project=..\BuildSupportFiles\anyCpu\ClosingProjectSettings.targets / /Project The thing we do in OpeningProjectSettings is Set the $(OutputPath) property setting for all projects so that dll, exe, msi, other output all gets placed in same folder it will get placed in when we setup tfs automated execution of per checkin and daily build msbuild .proj files.The great thing about tfs automated execution of per checkin and daily build msbuild .proj files is that it automatically sets OutDir to the build setup enlistment root/Binaries/$(Configuration). This makes authoring wix30 msi sources nice because if we could access wix project related variables we could then set the Source attribute for all File entries to use Source=$(var.OurDir) and not have to worry about baking source tree build output hierarchy knowledge into our wix sources. For the cases where the wix project itself has source files that need to be referenced, e.g. ReadMe.txt and Other stuff not coming for other solution build output, I'd want to be able to use Source=$(var.ProjectDir)... references. From: Jason Ginchereau Sent: Friday, April 04, 2008 8:31 AM To: Robert O'Brien; 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] is there a way to access wixproj macro values from within wix sources The project-related variables are only generated for project references. You don't get project variables for the WiX project itself. (Hmm... would that be a nice feature to have?) So you need to add a reference from your WiX project to another application project to get variables for that project. And as the documentation says, you need to include the project name in the variable, for example: $(var.MyAppProject.TargetPath) If you examine at the Output window of VS when you build, you can see all the available project/solution variables where they are passed on the command-line to candle.exe. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien Sent: Friday, April 04, 2008 8:13 AM To: 'wix-users@lists.sourceforge.net' Subject: Re: [WiX-users] is there a way to access wixproj macro values from within wix sources I removed the DefineSolutionPropertiesfalse/DefineSolutionProperties PropertyGroup setting from my wixproj file which I had added earlier to address the following warning (default target) (1) -(AddSolutionDefineConstants target) - C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.0\Wix.targets : warning : Solution properties are only available during IDE builds or when building the solution file from the command line. To turn off this warning set DefineSolutionPropertiesfalse/DefineSolutionProperties in your .wixproj file. that was getting generated when I built from the command line using msbuild myservicedeliverable.wixproj After making that change I can now leverage $(var.Solution*) macros, e.g. Source=$(var.SolutionDir)... but get still get the compiler error mentioned earlier if I try and use wix project macros such as $(var.ProjectDir), $(var.OutputPath), $(var.OutDir) and $(var.TargetPath). So are these ones basically n/a but if I reference a non-wix project like a csproj generated dll then I should expect that $(var.ReferencedProjectName.StandardIssueProjectMacro) variable references will work? From: Robert O'Brien Sent: Friday, April 04, 2008 7:41 AM To: 'wix-users@lists.sourceforge.net' Subject: RE: is there a way to access wixproj macro values from within wix sources Tried using $(var.ProjectDir) in a File Source attribute field and got a Undefined preprocessor variable '$(var.ProjectDir)'. compiler error. Tried using the List of Supported Project References documented $(var.SolutionDir) variable which the documentation suggests is supported and got the same compiler error, i.e. Undefined preprocessor variable '$(var.SolutionDir)'. for the following line File Id=InstalledUninstallShortcut.txt
Re: [WiX-users] Forums...
I'm not sure what Christopher is intending with his tone here, but I don't seem to remember anybody being opposed to doing anything that the community wants to do. It's just all a matter of time and resources. If the community would like to have a forum, I don't think anybody is opposed to it. Somebody just needs to set it up and pick a place for it to live. That somebody would probably have to be on the core team, just because that person would also have to be the administrator. That means that doing forum administration would also take time away from writing code, testing, or debugging the toolset. I think we're always open to suggestions. Just because we don't sometimes use a suggestion or choose to go a different way doesn't mean that we don't play well with others. Also, aren't there other forum-like venues already out there for WiX? I know there are a couple of Wiki sites and also sites that aggregate these emails. What additional value will a forum serve? (I'm not opposed to it, I'm just asking for more clarification). Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Monday, March 03, 2008 12:39 PM To: Jeremy Farrell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Forums... Yes, the answer is pretty much always `email rocks, forums suck, I'm a really important contributor and if there is ever a change I'm going to take my ball and go home.` Jeremy Farrell [EMAIL PROTECTED] wrote: Maybe no-one can remember. I can't be sure if it was here, but I've a feeling there was such discussion once. It should be possible to find out from the archives. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aurélien DEROUINEAU Sent: Saturday, March 01, 2008 1:57 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Forums... Still waiting for an answer... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aurélien DEROUINEAU Sent: vendredi 22 février 2008 13:15 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Forums... Has there been any discussion on the creation of community-driven forums? - 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 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20 - 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] Changing the file extension of WiX extensions from .dll to .wixext (Revisited)
In one of my last blog posts (http://blogs.msdn.com/jrock/archive/2008/02/13/changing-the-file-extension- of-wix-extensions-from-dll-to-wixext.aspx) I wrote about how we would be changing the file extension of WiX extensions from .dll to .wixext. Well, it turns out that we won't be doing it for technical reasons. A WiX extension is really just a .NET assembly with an embedded XSD and wixlib. While it's technically possible to rename a managed assembly from .dll to .wixext, it will add a limitation that we didn't want to enforce. If WixExtensionA.wixext had a runtime reference to WixExtensionB.wixext, then the runtime cannot find the file if it doesn't end in a .dll. I personally think that's a limitation that the .NET Framework did not need to impose, but I also do not know all of the details. I'm sure there was a good reason to impose that limitation. We also had some problems with Visual Studio not letting us add project references to other WixExtensions that didn't end in a .dll. As a result, we will not be doing this change and the current behavior will remain. Here's the full blog post: http://blogs.msdn.com/jrock/archive/2008/03/03/changing-the-file-extension-o f-wix-extensions-from-dll-to-wixext-revisited.aspx Thanks, Justin - 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] Changing the file extension of WiX extensions from .dll to .wixext
We will be doing a change that will probably affect most users of WiX v3, so I wanted to get this notice out in the community to notify people of the upcoming change. Within the next few weeks we will be changing the file extension of WiX extensions from .dll to .wixext. There are several reasons why we think this is an important thing to do, which I've blogged about. Please see http://blogs.msdn.com/jrock/archive/2008/02/13/changing-the-file-extension-o f-wix-extensions-from-dll-to-wixext.aspx for more information and how this change will affect you. How Does this Affect You? If you use any of the standard WiX custom action extensions, then you'll have to change your build scripts to reference the new names. If you use MSBuild or Votive, then you'll have to change any references you have in your .wixproj files (WixExtension elements). You can do this manually by hand-editing the .wixproj file or you can do this by removing the old references (right mouse click and select Remove) and then re-adding them. ItemGroup WixExtension Include=$(ProgramFiles)\Windows Installer XML v3\bin\WixIIsExtension.wixext / /ItemGroup We will also try to put out a similar reference for NMake and NAnt when the feature gets checked in. As always, feel free to send comments. We sent out a proposal for this change on the wix-users list about a month or so ago and got no negative feedback, so we've decided to go ahead with the change. Thanks, Justin - 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] pre-defined variables?
Thanks for the note. Here's what I responded to your comment on the blog: Mark, This should also work in Votive 2.0, although the preprocessor definitions may be slightly different than the ones I presented here. Take a look at Rob's MSDN article here (http://msdn2.microsoft.com/en-us/aa302186.aspx#wixsetup_topic9) for more information on how to do this in Votive 2.0. Sorry about the confusion. I should have pointed this out in the blog entry. Thanks, Justin -Original Message- From: mark.modrall [mailto:[EMAIL PROTECTED] Sent: Thursday, January 31, 2008 6:30 AM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] pre-defined variables? Thanks, Justin. I just commented on the blog, but I'll say the same here: If I follow the add-reference instructions above, I get a dialog saying Sorry, project references are not yet supported in Votive. If you want to add the code, by all means! :) Votive 2.0.5325 If I right-click the project itself and choose Project Dependencies, all of the right dependencies are already listed; unfortunately, that doesn't seem to connect to these variable definitions. I presume this is a 3.0-only thing? Thanks Mark -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 6:03 PM To: mark.modrall; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] pre-defined variables? I also just blogged about this, so you can check out http://blogs.msdn.com/jrock/archive/2008/01/29/complete-list-of-candle-p repr ocessor-variables.aspx. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mark.modrall Sent: Wednesday, January 30, 2008 12:53 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] pre-defined variables? Okay, are the preprocessor variables listed in http://msdn2.microsoft.com/en-us/library/aa302186.aspx only applicable to source projects? We have some Wix projects that bundle a bunch of msms into an msi. The main project has project dependencies on all of the othe Wix projects but when I put in something like Merge Id=Module1 Language=1033 src=$(var.Module1.TargetPath) DiskId=1 / (where Module1 is the name of a dependency Wix project) I get an error that $(var.Module1.TargetPath) is undefined. We're using Votive 2.0.5325 Thanks Mark - 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 - 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] pre-defined variables?
Oh, sorry. Another thing I should have probably pointed out. Referenced wix projects don't have their project preprocessor variables written out in Votive v2. It was another few Visual Studio interfaces that I didn't get around to implementing in version 2. I think in Votive v2, C#, J#, and VB work and I think C++ works as well. In Votive v3 any language that supports MSBuild should work correctly (which means that C++ projects don't work yet). Does that clarify it more? I'm probably missing some other vital piece of information that you need, in which case just ask me again. :) Justin -Original Message- From: mark.modrall [mailto:[EMAIL PROTECTED] Sent: Friday, February 01, 2008 11:42 AM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] pre-defined variables? Hi Justin... Still doesn't seem to work... At least not when the dependent project is another Wix project. $(var.project.TargetPath) is on both lists as *supposedly* supported, but when I have one wix projects merging the output msms of other projects, I just get variable-undefined errors. Would be a nice feature... Thanks Mark -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Friday, February 01, 2008 2:22 PM To: mark.modrall; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] pre-defined variables? Thanks for the note. Here's what I responded to your comment on the blog: Mark, This should also work in Votive 2.0, although the preprocessor definitions may be slightly different than the ones I presented here. Take a look at Rob's MSDN article here (http://msdn2.microsoft.com/en-us/aa302186.aspx#wixsetup_topic9) for more information on how to do this in Votive 2.0. Sorry about the confusion. I should have pointed this out in the blog entry. Thanks, Justin -Original Message- From: mark.modrall [mailto:[EMAIL PROTECTED] Sent: Thursday, January 31, 2008 6:30 AM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] pre-defined variables? Thanks, Justin. I just commented on the blog, but I'll say the same here: If I follow the add-reference instructions above, I get a dialog saying Sorry, project references are not yet supported in Votive. If you want to add the code, by all means! :) Votive 2.0.5325 If I right-click the project itself and choose Project Dependencies, all of the right dependencies are already listed; unfortunately, that doesn't seem to connect to these variable definitions. I presume this is a 3.0-only thing? Thanks Mark -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 6:03 PM To: mark.modrall; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] pre-defined variables? I also just blogged about this, so you can check out http://blogs.msdn.com/jrock/archive/2008/01/29/complete-list-of-candle-p repr ocessor-variables.aspx. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mark.modrall Sent: Wednesday, January 30, 2008 12:53 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] pre-defined variables? Okay, are the preprocessor variables listed in http://msdn2.microsoft.com/en-us/library/aa302186.aspx only applicable to source projects? We have some Wix projects that bundle a bunch of msms into an msi. The main project has project dependencies on all of the othe Wix projects but when I put in something like Merge Id=Module1 Language=1033 src=$(var.Module1.TargetPath) DiskId=1 / (where Module1 is the name of a dependency Wix project) I get an error that $(var.Module1.TargetPath) is undefined. We're using Votive 2.0.5325 Thanks Mark - 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 - 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] pre-defined variables?
I also just blogged about this, so you can check out http://blogs.msdn.com/jrock/archive/2008/01/29/complete-list-of-candle-prepr ocessor-variables.aspx. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mark.modrall Sent: Wednesday, January 30, 2008 12:53 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] pre-defined variables? Okay, are the preprocessor variables listed in http://msdn2.microsoft.com/en-us/library/aa302186.aspx only applicable to source projects? We have some Wix projects that bundle a bunch of msms into an msi. The main project has project dependencies on all of the othe Wix projects but when I put in something like Merge Id=Module1 Language=1033 src=$(var.Module1.TargetPath) DiskId=1 / (where Module1 is the name of a dependency Wix project) I get an error that $(var.Module1.TargetPath) is undefined. We're using Votive 2.0.5325 Thanks Mark - 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 - 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] Votive 3.0.3530.0-can't add a relative reference to a wixlib
Relative references should work if you hand-edit the .wixproj file (let me know if they don't). We fixed a bug recently where the UI portion of it would write out the absolute path, but I don't know if it's in the latest build or not. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Tuesday, January 29, 2008 7:13 AM To: WiX Users Subject: [WiX-users] Votive 3.0.3530.0-can't add a relative reference to a wixlib I have a bunch of installer projects that depend on a custom wixlib for common UI elements. Everything was working fine until I changed the project structure on my hard drive, and I noticed that I had to add new references with new absolute paths to the library file. This is a problem if I want to have other developers on my team build setup projects. Everything is under source control, so a certain amount of the path can/will be hard coded, but the reference is added with a full path name. In short, I'd like to be able to set a reference path to ..\..\..\lib\MyUI.wixlib instead of d:\projects\6.1\lib\MyUI.wixlib. I also tried adding the library project to the same solution as a dependency of my setup and adding a project reference, but then the setup project didn't pick up the library. Anyone have any idea how to get around this? One thought I had was to have a pre-build step on the setup that copied the library to a local dir, but this would mean that I'd have to reference the library without a path (which appears to be impossible). I'll see what else I can come up with in the meantime, and post if I find a solution. Thanks! Chris - 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] pre-defined variables?
There's a complete list in wix.chm. Here's the list again if you need it: Project References Introduction The WiX Visual Studio package supports adding project references to a WiX project. This ensures that build order dependencies are defined correctly within the solution. In addition, it generates a set of WiX preprocessor definitions which are set on the Candle command line and can be referenced in source files. Adding Project References To add a project reference to a WiX project: 1. Right-click on the References node of the project in the Solution Explorer and choose Add Reference... 2. In the Add WiX Library Reference dialog, click on the Projects tab. 3. Select the desired project(s) and click the Add button, then click OK to dismiss the dialog. List of Supported Project References The WiX Visual Studio package supports the following project reference variables: Variable name Example usage Example value var.ProjectName.Configuration $(var.MyProject.Configuration) Debug or Release var.ProjectName.FullConfiguration $(var.MyProject.FullConfiguration) Debug | AnyCPU var.ProjectName.Platform $(var.MyProject.Platform) AnyCPU, Win32, x64 or ia64 var.ProjectName.ProjectDir $(var.MyProject.ProjectDir) C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\ var.ProjectName.ProjectExt $(var.MyProject.ProjectExt) .csproj var.ProjectName.ProjectFileName $(var.MyProject.ProjectFileName) MyProject.csproj var.ProjectName.ProjectName $(var.MyProject.ProjectName) MyProject var.ProjectName.ProjectPath $(var.MyProject.ProjectPath) C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\MyApp.csproj var.ProjectName.TargetDir $(var.MyProject.TargetDir) C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\obj\Debug\ var.ProjectName.TargetExt $(var.MyProject.TargetExt) .exe var.ProjectName.TargetFileName $(var.MyProject.TargetFileName) MyProject.exe var.ProjectName.TargetName $(var.MyProject.TargetName) MyProject var.ProjectName.TargetPath $(var.MyProject.TargetPath) C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\obj\Debug\MyProject.exe var.SolutionDir $(var.SolutionDir) C:\users\myusername\Documents\Visual Studio 2005\Projects\MySolution\ var.SolutionExt $(var.SolutionExt) .sln var.SolutionFileName $(var.SolutionFileName) MySolution.sln var.SolutionName $(var.SolutionName) MySolution var.SolutionPath $(var.SolutionPath) C:\users\myusername\Documents\Visual Studio 2005\Projects\MySolution\MySolution.sln Example The following File element demonstrates how to use project references in WiX authoring: File Id=MyExecutable Name=$(var.MyProject.TargetFileName) Source=$(var.MyProject.TargetPath) DiskId=1 / -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanikella, Rajanikanth (SCR US) Sent: Tuesday, January 29, 2008 2: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
Re: [WiX-users] Votive v3 Build Output Progress
There are several bugs logged on this already. It broke a few builds ago and the fix isn't in the build yet. It should work again soon. Sorry about the hassle. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan O'Neill Sent: Sunday, January 20, 2008 6:15 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 Build Output Progress Does it not capture the output if you set the build verbosity (did I make that word up) in VS higher? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: 20 January 2008 13:40 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Votive v3 Build Output Progress Is there any plans to properly link candle/light output to the build progress in visual studio? I was trying to eval votive the other day and it was very annoying to only get an exit code published. I couldn't find any documentation on what the exit codes meant and there was no way of correlating where in my source the problem originated. I had to drop down to dos to run the compilers manually to get any type of feedback on what I was doing wrong. _ Never miss a thing. Make Yahoo http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs your homepage. - 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] Votive v3 Build Output Progress
The MPF (managed package framework, part of the Visual Studio SDK) that we build on has a bug where they don't spin off a different thread for the build. This means that it effectively hangs the UI, which is probably what you were seeing. Hopefully the MPF will fix this in future builds. In the meantime, we also have a bug logged against Votive to fix this, so we may get to a fix before it's fixed in the MPF. From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Monday, January 21, 2008 11:24 AM To: Justin Rockwood; 'Ryan O'Neill'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 Build Output Progress When it was working, how was the performance? The last time I worked with this, I was working on large wxs files ( 5000+ components ) that were autogenerated yet incorrect. The compiler was generating a lot of errors and the build output view was having a struggle keeping up. Justin Rockwood [EMAIL PROTECTED] wrote: There are several bugs logged on this already. It broke a few builds ago and the fix isn't in the build yet. It should work again soon. Sorry about the hassle. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan O'Neill Sent: Sunday, January 20, 2008 6:15 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 Build Output Progress Does it not capture the output if you set the build verbosity (did I make that word up) in VS higher? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: 20 January 2008 13:40 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Votive v3 Build Output Progress Is there any plans to properly link candle/light output to the build progress in visual studio? I was trying to eval votive the other day and it was very annoying to only get an exit code published. I couldn't find any documentation on what the exit codes meant and there was no way of correlating where in my source the problem originated. I had to drop down to dos to run the compilers manually to get any type of feedback on what I was doing wrong. _ Never miss a thing. Make Yahoo http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs your homepage. - 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 _ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8H DtDypao8Wcj9tAcJ%20 it now. - 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] VS Orcas SKU Detection
If you're using Wix v3, we have all of these detections wrapped up in an extension so you don't have to duplicate the effort. They're contained in the WixVsExtension.dll. If you need a reminder on how to use an extension, check out http://blogs.msdn.com/jrock/archive/2007/10/19/how-to-use-extensions-in-voti ve-iis-or-ui-extensions-for-example.aspx. You can check out the topic in wix.chm on the WixVSExtension, but it looks like what you want is the VS90_IDE_VSTS_TESTSYSTEM_INSTALLED property. You can use it by having a PropertyRef Id=VS90_IDE_VSTS_TESTSYSTEM_INSTALLED in your authoring. Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Alonso Sent: Tuesday, January 15, 2008 12:18 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] VS Orcas SKU Detection Hi, I need to detect if the Visual Studio codename Orcas VSTS SKU is installed. I found that I could use this registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VS\Servicing\9.0\VSTS Is this the best practice for detecting the VSTS Orcas SKU? Will it work for any VSTS specific SKU (Database, Tester, Dev, etc)? Thanks, -Adrian - 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] Having trouble with Wix V2 (title change)
Votive 2.0 hasn't been touched in over a year, so I'm not sure what the
issues might be. Also, Votive 2.0 was designed primarily to work with Visual
Studio 2003, although I think it also was supposed to work in VS 2005. Maybe
with SP1 there were some changes. Actually, I know that's the case now that
I think about it. SP1 moved a bunch of registry keys from HKLM to HKCU, so I
bet Votive doesn't work on SP1. I'd like to say that we'll fix that, but we
probably won't. J Sorry about that. I recommend one of the following: 1)
move to Votive v3, which is more stable and more feature-rich, 2) use Visual
Studio 2003 for Votive v2 development, or 3) uninstall SP1 for VS 2005. I
know that these options may not be the best for you, for which I apologize,
but Votive v2 is really not supported anymore.
Thanks,
Justin
From: Brad Thompson (WEBSTORE) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 19, 2007 7:19 PM
To: Justin Rockwood; wix-users@lists.sourceforge.net
Subject: RE: Having trouble with Wix V2 (title change)
Installing 1.1 SDK and .Net 3.5 fixed the build issue. Thank you.
However Votive still does not work. I am using Votive-2.0.5325.0.
Loading any wixproj project into VS it leaves the solution pane completely
empty. It doesn't even list the name of the solution.
When I load the WXS file directly, I get a dialog that says Attempted to
read or write protected memory. This is often an indication that other
memory is corrupt
Brad Thompson.
From: Justin Rockwood [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 19, 2007 11:54 AM
To: Brad Thompson (WEBSTORE); wix-users@lists.sourceforge.net
Subject: RE: Having trouble with Wix V3
Which version of Votive are you trying to use for your first problem? It was
unclear whether you're using v2 or v3.
As far as the build failures go, Wix 2.0 requires the .NET Framework 1.1 SDK
(which is different than the runtime). You're right in that the runtime is
installed with the OS, but you actually need to install the SDK as well
(available at
http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-
9F41-A333C6B9181D
http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070
-9F41-A333C6B9181Ddisplaylang=en displaylang=en). For the 3.0 error, it
looks like we might be requiring .NET 3.5, but that should be fixed. In the
meantime, installing .NET 3.5 may help you get past that error.
Justin
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brad Thompson
(WEBSTORE)
Sent: Tuesday, December 18, 2007 10:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Having trouble with Wix V3
I am having a couple of problems with Wix V2. They may be related. I've
included my system configuration at the bottom.
First thing, I cannot get Votive to create a valid Wix project file.
Installation of Votive was successful (Version 5325). After installation,
when I open Visual Studio I can see the new Wizard for creating Wix
Projects. When I use the wizard to create a Wix project it has a problem.
The status bar says Creating project WixProject1.wixproj.project creation
was successful, but there is nothing at all in the Solution Explorer. If I
look at the WixProject1.wixproj file, it looks OK (see attached), but VS
doesn't do anything with it. Closing and reloading the project just gets
ready in the status bar.
Secondly, I cannot compile the Delivery project.
dtools debug succeeded.
wix debug failed.
wix20debug failed.
WIX 2.0 fails to compile with: Building WiX requires .NET Framework 1.1
SDK. However, I know it is installed. It's part of the OS.
Wix 3.0 fails with:
Using NANT from the C:\Delivery\Dev\wix directory:
[exec] Build FAILED.
[exec]
C:\Delivery\Dev\wix\src\votive\SDK_VS2008\Tools\Build\Microsoft.VsSDK.target
s(448,5): error MSB4062: The CalculateZipItems task could not be loaded
from the assembly
C:\Delivery\Dev\wix\src\votive\SDK_VS2008\Tools\Build\Microsoft.VsSDK.Build.
Tasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v3.5,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of
its dependencies. The system cannot find the file specified. Confirm that
the UsingTask declaration is correct, and that the assembly and all its
dependencies are available.
[exec] 0 Warning(s)
[exec] 1 Error(s)
My configuration:
Windows 2003 Server
Visual Studio 2005 Team Suite with all SPs
Installed packages:
{437AB8E0-FB69-4222-B280-A64F3DE22591} Microsoft Visual Studio 2005
Professional Edition - ENU
{15095BF3-A3D7-4DDF-B193-3A496881E003} Microsoft .NET Framework 3.0
{C25EF637-BE7A-4761-9B45-9069989C319F} Microsoft Visual Studio 2005 Premier
Partner Edition - ENU
{B43357AA-3A6D-4D94-B56E-43C44D09E548} Microsoft .NET Framework (English)
{7131646D-CD3C-40F4-97B9-CD9E4E6262EF} Microsoft .NET Framework 2.0
{1862162E-3BBC-448F-AA63-49F33152D54A} Microsoft Visual
Re: [WiX-users] Having trouble with Wix V3
Which version of Votive are you trying to use for your first problem? It was
unclear whether you're using v2 or v3.
As far as the build failures go, Wix 2.0 requires the .NET Framework 1.1 SDK
(which is different than the runtime). You're right in that the runtime is
installed with the OS, but you actually need to install the SDK as well
(available at
http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-
9F41-A333C6B9181D
http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070
-9F41-A333C6B9181Ddisplaylang=en displaylang=en). For the 3.0 error, it
looks like we might be requiring .NET 3.5, but that should be fixed. In the
meantime, installing .NET 3.5 may help you get past that error.
Justin
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brad Thompson
(WEBSTORE)
Sent: Tuesday, December 18, 2007 10:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Having trouble with Wix V3
I am having a couple of problems with Wix V2. They may be related. I've
included my system configuration at the bottom.
First thing, I cannot get Votive to create a valid Wix project file.
Installation of Votive was successful (Version 5325). After installation,
when I open Visual Studio I can see the new Wizard for creating Wix
Projects. When I use the wizard to create a Wix project it has a problem.
The status bar says Creating project WixProject1.wixproj.project creation
was successful, but there is nothing at all in the Solution Explorer. If I
look at the WixProject1.wixproj file, it looks OK (see attached), but VS
doesn't do anything with it. Closing and reloading the project just gets
ready in the status bar.
Secondly, I cannot compile the Delivery project.
dtools debug succeeded.
wix debug failed.
wix20debug failed.
WIX 2.0 fails to compile with: Building WiX requires .NET Framework 1.1
SDK. However, I know it is installed. It's part of the OS.
Wix 3.0 fails with:
Using NANT from the C:\Delivery\Dev\wix directory:
[exec] Build FAILED.
[exec]
C:\Delivery\Dev\wix\src\votive\SDK_VS2008\Tools\Build\Microsoft.VsSDK.target
s(448,5): error MSB4062: The CalculateZipItems task could not be loaded
from the assembly
C:\Delivery\Dev\wix\src\votive\SDK_VS2008\Tools\Build\Microsoft.VsSDK.Build.
Tasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v3.5,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of
its dependencies. The system cannot find the file specified. Confirm that
the UsingTask declaration is correct, and that the assembly and all its
dependencies are available.
[exec] 0 Warning(s)
[exec] 1 Error(s)
My configuration:
Windows 2003 Server
Visual Studio 2005 Team Suite with all SPs
Installed packages:
{437AB8E0-FB69-4222-B280-A64F3DE22591} Microsoft Visual Studio 2005
Professional Edition - ENU
{15095BF3-A3D7-4DDF-B193-3A496881E003} Microsoft .NET Framework 3.0
{C25EF637-BE7A-4761-9B45-9069989C319F} Microsoft Visual Studio 2005 Premier
Partner Edition - ENU
{B43357AA-3A6D-4D94-B56E-43C44D09E548} Microsoft .NET Framework (English)
{7131646D-CD3C-40F4-97B9-CD9E4E6262EF} Microsoft .NET Framework 2.0
{1862162E-3BBC-448F-AA63-49F33152D54A} Microsoft Visual Studio 2005 Team
Suite - ENU
{E027FE2E-3FF5-4DC9-A838-3F21CCF74EFE} Microsoft Visual Studio 2005 Team
Explorer - ENU
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Community Poll: changing the file extension for WiX extensions
Thanks for your feedback and for the bug. We actually already have a fix for that underway, so it should be in the builds fairly soon. Justin -Original Message- From: si [mailto:[EMAIL PROTECTED] Sent: Monday, December 17, 2007 10:09 PM To: Justin Rockwood Cc: WiX Users; Candy Chiang Subject: Re: [WiX-users] Community Poll: changing the file extension for WiX extensions Hi Justin, We'd like to change the file extension for WiX extensions from .dll to .wixext, but wanted to get a feel from the community how this would affect people. Please respond if this would affect you negatively (or positively) and how. Note that this is just for wix v3. Version 2 is not affected. +1 No problem for us. A (somewhat) related issue: We version control our extensions and place them relative to the source; this stops things from falling over when WiX is installed in different locations, and gives people a clue as to when to update to the next weekly release. However, there is to my knowledge no easy way to change an extensions path from being absolute to relative, or to add a relative path to begin with, except by diving into the wixproj file. I've no problems doing this (except the time cost of unloading project - modify absolute to relative path - reload project - test compile - repeat until successful:), but we want to encourage our developers to think about setup/install as part of the continuous development process, rather than just at the end of it...and this issue hinders that. So, it would be great if the Votive UI for adding an extension reference respected relative paths, just like the rest of Visual Studio does. Opps, sorry, I just realised I should probably log this as an issue rather than via email (will do it now [1]). [1] http://sourceforge.net/tracker/index.php?func=detailaid=1852868group_id=10 5970atid=642714 -- It's a wild world that we live in, you step to the vibe like a new found religion, take your position, compile your vision, futurism, algorithm has risen up!pfm - the western - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive on VS 2008?
Sorry for the delayed response. Yes, the project reference variables were added back to Votive 3, so they should work just fine for you now. Justin -Original Message- From: Chris Bardon [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 6:54 AM To: Justin Rockwood; WiX Users Subject: RE: [WiX-users] Votive on VS 2008? OK, I just installed the latest release, and everything seems to be working fine-thanks Justin! I saw a reference to it in the history, but were the variable defines added back to Votive (something like var.Project.TargetDir)? I know these worked in 2, but not in 3. Chris -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Friday, December 07, 2007 3:45 PM To: Chris Bardon; WiX Users Subject: RE: [WiX-users] Votive on VS 2008? Yes, it works side by side just fine (or at least it's supposed to :-). You should see an option on whether you want to install it to VS 2005, VS 2008, or both. The installation detects what versions of Visual Studio you have installed and presents the options appropriately (so if you only have 2008 installed you won't see the option for 2005). Thanks, Justin -Original Message- From: Chris Bardon [mailto:[EMAIL PROTECTED] Sent: Friday, December 07, 2007 12:40 PM To: Justin Rockwood; WiX Users Subject: RE: [WiX-users] Votive on VS 2008? No, I'd grabbed the latest from http://sourceforge.net/project/showfiles.php?group_id=105970package_id= 16, which is a whole lot more out of date. I've give the new build a try. Did you happen to try it on a side by side with 2005 and 2008? If not, I'll let you know how it works. -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Friday, December 07, 2007 3:02 PM To: Chris Bardon; WiX Users Subject: RE: [WiX-users] Votive on VS 2008? Have you picked up the most recent version on http://wix.sourceforge.net/releases (Votive 3, not 2)? Aaron has already done the work to get Votive to work with VS 2008 Beta 2 and I hear that it works on RTM as well. We're actually finishing up a change that will use the RTM bits as well, but I think you should be fine with what we already have. Thanks, Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Friday, December 07, 2007 7:51 AM To: WiX Users Subject: Re: [WiX-users] Votive on VS 2008? I did try reinstalling with the latest 3.0 setup from sourceforge, and 2008 still doesn't recognize the wixproj projects. I took a look at the votive setup though, and it looks like it's just a matter of a few registry settings that'll have to be duplicated. I'd rather not remove VS 2005 at the moment, but I might give it a shot in virtual PC if I can't get the registry change fix to work. All of the wix binaries are there, I just need to make sure that VS2008 can recognize the project types, XML schemas, etc. -Original Message- From: Richard [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sent: Thursday, December 06, 2007 7:24 PM To: Chris Bardon Subject: Re: [WiX-users] Votive on VS 2008? In article [EMAIL PROTECTED] , Chris Bardon [EMAIL PROTECTED] writes: I'm using 3.0. [...] On Rob Mensching's blog, he stated that the community technology preview for the next release of VS.NET is incorporating WiX 3.0, so I'd expect that WiX 3.0 would work well with VS.NET 2008. However, I try not to install two editions of VS.NET on one box at the same time. If you have a spare machine try installing VS.NET 2008 on that machine along with WiX 3.0/Votive and see if that works. If it does then you know its an issue with installing things side-by-side and not a basic compatability problem. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive on VS 2008?
Have you picked up the most recent version on http://wix.sourceforge.net/releases (Votive 3, not 2)? Aaron has already done the work to get Votive to work with VS 2008 Beta 2 and I hear that it works on RTM as well. We're actually finishing up a change that will use the RTM bits as well, but I think you should be fine with what we already have. Thanks, Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Friday, December 07, 2007 7:51 AM To: WiX Users Subject: Re: [WiX-users] Votive on VS 2008? I did try reinstalling with the latest 3.0 setup from sourceforge, and 2008 still doesn't recognize the wixproj projects. I took a look at the votive setup though, and it looks like it's just a matter of a few registry settings that'll have to be duplicated. I'd rather not remove VS 2005 at the moment, but I might give it a shot in virtual PC if I can't get the registry change fix to work. All of the wix binaries are there, I just need to make sure that VS2008 can recognize the project types, XML schemas, etc. -Original Message- From: Richard [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sent: Thursday, December 06, 2007 7:24 PM To: Chris Bardon Subject: Re: [WiX-users] Votive on VS 2008? In article [EMAIL PROTECTED] , Chris Bardon [EMAIL PROTECTED] writes: I'm using 3.0. [...] On Rob Mensching's blog, he stated that the community technology preview for the next release of VS.NET is incorporating WiX 3.0, so I'd expect that WiX 3.0 would work well with VS.NET 2008. However, I try not to install two editions of VS.NET on one box at the same time. If you have a spare machine try installing VS.NET 2008 on that machine along with WiX 3.0/Votive and see if that works. If it does then you know its an issue with installing things side-by-side and not a basic compatability problem. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive on VS 2008?
Yes, it works side by side just fine (or at least it's supposed to :-). You should see an option on whether you want to install it to VS 2005, VS 2008, or both. The installation detects what versions of Visual Studio you have installed and presents the options appropriately (so if you only have 2008 installed you won't see the option for 2005). Thanks, Justin -Original Message- From: Chris Bardon [mailto:[EMAIL PROTECTED] Sent: Friday, December 07, 2007 12:40 PM To: Justin Rockwood; WiX Users Subject: RE: [WiX-users] Votive on VS 2008? No, I'd grabbed the latest from http://sourceforge.net/project/showfiles.php?group_id=105970package_id= 16, which is a whole lot more out of date. I've give the new build a try. Did you happen to try it on a side by side with 2005 and 2008? If not, I'll let you know how it works. -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Friday, December 07, 2007 3:02 PM To: Chris Bardon; WiX Users Subject: RE: [WiX-users] Votive on VS 2008? Have you picked up the most recent version on http://wix.sourceforge.net/releases (Votive 3, not 2)? Aaron has already done the work to get Votive to work with VS 2008 Beta 2 and I hear that it works on RTM as well. We're actually finishing up a change that will use the RTM bits as well, but I think you should be fine with what we already have. Thanks, Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Friday, December 07, 2007 7:51 AM To: WiX Users Subject: Re: [WiX-users] Votive on VS 2008? I did try reinstalling with the latest 3.0 setup from sourceforge, and 2008 still doesn't recognize the wixproj projects. I took a look at the votive setup though, and it looks like it's just a matter of a few registry settings that'll have to be duplicated. I'd rather not remove VS 2005 at the moment, but I might give it a shot in virtual PC if I can't get the registry change fix to work. All of the wix binaries are there, I just need to make sure that VS2008 can recognize the project types, XML schemas, etc. -Original Message- From: Richard [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sent: Thursday, December 06, 2007 7:24 PM To: Chris Bardon Subject: Re: [WiX-users] Votive on VS 2008? In article [EMAIL PROTECTED] , Chris Bardon [EMAIL PROTECTED] writes: I'm using 3.0. [...] On Rob Mensching's blog, he stated that the community technology preview for the next release of VS.NET is incorporating WiX 3.0, so I'd expect that WiX 3.0 would work well with VS.NET 2008. However, I try not to install two editions of VS.NET on one box at the same time. If you have a spare machine try installing VS.NET 2008 on that machine along with WiX 3.0/Votive and see if that works. If it does then you know its an issue with installing things side-by-side and not a basic compatability problem. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Output Window bugs with latest versions of Wix?
This is a known bug and we're working on a fix. It's actually a bug in Visual Studio 2005 and not in our stuff, but we're working to get a fix for it. It works fine in Visual Studio 2008. Also, the task pane should show the errors in the correct format in both versions as a workaround. Thanks, Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Wednesday, December 05, 2007 5:15 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Output Window bugs with latest versions of Wix? Has the output format changed. The latest versions of Wix I have (3.0.3530.0, and 3.0.3526.0, 3.0.3509.0, and 3.0,3502.0) aren't setting the output for error messages correctly in my copy of Visual Studio 2005. I'm getting line numbers for the error message, but no actual error message. It's also not throwing in line-feeds correctly. When I run it from the command line, everything looks normal. I get this on the command line: C:\projects\rowing\StrokeOfGenius\RowingTelemetryWiX\ftdi-drivers.wxs(45) : error LGHT0094 : Unresolved reference to symbol 'Compone nt:drivers' in section 'Fragment:'. C:\projects\rowing\StrokeOfGenius\RowingTelemetryWiX\ftdi-drivers.wxs(46) : error LGHT0094 : Unresolved reference to symbol 'Compone nt:drivers_i386' in section 'Fragment:'. C:\projects\rowing\StrokeOfGenius\RowingTelemetryWiX\ftdi-drivers.wxs(47) : error LGHT0094 : Unresolved reference to symbol 'Compone nt:drivers_amd64' in section 'Fragment:'. And this in visual studio 2005. C:\projects\rowing\StrokeOfGenius\RowingTelemetryWiX\ftdi-drivers.wxs(45,0)E rror LGHT0094: C:\projects\rowing\StrokeOfGenius\RowingTelemetryWiX\ftdi-drivers.wxs(46,0)E rror LGHT0094: C:\projects\rowing\StrokeOfGenius\RowingTelemetryWiX\ftdi-drivers.wxs(47,0)E rror LGHT0094: Done building project RowingTelemetryWiX.wixproj -- FAILED. I get similar errors with candle. Anyone else seeing this? Anthony Wieser Wieser Software Ltd - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Some STUPID Limitations in WiX
Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX toolset, it's typically not a good idea to call it STUPID and then in the same sentence ask for help. You're biting the hand that feeds you. Plus if you think it's stupid then why would you trust the advice from the people that created it? At any rate, good luck with your powerful installer. Since we don't really know how to build those (smile), you may want to take any advice we give with a grain of salt. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dong Fang Xie (Excell Data Corporation) Sent: Tuesday, September 25, 2007 12:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Some STUPID Limitations in WiX I'm working on a small and simple installer using WiX toolset (the latest stable version 2.0.3719.0). To my surprise, it is really very very tough !! It almost drove me crazy. I really don't understand why there are so many stupid limitations: LIMIT 1: Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why there is no ProcessSearch or TaskSearch ?!I need to know whether a specific process is running before installation/uninstallation. LIMIT 2: If all files in a msi package are from different small projects, I can build a module for each small project, and create a main wxs file to merge all modules. It should be a good idea, but how can I use the files from different modules ? There is no way for now. I must control all custom actions in the main wxs file, and some custom actions need a FileKey to a file in a module. I cannot distribute all cutom actions in different modules, if I do so, how can I control the InstallSequence ? Using stupid numbers? LIMIT 3: I defined a dialog which must be shown not only during installation but also during uninstallation. But how to make it shown during uninstallation ? the UILevel will be set to basic UI or no UI automatically by msiexec.exe. How can I beg Windows NOT do that for me? I can use command msiexec /qf /x msifile, but how can I know my customer can do that each time they want to uninstall the msi file ? Is there any way I can define UILevel of uninstallation inside msi file ? WiX is a very good toolset, but far from perfect ! I bet the developers of WiX toolset have never built a powerful installer for customers. I will never know the limit if I wasn't assigned the job to build a small and simple installer. I noticed that there are some extensions in WiX 3.0, but it is still far from enough. For LIMIT 1, I've built my own dll to detect running processes. But how to break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ? Thanks in advance - 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 - 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] Some STUPID Limitations in WiX
True. Although, there's a grain of truth in Dong's frustrations, which is why I was just joking around in my initial response (I really did think Dong's email was funny and didn't take offense). I do think that Windows Installer could be a lot easier to understand and work with and I think that we still have a good ways to go to make it easier in WiX for novice users (not necessarily calling Dong a novice). Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Shurts Sent: Tuesday, September 25, 2007 2:44 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Some STUPID Limitations in WiX I have seen this time and time again. When someone doesn't understand the subtle nuances of the Windows Installer service, all of a sudden all the tools built around it suck or are STUPID. :-) On 9/25/07, Justin Rockwood [EMAIL PROTECTED] wrote: Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX toolset, it's typically not a good idea to call it STUPID and then in the same sentence ask for help. You're biting the hand that feeds you. Plus if you think it's stupid then why would you trust the advice from the people that created it? At any rate, good luck with your powerful installer. Since we don't really know how to build those (smile), you may want to take any advice we give with a grain of salt. Justin -Original Message- From: [EMAIL PROTECTED] [mailto: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Dong Fang Xie (Excell Data Corporation) Sent: Tuesday, September 25, 2007 12:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Some STUPID Limitations in WiX I'm working on a small and simple installer using WiX toolset (the latest stable version 2.0.3719.0). To my surprise, it is really very very tough !! It almost drove me crazy. I really don't understand why there are so many stupid limitations: LIMIT 1: Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why there is no ProcessSearch or TaskSearch ?!I need to know whether a specific process is running before installation/uninstallation. LIMIT 2: If all files in a msi package are from different small projects, I can build a module for each small project, and create a main wxs file to merge all modules. It should be a good idea, but how can I use the files from different modules ? There is no way for now. I must control all custom actions in the main wxs file, and some custom actions need a FileKey to a file in a module. I cannot distribute all cutom actions in different modules, if I do so, how can I control the InstallSequence ? Using stupid numbers? LIMIT 3: I defined a dialog which must be shown not only during installation but also during uninstallation. But how to make it shown during uninstallation ? the UILevel will be set to basic UI or no UI automatically by msiexec.exe. How can I beg Windows NOT do that for me? I can use command msiexec /qf /x msifile, but how can I know my customer can do that each time they want to uninstall the msi file ? Is there any way I can define UILevel of uninstallation inside msi file ? WiX is a very good toolset, but far from perfect ! I bet the developers of WiX toolset have never built a powerful installer for customers. I will never know the limit if I wasn't assigned the job to build a small and simple installer. I noticed that there are some extensions in WiX 3.0, but it is still far from enough. For LIMIT 1, I've built my own dll to detect running processes. But how to break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ? Thanks in advance - 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 - 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 - 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] Some STUPID Limitations in WiX
Yep, I agree (see my last email - we crossed responses). I wasn't intending to come down on Dong. I was writing tongue-in-cheek, but I'm not sure if that came across. I still get frustrated with Windows Installer/WiX, so I know the feeling. Thanks, Justin From: Chris Mumford [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 25, 2007 2:50 PM To: Justin Rockwood Cc: Dong Fang Xie (Excell Data Corporation); wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Some STUPID Limitations in WiX Hi Justin: Even though your advice and comments to Dong are 100% correct I'm still going easy on him. I've had many frustrating days with Windows Installer/WiX. I would say that these are most surely issues with Windows Installer's complexity and not WiX - however WiX's tendency to assume that you are already a Windows Installer expert, and it's missing support for UI (until recently) never helped matters. On 9/25/07, Justin Rockwood [EMAIL PROTECTED] wrote: Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX toolset, it's typically not a good idea to call it STUPID and then in the same sentence ask for help. You're biting the hand that feeds you. Plus if you think it's stupid then why would you trust the advice from the people that created it? At any rate, good luck with your powerful installer. Since we don't really know how to build those (smile), you may want to take any advice we give with a grain of salt. Justin -Original Message- From: [EMAIL PROTECTED] [mailto: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Dong Fang Xie (Excell Data Corporation) Sent: Tuesday, September 25, 2007 12:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Some STUPID Limitations in WiX I'm working on a small and simple installer using WiX toolset (the latest stable version 2.0.3719.0). To my surprise, it is really very very tough !! It almost drove me crazy. I really don't understand why there are so many stupid limitations: LIMIT 1: Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why there is no ProcessSearch or TaskSearch ?!I need to know whether a specific process is running before installation/uninstallation. LIMIT 2: If all files in a msi package are from different small projects, I can build a module for each small project, and create a main wxs file to merge all modules. It should be a good idea, but how can I use the files from different modules ? There is no way for now. I must control all custom actions in the main wxs file, and some custom actions need a FileKey to a file in a module. I cannot distribute all cutom actions in different modules, if I do so, how can I control the InstallSequence ? Using stupid numbers? LIMIT 3: I defined a dialog which must be shown not only during installation but also during uninstallation. But how to make it shown during uninstallation ? the UILevel will be set to basic UI or no UI automatically by msiexec.exe. How can I beg Windows NOT do that for me? I can use command msiexec /qf /x msifile, but how can I know my customer can do that each time they want to uninstall the msi file ? Is there any way I can define UILevel of uninstallation inside msi file ? WiX is a very good toolset, but far from perfect ! I bet the developers of WiX toolset have never built a powerful installer for customers. I will never know the limit if I wasn't assigned the job to build a small and simple installer. I noticed that there are some extensions in WiX 3.0, but it is still far from enough. For LIMIT 1, I've built my own dll to detect running processes. But how to break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ? Thanks in advance - 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 - 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 - 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/VS+Votive - adding all files in a directory to a project?
You're right that what you want is dangerous because it goes against component rules. However, I can also see the value in having something like this inherent in Votive. If you want to log a feature request, I think it would be something good to add to Votive. I'd probably have some sort of scary dialog popping up the first time warning you that you're treading on dangerous ground, but the feature could be useful. Here's the link to add a feature request: http://sourceforge.net/tracker/?group_id=105970 http://sourceforge.net/tracker/?group_id=105970atid=642717 atid=642717 Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sergei Shelukhin Sent: Friday, September 14, 2007 12:15 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix/VS+Votive - adding all files in a directory to a project? Hi. I wonder if there's something similar to Project output concept for Wix setup projects created using Votive. We are currently using Web setup project followed by Custom Action that is used to do most of the work to deploy a big ASP.NET application. We are considering moving the deployment to either WiX or a completely custom tool because of the utter lack of functionality in Web Setup projects. The problem is that the project has hundreds of files in a complicated subdirectory tree in several separate projects and files are constantly added, removed and moved around from version to version. Web setup has the advantage of packaging all the required files easily, I wonder if this is available for WiX. Application is basically a monolithic entity and the update includes the removal of most files (apart from maybe 3-5 files and 1-2 subdirectories) and redeployment of the new ones so we don't care about component versioning problems. - 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] MSB4035 - WiX 3.0 TFS Beta 2
This bug has been fixed, but hasn't been checked in yet. In the meantime,
you can make the change yourself if you want (the change is in bold):
Import Project=$(CustomBeforeWixTargets) Condition=
'$(CustomBeforeWixTargets)' != '' and Exists('$(CustomBeforeWixTargets)')
/
Import Project=$(CustomAfterWixTargets) Condition=
'$(CustomAfterWixTargets)' != '' and Exists('$(CustomAfterWixTargets)') /
Justin
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Dierkes
Sent: Wednesday, September 12, 2007 1:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] MSB4035 - WiX 3.0 TFS Beta 2
I get the following error with the Wix.Targets file when trying a team build
with Team Foundation Server 2008 Beta 2.
[Any CPU/Debug] C:\Program
Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(55,3): error MSB4035: The
required attribute Project is missing from element Import.
Here is line 55 from Wix.Targets.
Import Project=$(CustomBeforeWixTargets)
Condition=Exists('$(CustomBeforeWixTargets)') /
I commented line 55 above in Wix.Targets and this line was tagged with the
same error.
!-- Extension point: Define CustomAfterWixTargets to a .targets file that
you want to include after this file. --
Import Project=$(CustomAfterWixTargets)
Condition=Exists('$(CustomAfterWixTargets)') /
After commenting out the second line I do not get an error. If I don't have
any custom build tasks then how can I get past this without defining these
custom targets and without modifying the Wix.Targets file?
Cheers,
Jim
-
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] Problem with german letters if UI as FragmentRef
Sounds like your wxs file is not saved in UTF-8 or some other encoding that allows German characters. Also, you have to have ?xml version=1.0 encoding=utf-u ? at the top of your XML file. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of pobox77 Sent: Monday, September 10, 2007 1:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with german letters if UI as FragmentRef Hi, I have in UI some german texts with special german characters like Ä, Ü, Ö, ß. I saved UI in a separate fragment file FragmentUI.wxs and referenced it by FragmentRef Id=FragmentUI / While compiling I always get the error: C:\...\FragmentUI.wxs(629) : error CNDL0104 : Not a valid source file; detail: Invalid character in the given encoding. Line 629, position 74. Here is for example an 'ä' in the text. My product has Language=1031, package has Languages=1031, Codepage=1252, light.exe has cultures en-us. If my UI section is in the main wxs file, it will be compiled without any error using the same settings. How should I use a separate ui-fragment including german characters? Regards, Peter -- View this message in context: http://www.nabble.com/Problem-with-german-letters-if-%3CUI%3E-as-FragmentRef-tf4413039.html#a12588647 Sent from the wix-users mailing list archive at Nabble.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 - 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] Votive and Project References -- RESEND
Unfortunately, there's a bug right now in wixlib references. You can manually add the reference (not a project reference) and have it work fine. Like you said, though, I think it stores a hardcoded path, which is a bug. Adding a .wixlib project reference, however, does not currently work as expected. This is also a bug. Sorry about the trouble. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quattro IV Sent: Thursday, August 09, 2007 7:17 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Votive and Project References -- RESEND I didn't get a response so I'm resending this: Hello, I'm having an issue referencing a WiX library from a standard WiX module. For some reason I get Unresolved reference to symbol... errors when I just reference the WiX library project directly instead of the referencing the output of the project (.wixlib file) Anyone get this to work? Also, when I reference the output file directly it creates a hardcoded path and I have to manually update the .wixproj directly to fix it, is this a bug? Any help is appreciated. Reese - 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] macro/property for detecting debug/release from Votive
You can do one of two things: 1) If you're deploying DLLs that you build within your Visual Studio solution, then you can use the project references to do it. Right mouse click on your Votive project and click Add Reference. Then add a Project Reference to the DLL that you want to deploy. In your wxs file you then write something like this: File Source=$(var.YourDllProjectName.TargetPath) / When your Votive project builds, it will automatically detect when projects have been rebuilt and include your new binaries. 2) You can code this yourself in a similar way: File Source=bin\$(var.Configuration)\DllName.dll / On the Votive property pages, you can then define a compiler variable like this: Configuration=$(Configuration) $(Configuration) is an MSBuild property that gets defined automatically. When candle.exe runs, the Configuration property will be defined correctly for you. Hope this helps, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley Sent: Wednesday, August 01, 2007 4:02 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] macro/property for detecting debug/release from Votive I am using Votive in Visual Studio 2005. Can anyone tell me how I can configure my WXS file to pick up DLLS to be deployed (with the File tag) from bin\Debug if the build configuration is set to Debug, and bin\Release if its Release? Thanks - Adam Secon NZ Ltd. A1/400 Rosedale Road Albany North Shore 0632 New Zealand Tel. +64 (0)9 414 4071 Fax. +64 (0)9 414 4072 www.seconag.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] votive project reference to wixlib
There are actually two bugs here (or NYI features, however you'd like to view it J). The first bug is that Votive (.wixproj) projects actually don't work with project references right now (meaning that you can't have a project reference to another wixproj and have it generate the preprocessor variables). The second bug is that adding a project reference to a wixlib will not automatically use that generated wixlib in the link step. Adding an actuall reference to the wixlib will work, as you pointed out. If you'd like to add bugs for both of these, it would be great. I knew about them, but haven't logged bugs against them yet, and therefore they've fallen off my radar. Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of steve baker Sent: Thursday, June 28, 2007 9:19 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] votive project reference to wixlib I have a wixlib project in my solution that houses my custom UI. When I add a project reference to that wixlib project from my msi project it doesn't resolve. I found that I can add a reference directly to the wixlib file and it works. I was just wondering if that is the expected way to add references or if a project reference is supposed to work? Thanks, steve - 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] Future of Votive?
Yes, there are plans to add designers to Votive. It's been on my list for a while, but unfortunately my spare time has been rare the past few months. I think the first designers will probably be very basic and rudimentary (I'm thinking of registry and file/directory editors), but eventually more will come. The challenging part will be to create the architecture for supporting designer extensions. So, for example, somebody writes a Wix extension to work with Media Center. They could also write an editor for that same extension and have it plug into Votive automatically once the extension is referenced from the wixproj. All sorts of cool ideas, but it'll probably be a while before they're in at the rate I'm going, unfortunately. Anyway, thanks for your suggestions. It's stuff that's already on my radar, but it's good to know that other people want it, too. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Ashman Sent: Friday, June 08, 2007 9:47 PM To: Christopher Painter Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Future of Votive? Not sure about the Votive information, but if you pass -gg to heat as an option it will generate guids for you instead of inserting the PUT-GUID-HERE message. On 6/8/07, Christopher Painter [EMAIL PROTECTED] wrote: I've been playing with Votive and I really like the way it plugs into VS and uses MSBuild. My installs are primarily InstallShield based, and they will remain that way, but I would like to break some of the xcopy type logic out into seperate merge modules and let developers maintain them. My developers looked at Votive and basically said that they have no intention of entering raw xml to maintaing the dir/file trees associated with these merge modules. Will Votive ever have a Right Click | View Designer feature? The perfect tool for me would take the VS features the Votive already has and give a vey simple drag and drop approach to directory structure creation similar to the way VDPROJ does it. The tool would need to automaically generate relative path file links and be very careful to not let developers do stupid things. We are trying to support minor upgrades so features like `deprecate file` to cause transitive style puncturing of components would be really good. I tried playing with heat but my developer don't want to have to use the command line and they want to be able to easily add and remove from the tree as needed. Eitherway I have a question about heat I notice that it sets components to Guid=PUT-GUID-HERE and uses absolute paths instead of relative paths in the Source attribute. When you import a large directory structure, whats the easiest way to update those? It seems very annonying to have to go through hundreds of these to get an WXS file that will properly work. _ Looking for a deal? Find great prices on flights and hotels http://us.rd.yahoo.com/evt=47094/*http:/farechase.yahoo.com/;_ylc=X3oDMTFic DJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20- with Yahoo! FareChase. - 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 - 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] Pass variable's value using MSBuild (and a votive problem)
It depends on what build you're using. I recently checked in a fix (a couple of weeks ago) where some property changes would not mark the project as dirty, so they wouldn't save. I think things should be working now, though. Let me know if you find that you're still having problems with changes not getting saved correctly. Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Friday, April 27, 2007 11:56 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Pass variable's value using MSBuild (and a votive problem) If you're using Votive, go to the property pages, and add SOURCEPATH=\\droplocation\sourcecode to your define variables. I had a lot of problems getting the values to stick for my project configurations, so ended up doing it manually in the wixproj file, as described below in my original reply. There seems to be some confusion between the project the property page is modifying, and the one that visual studio is claiming is current in its toolbar. Has anyone else noticed that Votive doesn't like to save changed pages, and figured out what provokes the problem. Anthony Wieser Wieser Software Ltd So if I had a dropLocation that is used as a variable in my wxs file as ?define SOURCEPATH =\\dropLocation\sourcecode? which is used in the wxs project as File Id=FileWebConfig Name=WEB~1.CON LongName=Web.config src=$(var.SOURCEPATH)\Web.config / How would I make this part of my MSBuild? I want to use the MSBuild's droplocation as input to the wixproj which here is the value for the SOURCEPATH. Can you elaborate help out here? Thanks, SJ On 4/27/07, Anthony Wieser [EMAIL PROTECTED] wrote: I'm had problems with this too. I've had the following line in my .wixproj file: WixVariablesConfig= demo.wxi/WixVariables Then in my .wxs file, I'd like to include the file specified as config. I tried this in my .wxs file, ?include $(var.Config) ? but I get this error: Error CNDL0150: Undefined preprocessor variable '$( var.Config)'. Then I looked around, and discovered, that this passes a LINKER variable. To pass a compiler variable I need to do this instead: DefineConstantsConfig=demo.wxi/DefineConstants Now it works as expected. Anthony Wieser Wieser Software Ltd - 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 - 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 variables from nant to votive wix project
It might be better to just use preprocessor variables in your WiX files and
then pass in those values when you call the MSBuild NAnt task. In your wxs
files use:
$(var.Version) and then when calling MSBuild, set
/property:DefineConstants=Version=1.0.1013.0. Then you don't have to use
NAnt to change your source files, which is usually not a good idea with
Source Code Control systems.
Justin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Paulsen
Sent: Tuesday, April 10, 2007 7:25 AM
To: Scott Sam
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] getting variables from nant to votive wix project
Scott Sam wrote:
We have nant create the version number during the build. I would like
to use this in various places in the wix projects. Is there a way to do
this without setting environment variables? I'm using votive and just
using nant's msbuild task to build the solution. I don't want to use
environment variables because there could be multiple versions building
at the same time.
Since you are using nant for the version number, you can use the xmlpoke
task to put the value right into your wxs, like this:
xmlpoke file=MyInstaller.wxs xpath=/wix:Wix/wix:Product/@Version
value=${buildnumber.version}
namespaces
namespace prefix=wix uri=http://schemas.microsoft.com/wix/2006/wi/
/namespaces
/xmlpoke
--
Jeff Paulsen
-
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
-
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
Re: [WiX-users] WiX 3 and the wixui
Using Votive you cannot target the Wix 2 stuff. You have to use Votive 2 (supported on VS 2003) in order to target Wix 2. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of learnerplates Sent: Thursday, April 05, 2007 7:54 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX 3 and the wixui I've installed WiX 3 in order to get the Visual Studio integrated version. It works fine, and I can use sourcesafe through Visual Studio. Now I've just started to use the UI part of WiX, it's failing, I think the installed WiXUI library in Visual Studio is from Version 2 and may have come with the Visual Studio SDK! Is there anyway to get WiX 3 to work with WiX 2 UI libraries? I've been trying to use the example SampleWixUI found at the WiX Tutorial http://www.tramontana.co.hu/wix/lesson2.php Here's the error: C:\dotNET\WixSampleUI\WixSampleUIlight.exe -out SampleWixUI.msi SampleWixUI.wix obj C:\Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioIntegration\Too ls\Wix\wixui.wixlib Microsoft (R) Windows Installer Xml Linker version 3.0.2420.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioIntegration\Tools\Wi x\wixui.wixlib : error LGHT0141 : The library file format version 2.0.2207.0 is not compatible with the expected library file format version 3.0.2002.0. Also, does anyone know how to add the additional switch for the WixUI to the Visual Studio project (The WixProject does not appear to have commandline parameters in the project properties!!!) _ View this message in context: WiX 3 http://www.nabble.com/WiX-3-and-the-wixui-tf3532073.html#a9857389 and the wixui Sent from the wix-users http://www.nabble.com/wix-users-f4470.html mailing list archive at Nabble.com. - 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
Re: [WiX-users] Problems with Dependencies inVotive
Ok, I was afraid of that. It appears that this isn't implemented in the VS SDK 3.0. Maybe it's been fixed in 4.0. I'll have to add this feature, since it's not working correctly right now. Sorry for the trouble you're having. Justin -Original Message- From: Anthony Wieser [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 3:07 AM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: Problems with Dependencies inVotive I've added this to my project: ItemGroup Content Include=..\setupdude\dude.cabLinkdude.cab/Link/Content /ItemGroup When I reload the project in vs2005, this is what ends up in the file. ItemGroup Content Include=..\setupdude\release\dude.cab Linkdude.cab/Link /Content /ItemGroup ItemGroup Folder Include=..\ / Folder Include=..\setupdude\ / Folder Include=..\setupdude\release\ / /ItemGroup I tried adding a folder structure manually first, but that looks like it's going to lead to trouble. When I create the first folder (..), I get a warning message that it exists already, but it does get added to the project. Then when I try to add a new folder to .., a new tree gets created. So, it looks like this isn't working correctly in the UI. I haven't checked if the msbuild file on its own works or not. Any thoughts? Anthony Wieser Wieser Software Ltd - Original Message - From: Justin Rockwood [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; Justin Rockwood [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, March 23, 2007 9:54 PM Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive In Visual Studio, when you select Add Existing File... if you just click Add, then the file will be copied to your local directory. This is by design and works the same way as C#, VB, etc. If you want to add a link, which you do, then drop down the little arrow next to the Add you'll see an Add As Link option. You want to select that. This will then populate your MSBuild (.wixproj) file for you correctly. You will not be allowed to Delete that file, but you can remove the link from your project. Does this make sense? To do this manually, you have to do this: Content Include=relative path to file LinkHow you want the file to appear in your project/Link /Content A more concrete example: Content Include=..\Release\MyExe.exe LinkMyExe.exe/Link /Content You shouldn't get messy directory structures if you do this approach. Justin -Original Message- From: Anthony Wieser [mailto:[EMAIL PROTECTED] Sent: Friday, March 23, 2007 7:38 AM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies in Votive - Original Message - From: Justin Rockwood [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Thursday, March 22, 2007 6:40 PM Subject: RE: [WiX-users] Problems with Post Build Step and Dependencies in Votive Do you mind logging a bug on the _TimeStampAfterCompile? I'll look into that. Done. As far as forcing a recompile... You can do that by including your inputs into your .wixproj project file as Content elements. In Votive, you do this by selecting Content from the Build Type property in the property browser (hit F4 if it's not showing). If you're working just with the MSBuild .wixproj file, you can just add ContentRelative path to file/Content in an ItemGroup section. When compiling, I account for the Content elements to trigger a rebuild if they change. Justin I can't get this to work with Votive. My solution is structured as follows: Proj-root | |-Main Program Project | |-Debug | |-Release [exe to depend on is here] | |-Wix Project ||-bin ||--Release [msi ends up here] In my project in VS2005, I right click on the Wix project, and choose Add Existing Item... When I navigate up the hierarchy to release, what happens is that a copy of the selected .exe file ends up in the Wix Project folder. the .wixproj file contains: ItemGroup Content Include=myprog.exe /ItemGroup Is that correct? Manually editing as suggested above to Content Include=..\release\myprog.exe makes the project expand into a messy disaster of .. folders, which presumably isn't correct either. Especially as there are 3 .. based folders! looking at the aftermath of that, this is what ends up in the wixproj file: ItemGroup Folder Include=..\ / Folder Include=..\release / /ItemGroup Being of a suspicious nature, I created another folder, and then deleted it, and found it was removed from my disk. I dread to think what will happen if I try to delete one of these from within votive, but why not? Don'tTryThisAtHome Deleting the .exe shown under folder release under folder .. does indeed delete the exe from the release... Deleting the folder
Re: [WiX-users] Can Votive use Visual Studio Macros/Env vars ..eg SolutionPath, ConfigurationName ect
Although the feature to use $(var.Project.TargetPath) isn't done yet, you can still do what you want by using MSBuild variables. In your .wixproj file, add the following to a PropertyGroup element: PropertyGroup DefineConstantsConfiguration=$(Configuration)/DefineConstants /PropertyGroup This will automatically add the -dConfiguration=Debug to the candle command line. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ste Sent: Monday, March 26, 2007 1:32 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Can Votive use Visual Studio Macros/Env vars ..eg SolutionPath, ConfigurationName ect Hi Using Wix3 and Votive. Is there an environment variable to specify the current project settings eg instead of hard coding the project path or build i would like use the Visual studio environment variables File Id=MyService.exe Name=MyService.exe DiskId='1' Vital='yes' Source='..\MyProject\bin\Debug\MyService.exe'/ For example VS has the macro ConfigurationName mapped to debug or release, but i cannot access this via the Wix $(env) var File Id=MyService.exe Name=MyService.exe DiskId='1' Vital='yes' Source='..\MyProject\bin\$(env.ConfigurationName)\MyService.exe'/ Is there away to get these VS environment (macros as VS calls them) into Votive for Wix to expand? Thanks - 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 - 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
Re: [WiX-users] Wix votive stable version
You guys are absolutely right. I'm so sorry for leading you in the wrong direction. I'm an idiot. J I forgot that I hadn't fully implemented the Link feature yet. I'm sorry about that. I think, though, that you should be able to manually tweak the .wixproj file to make it work, although I haven't actually tried it myself yet. Would somebody be willing to submit a feature request for the Add as Link feature? Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Dahlbacka Sent: Tuesday, March 27, 2007 10:44 AM To: John Vottero Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix votive stable version On 3/27/07, John Vottero [EMAIL PROTECTED] wrote: I think you're looking in the wrong place. You said There is no add as link option shown on my system when I right click the project on my my system. Add shows New Item Existing Item and Folder. Add as link doesn't show up when you right click the project. You right-click the project, pick Add - Existing item. A dialog box will open where you can select the item to add and, the Add button in that dialog box is a pulldown menu that includes Add as link and Add. yes, that what happens in a normal project (e.g. C#) However, the add button in that dialog box doesn't have a pulldown in my wix project... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Tuesday, March 27, 2007 12:24 PM To: Chris Bardon; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix votive stable version Can you, or anyone else for that matter, insert a link to another project, as Justin described here: Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive In Visual Studio, when you select Add Existing File... if you just click Add, then the file will be copied to your local directory. This is by design and works the same way as C#, VB, etc. If you want to add a link, which you do, then drop down the little arrow next to the Add you'll see an Add As Link option. You want to select that. This will then populate your MSBuild (.wixproj) file for you correctly. You will not be allowed to Delete that file, but you can remove the link from your project. Does this make sense? There is no add as link option shown on my system when I right click the project on my my system. Add shows New Item Existing Item and Folder. Am I looking in the wrong place? Anthony Wieser Wieser Software Ltd - Original Message - From: Chris mailto:[EMAIL PROTECTED] Bardon To: Nitin Chaudhari mailto:[EMAIL PROTECTED] ; wix-users@lists.sourceforge.net Sent: Tuesday, March 27, 2007 3:20 PM Subject: Re: [WiX-users] Wix votive stable version So far, I've been using the Votive 3.0 build without any problems. I think the only thing unstable about the build is that there could be breaking changes in future releases that mean you'll have to change your code. Other than the environment variable macros (being able to refer to project output) not being in the 3.0 build, it seems to be much fuller featured than 2.0. Chris - 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.php http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV p=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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
Re: [WiX-users] Problems with Post Build Step and Dependencies in Votive
In Visual Studio, when you select Add Existing File... if you just click Add, then the file will be copied to your local directory. This is by design and works the same way as C#, VB, etc. If you want to add a link, which you do, then drop down the little arrow next to the Add you'll see an Add As Link option. You want to select that. This will then populate your MSBuild (.wixproj) file for you correctly. You will not be allowed to Delete that file, but you can remove the link from your project. Does this make sense? To do this manually, you have to do this: Content Include=relative path to file LinkHow you want the file to appear in your project/Link /Content A more concrete example: Content Include=..\Release\MyExe.exe LinkMyExe.exe/Link /Content You shouldn't get messy directory structures if you do this approach. Justin -Original Message- From: Anthony Wieser [mailto:[EMAIL PROTECTED] Sent: Friday, March 23, 2007 7:38 AM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies in Votive - Original Message - From: Justin Rockwood [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Thursday, March 22, 2007 6:40 PM Subject: RE: [WiX-users] Problems with Post Build Step and Dependencies in Votive Do you mind logging a bug on the _TimeStampAfterCompile? I'll look into that. Done. As far as forcing a recompile... You can do that by including your inputs into your .wixproj project file as Content elements. In Votive, you do this by selecting Content from the Build Type property in the property browser (hit F4 if it's not showing). If you're working just with the MSBuild .wixproj file, you can just add ContentRelative path to file/Content in an ItemGroup section. When compiling, I account for the Content elements to trigger a rebuild if they change. Justin I can't get this to work with Votive. My solution is structured as follows: Proj-root | |-Main Program Project | |-Debug | |-Release [exe to depend on is here] | |-Wix Project ||-bin ||--Release [msi ends up here] In my project in VS2005, I right click on the Wix project, and choose Add Existing Item... When I navigate up the hierarchy to release, what happens is that a copy of the selected .exe file ends up in the Wix Project folder. the .wixproj file contains: ItemGroup Content Include=myprog.exe /ItemGroup Is that correct? Manually editing as suggested above to Content Include=..\release\myprog.exe makes the project expand into a messy disaster of .. folders, which presumably isn't correct either. Especially as there are 3 .. based folders! looking at the aftermath of that, this is what ends up in the wixproj file: ItemGroup Folder Include=..\ / Folder Include=..\release / /ItemGroup Being of a suspicious nature, I created another folder, and then deleted it, and found it was removed from my disk. I dread to think what will happen if I try to delete one of these from within votive, but why not? Don'tTryThisAtHome Deleting the .exe shown under folder release under folder .. does indeed delete the exe from the release... Deleting the folder release under the folder .. the exe was in: You guessed it. The folders gone. Deleting the other folder release that was under the populated .. tries to delete, but, instead gives: Internal MSBuild Error: No parent BuildItemGroup for item to be removed. /Don'tTryThisAtHome Even I'm not brave enough to delete my parent folder, which contains the project I'm in and everything else. Ideally, I'd like to link in the outputs of the same configuration somehow into the dependency tree, though I'm not sure how to do that now. Any ideas? Anthony Wieser Wieser Software Ltd p.s. What's the proper protocol for replies like this? Should they go to the author and the list, or just the list? - 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
Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive
Right mouse click on your project -- Add/Existing Item -- an open dialog pops up -- the Add button is actually a drop down button à click on Add As Link. Here's a screen shot. -Original Message- From: Anthony Wieser [mailto:[EMAIL PROTECTED] Sent: Friday, March 23, 2007 2:15 PM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive In Visual Studio, when you select Add Existing File... if you just click Add, then the file will be copied to your local directory. This is by design and works the same way as C#, VB, etc. If you want to add a link, which you do, then drop down the little arrow next to the Add you'll see an Add As Link option. You want to select that. This will then populate your MSBuild (.wixproj) file for you correctly. You will not be allowed to Delete that file, but you can remove the link from your project. Does this make sense? There is no add as link option shown on my system when I right click the project on my my system. Add shows New Item Existing Item and Folder. Am I looking in the wrong place? Anthony Wieser Wieser Software Ltd attachment: image001.jpg - 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
Re: [WiX-users] Problems with Post Build Step and Dependencies in Votive
Do you mind logging a bug on the _TimeStampAfterCompile? I'll look into that. As far as forcing a recompile... You can do that by including your inputs into your .wixproj project file as Content elements. In Votive, you do this by selecting Content from the Build Type property in the property browser (hit F4 if it's not showing). If you're working just with the MSBuild .wixproj file, you can just add ContentRelative path to file/Content in an ItemGroup section. When compiling, I account for the Content elements to trigger a rebuild if they change. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Thursday, March 22, 2007 4:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problems with Post Build Step and Dependencies in Votive Hi, I'm trying to set up my project to automatically sign my msi files, so I've added a a post build step that looks like this: signcode CERTIFICATE ARGUMENTS HERE -t http://timestamp.verisign.com/scripts/timstamp.dll $(TargetDir)AutoSharesWx.msi and the run post build event is set to: When the build updates the project output That all seems to work fine, though you get a strange error if the build fails: 1C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(360,7): Error MSB4057: The target _TimeStampAfterCompile does not exist in the project. Ignoring that though, what I really want to be able to do is set dependencies on my Votive project to force it to recompile when my inputs change (say A.exe as an example). I've tried adding A.exe as a reference, but that doesn't work, nor does adding it as an embedded resource in the project. I must be missing something. Anthony Wieser Wieser Software Ltd - 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 - 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
Re: [WiX-users] Votive v3 and UI
Do you mean adding the wxl file or the wixlib/wix extension (dll)? I notice that this experience is perhaps not the most intuitive. Any suggestions on how I can make this more obvious or easier to discover in Votive? Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Tuesday, March 13, 2007 9:39 AM To: Levi Wilson; Simon Dahlbacka Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and UI I noticed that field, but adding a culture value to it doesn't appear to do anything. I tried en-US, en-US;, and even the example en-US;ja-JP listed below the textbox, and I still got the same errors. Adding the wxs file directly seems to be the only thing that works. From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 12:35 PM To: Simon Dahlbacka Cc: Chris Bardon; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and UI Maybe that's what it was...that it was TOO easy :-) I usually miss those. On 3/13/07, Simon Dahlbacka [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yes, (at least semi obvious) Using votive you select project properties (right-click project - properties, select linker tab) specify e.g. en-US in the Cultures textbox, and add a reference to WixUIExtension On 3/13/07, Chris Bardon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thanks for the reply-I managed to get it to work by adding a copy of the .wxl to the project, but I can't find anywhere to modify the light command line in the project. Am I just missing something obvious? On a semi-related note, is there something special you have to do with Votive to customize bitmaps from one of the UI libs? I tried creating a bitmaps directory, below the wxs file, but it seems to be ignored (regardless of whether the new bitmaps are added to the project or not). Is it not possible to customize the dialogs when using the WixUIExtension DLL? I'm planning on creating my own UI lib based off of Mondo, but I'd like to be able to customize it with different graphics when referenced in different setups. From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 11:50 AM To: Chris Bardon Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and UI When using WiX UI stuff from the WixUIExtension DLL in version 3, you need to add: -ext WixUIExtension -cultures:en-us To the light command-line. This should take care of a lot of those warnings. On 3/13/07, Chris Bardon [EMAIL PROTECTED] wrote: I've been going through the tuorial at http://www.tramontana.co.hu/wix/ and adapting to some of the v3 changes as I go, and I've run across a problem with adding UI elements. If I put in the UIRef elements UIRef Id =WixUI_Mondo / and UIRef Id= WixUI_ErrorProgressText / I get an unresolved symbol reference. Makes sense, since there's no reference to the UI lib. I checked in the target directory for the Votive/WiX MSI from the website though, and there's no wixlib files in the install directory. There's a WixUIExtension.dll that I can reference, but this doesn't seem to have any of the strings defined (LGHT0102 gets raised 552 times). It looks like I have to link using the WXL file for the language, but none of the WXL files are installed with the package. Is there no way to build an installer without downloading the source? Since I'm trying to set up a build process for Wix editing/installer creation where any developer on the team can edit/publish installers, I'd rather have everything they need to be encapsulated in a redstributable (i.e. not a separate source download). Is there just something that I'm missing with getting Votive to build using a UI? Thanks for the help Chris - 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.php http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV p=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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.php http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV p=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive v3 and UI
Good points. I don't necessarily like defaulting to en-US, just because WiX is being used quite heavily in other locales (German, Russian, and Dutch are ones that come to mind). However, defaulting to the OS culture makes a lot of sense. Let me know if you have any other suggestions as you dig more into your project. Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Tuesday, March 13, 2007 10:41 AM To: Ashman, Jared; Levi Wilson; Simon Dahlbacka Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and UI Ah, that did it, thanks. Probably just a bug with the settings not being saved in both cases. I know I've done the same thing more than once. As for Justin's question, the only thing I can think of off the top of my head is to at least automatically define the en-US culture when adding the reference to the UI DLL. If nothing else, this will mean that anyone who wants to compile to en-US will be able to do so without digging through properties, and others will be able to find the culture settings if they need to. Picking up the automatically included culture from the OS could also be an option, as would automatically including at least one culture in the properties, and then ignoring it if it's not needed (i.e. not compiling with the DLL). I'll see what else I come up with as I start venturing into more custom UI along the way (which I suspect will introduce a bunch of new questions). Chris From: Ashman, Jared [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 1:28 PM To: Chris Bardon; Levi Wilson; Simon Dahlbacka Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Votive v3 and UI Chris, If you add the en-US to the field, then open the advanced properties below that, then save, it does save the culture. The important step is the advanced properties for some reason. Jared M. Ashman mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Tuesday, March 13, 2007 11:39 AM To: Levi Wilson; Simon Dahlbacka Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and UI I noticed that field, but adding a culture value to it doesn't appear to do anything. I tried en-US, en-US;, and even the example en-US;ja-JP listed below the textbox, and I still got the same errors. Adding the wxs file directly seems to be the only thing that works. From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 12:35 PM To: Simon Dahlbacka Cc: Chris Bardon; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and UI Maybe that's what it was...that it was TOO easy :-) I usually miss those. On 3/13/07, Simon Dahlbacka [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yes, (at least semi obvious) Using votive you select project properties (right-click project - properties, select linker tab) specify e.g. en-US in the Cultures textbox, and add a reference to WixUIExtension On 3/13/07, Chris Bardon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thanks for the reply-I managed to get it to work by adding a copy of the .wxl to the project, but I can't find anywhere to modify the light command line in the project. Am I just missing something obvious? On a semi-related note, is there something special you have to do with Votive to customize bitmaps from one of the UI libs? I tried creating a bitmaps directory, below the wxs file, but it seems to be ignored (regardless of whether the new bitmaps are added to the project or not). Is it not possible to customize the dialogs when using the WixUIExtension DLL? I'm planning on creating my own UI lib based off of Mondo, but I'd like to be able to customize it with different graphics when referenced in different setups. From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 11:50 AM To: Chris Bardon Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and UI When using WiX UI stuff from the WixUIExtension DLL in version 3, you need to add: -ext WixUIExtension -cultures:en-us To the light command-line. This should take care of a lot of those warnings. On 3/13/07, Chris Bardon [EMAIL PROTECTED] wrote: I've been going through the tuorial at http://www.tramontana.co.hu/wix/ and adapting to some of the v3 changes as I go, and I've run across a problem with adding UI elements. If I put in the UIRef elements UIRef Id =WixUI_Mondo / and UIRef Id= WixUI_ErrorProgressText / I get an unresolved symbol reference. Makes sense, since there's no reference to the UI lib. I checked in the target directory for the Votive/WiX MSI from the website though, and there's no wixlib files in the install directory. There's a WixUIExtension.dll that I can reference, but this doesn't seem to have any of the strings defined (LGHT0102
Re: [WiX-users] Pre-Processor Directives ??
Yep, I'm close to having it back. :) For now, you can just define those variables yourself and pass them into the command line. If you're using a .wixproj with MSBuild/Votive, then you can define them in the DefineConstants property variable. In Votive, the property pages will give you access to that property as well if you prefer to set it via a UI. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Tuesday, March 13, 2007 4:06 PM To: Ryan Perlman; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Pre-Processor Directives ?? Supported in Votive v2, not supported in Votive v3 (although Justin keeps telling me he's close). I want the feature back too. smile/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Perlman Sent: Tuesday, March 13, 2007 3:32 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Pre-Processor Directives ?? According to the Documentation that I have found on the net. If you add a Wix Project to your solution you should be able to get the files of the project thru preprocessor Directives such as $(var.MyApp.TargetDir). But when I do this I get an Error Message stating Undefined Preprocessor variable '$(var.MyApp.TargetPath). Also if this is the syntax how does it handle it if you project was named MyApp.UI therefore giving you $(var.MyApp.UI.TargetPath)? Ryan PerlmanApplications Developer | +1(425) 703-8659 office | +1(206) 354-0838 mobile | IISBLK\5285 [cid:image001.png@01C76589.EF0FE630]http://www.microsoft.com/windowsvista/default.mspx Sent using Microsoft Office Outlook 2007 / Windows Vista Ultimate - 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
Re: [WiX-users] Votive for Orcas
There aren't any plans to add explicit support for Votive in Orcas until Orcas actually ships. I've got too much other stuff on my plate right now to add support for another platform. J Sorry about that. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peli de Halleux Sent: Tuesday, March 13, 2007 5:46 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Votive for Orcas The Wix v3 installer currently does not detect Orcas CTP. Is it planned to support it? - 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
Re: [WiX-users] Votive for Orcas
There aren't any plans to add explicit support for Votive in Orcas until Orcas actually ships. I've got too much other stuff on my plate right now to add support for another platform. J Sorry about that. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peli de Halleux Sent: Tuesday, March 13, 2007 5:46 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Votive for Orcas The Wix v3 installer currently does not detect Orcas CTP. Is it planned to support it? - 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
Re: [WiX-users] Votive v3 and variables
Soon, soon, I promise. J I've been working on it, but need to set aside some time to finish it up. And yes, I'll put them into the chm file as well. Good suggestion. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Dahlbacka Sent: Thursday, February 22, 2007 1:23 PM To: Chris Bardon Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and variables The feature request is still there (http://sourceforge.net/tracker/index.php?func=detailaid=1585281group_id=105970atid=642717 ) so I guess not... regards, Simon On 2/22/07, Chris Bardon [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: I decided to try out Votive v3 to see if it fixed the problem I was having with v2 and building an installer with a UI, and I found that as soon as I imported my wxs file into the new project, I got errors on the environment variables (e.g. src=$(var.testDLL1.TargetPath)) saying that the symbols could not be resolved. I found a reference to this in te mailing list archive from before Christmas saying that these variables were taken out for testing, but would be making their way back into Votive. Have they been reintroduced yet? Also, it'd be great if these variable definitions made it into the .chm help file-the only place I was able to find them was in the MSDN article. Thanks, Chris - 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.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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
Re: [WiX-users] Votive v3 and variables
Soon, soon, I promise. J I've been working on it, but need to set aside some time to finish it up. And yes, I'll put them into the chm file as well. Good suggestion. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Dahlbacka Sent: Thursday, February 22, 2007 1:23 PM To: Chris Bardon Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 and variables The feature request is still there (http://sourceforge.net/tracker/index.php?func=detail http://sourceforge.net/tracker/index.php?func=detailaid=1585281group_id=1 05970atid=642717 aid=1585281group_id=105970atid=642717 ) so I guess not... regards, Simon On 2/22/07, Chris Bardon [EMAIL PROTECTED] wrote: I decided to try out Votive v3 to see if it fixed the problem I was having with v2 and building an installer with a UI, and I found that as soon as I imported my wxs file into the new project, I got errors on the environment variables (e.g. src=$(var.testDLL1.TargetPath)) saying that the symbols could not be resolved. I found a reference to this in te mailing list archive from before Christmas saying that these variables were taken out for testing, but would be making their way back into Votive. Have they been reintroduced yet? Also, it'd be great if these variable definitions made it into the .chm help file-the only place I was able to find them was in the MSDN article. Thanks, Chris - 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.php http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV p=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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
Re: [WiX-users] Votive - Adding File as a Link
It's one of the things on my list to do, but linked files do not currently work yet. Sorry about that. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Capaldi Sent: Thursday, February 08, 2007 6:10 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Votive - Adding File as a Link Hi, I'm playing around with Votive v3.0.2211.0 in Visual Studio 2005 Team Edition for Software Developers. I would like to add an existing item into my WiX project as a link, but the dialog box doesn't have the drop down box on the Add button like other projects. I can only Add files, which means that the file is physically copied into the project folder on the file system Is there any way to add files to a Votive projects as a link? Regards, Mark Capaldi - 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] Votive - Adding File as a Link
Another thing you can try, which is the way it's supposed to officially work, is this: ItemGroup Compile Include=..\..\..\FileName.cs LinkFileName.cs/Link /Compile /ItemGroup I can't remember if this works in Votive or not. I think it does, though. Try it out and let me know. Justin From: Cullen Waters [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 12:47 PM To: Justin Rockwood; 'Mark Capaldi'; WiX-users@lists.sourceforge.net Subject: RE: [WiX-users] Votive - Adding File as a Link If you edit the project file directly, you can do this. In the ItemGroup Compile Include=my file.wxs / /ItemGroup Section, just add another entry like this: Compile Include=PathToFileMySecondFIle.wxs/ Now, there is a catch. When you reload the project in VS, it's going to be ugly. VS will add a Folder tag for each folder in the relative path from your project directory to the file. And it adds one folder entry for each level of folder. For instance, I have a file that is two directories up from my project file. So, when I open the project in VS, I have an empty folder for .., an empty folder for ..\.., and a folder that is for ..\..\, but has the item in it. Not pretty, but it works. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Rockwood Sent: Thursday, February 08, 2007 12:28 PM To: 'Mark Capaldi'; WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive - Adding File as a Link It's one of the things on my list to do, but linked files do not currently work yet. Sorry about that. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Capaldi Sent: Thursday, February 08, 2007 6:10 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Votive - Adding File as a Link Hi, I'm playing around with Votive v3.0.2211.0 in Visual Studio 2005 Team Edition for Software Developers. I would like to add an existing item into my WiX project as a link, but the dialog box doesn't have the drop down box on the Add button like other projects. I can only Add files, which means that the file is physically copied into the project folder on the file system Is there any way to add files to a Votive projects as a link? Regards, Mark Capaldi - 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] Wix 3.0 and Votive?
You can edit that property (DefineConstants) in the property pages if you're using Votive. Just right mouse click the project in Solution Explorer and click Properties. Alternatively, you can edit the .wixproj file directly and add DefineConstantsName=Value;Name2=Value2/DefineConstants within an existing PropertyGroup. Make sense? Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, February 07, 2007 11:00 AM To: Cullen Waters; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0 and Votive? Sorry I'm kind of new to this. Is that the msbuild file for the specific project correct? Is there a way to edit that in VS/TFS? From: Cullen Waters [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 1:01 PM To: Scott Sam; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0 and Votive? What I did was set a property called DefineConstants in my MSBuild file. Then, when candle is executed, the WixTasks convert that semicolon separated list of variables into -dname=value when passed into the candle command line. The only thing you might have to do is change the env. prefix to var., if nant was setting an environment variable for you. From: Scott Sam [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 8:58 AM To: Cullen Waters; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0 and Votive? Thanks, I've gotten the wxs files updated, and added them to the projects in TFS. How do you handle the source path for the files being added to the msi? Before I used a nant variable in the wix as part of the path. Is there a similar way to do this using MSBuild? It looks like the path will change based on whether or not it is a debug or release build. From: Cullen Waters [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 1:54 PM To: Scott Sam; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0 and Votive? I just moved my whole team from v2 to v3. In general, the update went really smoothly. You can use wixcop.exe to update all of the xml for you. Wixcop doesn't, however remove shortnames, which might cause you some headaches. I went through all my xml and manually deleted all the short names. What might cause you some extra work, depending on how you use v2, is that v3 runs msi validation as part of light. We found a bunch of msival errors in our MSIs when we went to v3, and it took some time to work through them. This is a good thing, though, since you have essentially raised the quality bar of your installers by doing this. We use votive with VS Team Suite, and we haven't had any problems yet. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Thursday, February 01, 2007 10:47 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0 and Votive? I was thinking of trying out votive. We are using Visual Studio Team Edition for Developers with Team Foundation Server. We are also using WIX v2 for the msi. I was wondering, is Wix v3 stable enough to use if we are deploying our next version of our product in about 3-5 months. Has anyone used votive with team foundation server? Are there any problems to be expected when moving from wix v2 to wix v3? - 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] preprocessor variable $(var.Build)
Yep, Oliver summed it up pretty well. As far as Votive is concerned, you can define the preprocessor variable by entering Configuration=$(Configuration) on the compiler property page (not linker property page). Also, make sure to put the parenthesis (which you missed in your example below). I think this is just a case of incorrect syntax for you. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Foster, Richard - PAL Sent: Tuesday, November 07, 2006 7:34 AM To: Friedrich, Oliver; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] preprocessor variable $(var.Build) Oliver, I'm still a bit unsure about where you are getting the error (I.e. are you building the installation from the command line? Within Visual Studio 2005? Somewhere else?). Unfortunately, I also don't use Votive so the vast majority of this reply is guesswork! I suspect that the MSBuild variable Configuration is being set, but that when you are seeing the error it is because this variable is never being passed to WiX. Depending on your build process, to get the information to WiX youmay need to pass it via the command line (e.g. -dWixVariableName=$(MSBuildVariableName) ), in which case you would access it using $(var.WixVariableName), or set an environment variable (e.g. set SomeEnvironmentVariable=$(MSBuildVariableName) ) and access it in WiX using $(env.SomeEnvironmentVariable). It is likely that Votive is intended to do this for you (like I said, I don't use Votive, so I don't know for certain), in which case you may have uncovered a bug. I also notice that you mention that you found a batch file setting var.Build to $(ConfigurationName).If true, this may not be desirable, since within WiX you may then need to reference that variable as $(var.var.Build). Within it's scripts, WiX requires the addition of the var prefix to indicate thatyou want to usea WiX variable (not an environment variable or system setting), but you do not specify that prefix when defining the variable. Hopefully this offers at least some additional information which may help you determine where you need to look. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Friedrich, Oliver Sent: Tuesday, November 07, 2006 03:37 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] preprocessor variable $(var.Build) Well, seems like $(Configuration) is set by Votive, but inside the WiX-code I can not access it? With : Property Id='MyProp' Value=$(Configuration)/ I get the Errormessage: Error1Ill-formed preprocessor variable 'Configuration'. Variables must have a prefix (like 'var.', 'env.', or 'sys.') and a name at least 1 character long.Z:\Projects\Aldi - Intranet\EwsSetup\Features\Ews_Mmc.wxs51EwsSetup Those three throw Undefined preprocessor variable: Property Id='MyProp' Value=$(var.Configuration)/ Property Id='MyProp' Value=$(sys.Configuration)/ Property Id='MyProp' Value=$(env.Configuration)/ On the properties of the .wixproj in the linker tab, there I can set userdefined variables, there I added Configuration=$Configuration but even then, I can not access this variable like above inside my WiX-code. Oliver From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 6:58 AM To: 'Bob Arnson'; Friedrich, Oliver Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] preprocessor variable $(var.Build) The variable $(Configuration) is set by most MSBuild scripts automatically (C#, VB, VJ#, WiX, etc.). Also, $(ConfigurationName) is usually set as well, but Id probably go with $(Configuration). You wont be able to know what the configuration is outside of MSBuild, but assuming that youre using C# or VB.NET, then you should already have this defined for you by the time you call your Pre-build event. If youre using Votive (and therefore wix.targets), then you also get $(Configuration) defined for you. Im not sure if $(ConfigurationName) is defined. If not, its a bug. Justin From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 7:28 PM To: Friedrich, Oliver Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] preprocessor variable $(var.Build) Friedrich, Oliver wrote: Alright,justfoundout,wherethisvariablewasset.Itissetonthecommandlinewhilecallingthebatch-filetostartthecompilationofthesetup. The batch-file is called as Pre-build event command line in VS2005. The variable var.Build is set to the value of $(ConfigurationName). The last is homemade of VisualStudio. How can I access this ConfigurationName under WiX-V3? WiX doesn't support that as it's a Visual Studio-specific concept. Votive might, though. JRock? -- sig://boBhttp://bobs.org * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e
Re: [WiX-users] msbuild nant task and WiX
Or you can just use the built-in wix.targets file that we ship with wix. That will do all of the right stuff for you, including smart incremental builds. If you use Votive v3, you'll automatically get MSBuild projects, but you don't have to use Votive to still use the wix.targets file. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lerudjordet, Morten Minge Sent: Monday, November 06, 2006 6:45 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] msbuild nant task and WiX In you'r msbuild file you can do something like this. Target Name=MakeMSI Exec Command=candle.exe -out DestOfWiXObjFiles\Product.wixobj Product.wxs/Exec Exec Command=light.exe -out DestFolderOfMSI\MyProdctName.msi Product.wixobj +ALL OTHER WIXOBJ files you need -loc WixUI_en-us.wxl/Exec /Target Target Name=MakeSetup DependsOnTargets=GenerateConfig;MakeMSI /Target morten Message: 5 Date: Mon, 6 Nov 2006 13:18:36 - From: Pawel Pabich [EMAIL PROTECTED] Subject: [WiX-users] msbuild nant task and WiX To: wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hi, What is the easiest way of being able to build my WiX installer project taking into account that I'm using msbuild task to build my solution? Thanks Pawel Pabich -- next part -- An HTML attachment was scrubbed... URL: http://sourceforge.net/mailarchive/forum.php?forum=wix-users/attachments /20061106/1413cde3/attachment.html -- Message: 6 Date: Mon, 6 Nov 2006 14:20:58 +0100 From: Friedrich, Oliver [EMAIL PROTECTED] Subject: Re: [WiX-users] preprocessor variable $(var.Build) To: wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Alright, just found out, where this variable was set. It is set on the commandline while calling the batch-file to start the compilation of the setup. The batch-file is called as Pre-build event command line in VS2005. The variable var.Build is set to the value of $(ConfigurationName). The last is homemade of VisualStudio. How can I access this ConfigurationName under WiX-V3? Sorry for the trouble... Oliver From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 6:04 PM To: Friedrich, Oliver Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] preprocessor variable $(var.Build) Friedrich, Oliver wrote: No, we did not use Votive V2, just plain wxs-files that we added to a simple solution, we did not use Votive V2. Sorry, I'm not understanding. Are you asking how to set the Build variable using Votive? -- sig://boB http://bobs.org -- next part -- An HTML attachment was scrubbed... URL: http://sourceforge.net/mailarchive/forum.php?forum=wix-users/attachments /20061106/70c1b015/attachment.html -- - 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 End of WiX-users Digest, Vol 6, Issue 21 - 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 - 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] Convincing customer to use WiX toolset - is itenterprise ready?
Here are some of the Microsoft products and groups that use WiX for their installations: * Office 2007 * Office Server 2007 * Windows SharePoint Server * SQL Server 2005 * Visual Studio * Windows Defender Additionally, there are several non-Microsoft products that use WiX. The biggest one that comes to mind is MySQL. There are lots more, but I can't remember off the top of my head. WiX has become the de-facto installation technology within Microsoft and all of the major product groups use it for their installations. If you or your client are worried about the stability, robustness, etc. don't be. The fact that some of the largest software products in the world use WiX should be testament enough that it's enterprise ready. Now, having said that, it doesn't mean that WiX is complete by any means. There is still lots of active development that goes on in the 3.0 version (which is still beta). Also, although there's a Visual Studio development experience, Votive still lacks a lot of the nice GUI designers that you'll find in Wise or InstallShield. There are some 3rd party designers for WiX files also available. And yes, sadly our documentation is not up to snuff yet. Let us know if you have any other questions. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Blaszczynski Sent: Monday, November 06, 2006 2:58 PM To: 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Convincing customer to use WiX toolset - is itenterprise ready? Hello! Thnx for replies - they are very helpful. Can someone from MSFT WiX developers confirm which enterprise grade product installers are currently created with help of WiX package? Rgrds Jacek -Original Message- From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 9:48 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Convincing customer to use WiX toolset - is itenterprise ready? I know that Microsoft use WiX for at least some parts of the SQL Server 2005, Office 2007 and Exchange Server 2007 installers. Version 2.0.x is considered the stable version. It does get bugfixes, but no major new development. Version 3.0.x is considered the unstable development version. The versions at http://sourceforge.net/project/showfiles.php?group_id=105970 of both are considered particularly stable; there are point releases (approximately weekly) at http://wix.sourceforge.net/releases/ (when it works). Most people want to download the binaries or the Votive MSI, not the sources package. It's self-contained - no other tools are necessary, not even the Windows Installer SDK. Votive is the GUI, which is a Visual Studio integration package. The documentation is in the 'doc' folder of the binaries package as a chm file. Documentation is currently a weak area - the WiX.chm file gives the syntax, but not really much in the way of semantics. There's a tutorial at http://www.tramontana.co.hu/wix/. WiX gives mostly direct access to the Windows Installer tables, so the SDK documentation is often the best source for understanding what's going on. I also find Phil Wilson's book The Definitive Guide to Windows Installer useful, although it may be helpful if you've had some experience with Visual Studio's deployment projects before reading it. You should probably also read Rob Mensching's blog at http://blogs.msdn.com/robmen/. To see how the default user interface looks during an install, get the UI sample linked from http://www.tramontana.co.hu/wix/lesson2.php (http://www.tramontana.co.hu/wix/download.php?file=samplewixui.ziptype=appl ication/zip). This uses the WixUI-Mondo user interface. However, WiX is a full Windows Installer tool, and can create any UI that the developer can think of and that the Windows Installer runtime will support. If you want to do something that Windows Installer cannot support (um, like all the Microsoft applications listed above!) then you need to create an external UI handler program, but that is actually not very common. The documentation at http://wix.sourceforge.net/manual-wix2/wix_index.htm is for WiX v2.0, and is a little out of date - I'm not sure when it was last generated. It's basically the same information as in the HTML Help file. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Blaszczynski Sent: 06 November 2006 10:51 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Convincing customer to use WiX toolset - is itenterprise ready? Hello! I am in process of trying to convince customer who looks for enterprise grade InstallShield installation package improvements. I have proposed to replace it with WiX based installer and pointed him to WiX sourceforge.net site and got a very fast answer with several doubts: 1. The sourceforge site indicates this is still in beta, so it is probally not ready for use for a commercial project which we
Re: [WiX-users] Convincing customer to use WiX toolset - is itenterprise ready?
1. Good idea. We should probably do that on our home page. 2. I can get to wix.sourceforge.net just fine. Maybe SourceForge was down for a minute? If you keep having problems getting to it, let us know. Justin -Original Message- From: Jacek Blaszczynski [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 5:23 PM To: 'Justin Rockwood'; 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Convincing customer to use WiX toolset - is itenterprise ready? Hello Justin! Thnx for this list of references it is really very helpfull to me. Personally I am not worried for WiX stability or robustness and I used it for all my installation packages created during last year. Furthermore, I am a strong advocate of WiX among all my customers. However, I would strongly recommend to fix 2 small things which create problems for coders trying to convince their customers to use WiX: 1. Provide official list of most prominent installer packages created with WiX - it tells actually everything. 2. Provide nice WiX home page linked via sourceforge.net project page - currently wix.sourceforge.net points to nothing and it may be bad www card for the package. Jacek -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:16 AM To: [EMAIL PROTECTED]; 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Convincing customer to use WiX toolset - is itenterprise ready? Here are some of the Microsoft products and groups that use WiX for their installations: * Office 2007 * Office Server 2007 * Windows SharePoint Server * SQL Server 2005 * Visual Studio * Windows Defender Additionally, there are several non-Microsoft products that use WiX. The biggest one that comes to mind is MySQL. There are lots more, but I can't remember off the top of my head. WiX has become the de-facto installation technology within Microsoft and all of the major product groups use it for their installations. If you or your client are worried about the stability, robustness, etc. don't be. The fact that some of the largest software products in the world use WiX should be testament enough that it's enterprise ready. Now, having said that, it doesn't mean that WiX is complete by any means. There is still lots of active development that goes on in the 3.0 version (which is still beta). Also, although there's a Visual Studio development experience, Votive still lacks a lot of the nice GUI designers that you'll find in Wise or InstallShield. There are some 3rd party designers for WiX files also available. And yes, sadly our documentation is not up to snuff yet. Let us know if you have any other questions. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Blaszczynski Sent: Monday, November 06, 2006 2:58 PM To: 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Convincing customer to use WiX toolset - is itenterprise ready? Hello! Thnx for replies - they are very helpful. Can someone from MSFT WiX developers confirm which enterprise grade product installers are currently created with help of WiX package? Rgrds Jacek -Original Message- From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 9:48 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Convincing customer to use WiX toolset - is itenterprise ready? I know that Microsoft use WiX for at least some parts of the SQL Server 2005, Office 2007 and Exchange Server 2007 installers. Version 2.0.x is considered the stable version. It does get bugfixes, but no major new development. Version 3.0.x is considered the unstable development version. The versions at http://sourceforge.net/project/showfiles.php?group_id=105970 of both are considered particularly stable; there are point releases (approximately weekly) at http://wix.sourceforge.net/releases/ (when it works). Most people want to download the binaries or the Votive MSI, not the sources package. It's self-contained - no other tools are necessary, not even the Windows Installer SDK. Votive is the GUI, which is a Visual Studio integration package. The documentation is in the 'doc' folder of the binaries package as a chm file. Documentation is currently a weak area - the WiX.chm file gives the syntax, but not really much in the way of semantics. There's a tutorial at http://www.tramontana.co.hu/wix/. WiX gives mostly direct access to the Windows Installer tables, so the SDK documentation is often the best source for understanding what's going on. I also find Phil Wilson's book The Definitive Guide to Windows Installer useful, although it may be helpful if you've had some experience with Visual Studio's deployment projects before reading it. You should probably also read Rob Mensching's blog at http://blogs.msdn.com/robmen/. To see how the default user interface looks during an install, get the UI sample
[WiX-users] Votive v3 has been re-released!
All of the issues have (hopefully) been fixed and the new build should be good to go. You can find it at http://wix.sourceforge.net/releases/3.0.2120.0/Wix3.msi. Let me know what you think! Thanks, Justin - 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
Re: [WiX-users] adding -loc parameter to 'light' when building WiX project in Visual Studio 2005
The good news is that you're not a complete n00b. :) Votive v2 does not have support for passing in command line parameters to candle/light. However, all you have to do is add the .wxl file to the project and then it should automatically pass in the -loc parameter. I would recommend that you install Votive v3, since it's a lot more robust and you can do a lot more things with it. You can see my blog for the new features and the download location: http://blogs.msdn.com/jrock/archive/2006/09/15/757144.aspx. Thanks, Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Epstein Sent: Monday, September 18, 2006 10:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] adding -loc parameter to 'light' when building WiX project in Visual Studio 2005 Hello, I have just started using Votive2-2.0.4415.0 and Visual Studio 2005. In order to add the UI features to the installer, you need to supply the '-loc' parameter (and associated value) to the 'light' linker. I have been able to do this successfully from the command line. I have not found a way to pass the '-loc' parameter to the build inside Visual Studio 2005. I have looked in a number of properties screens and dialog boxes, but I have not been able to find where I can specify a value to add a parameter to the 'light' command line executed by a Visual Studio 2005 build. Has anyone else done this? Am I a complete n00b for not being able to find how to get the '-loc' parameter into the Visual Studio 2005 build? Thank you in advance for you help. Eric - 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 - 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
Re: [WiX-users] Votive v3 has been released!
When you installed Votive3.msi, did you have any instances of Visual Studio 2005 open? If so, please uninstall and reinstall without them open. If not, please let me know so I can look into it further. Thanks, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Welter Sent: Monday, September 18, 2006 9:28 AM To: wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive v3 has been released! Hi, Was excited to try out the new release but found a bug right away. After installing the Votive v3 latest build, I couldn't create a new project in Visual Studio. In the New Project dialog, under Wix, the project template list is empty. Is there some way to manually add the templates so I can get started using the latest build? thanks Paul On 9/16/06, Justin Rockwood [EMAIL PROTECTED] wrote: Well, after many weeks of work, I've finally checked in Votive v3. It is now available after any build = 3.0.2115.0. You can download it from http://wix.sourceforge.net/releases/3.0.2115.0/Votive3.msi. For details about what is in the new version, you can find out on my blog. It also has some screen shots. http://blogs.msdn.com/jrock/archive/2006/09/15/757144.aspx Let me know what you think! Thanks, Justin - 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 -- ~ Paul - 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
Re: [WiX-users] Votive v3 has been released!
Thanks for the email. Yes, this problem has been reported a couple of times. The issue is that our PLK (Package Load Key) hash no longer matches our registration since I bumped the version to 3.0 and changed the package GUID. I'll get this fixed for the next drop (which should be on Wednesday). Unfortunately the only workaround is to install the Visual Studio SDK so that the DLK is installed and will override loading the package using the PLK. Justin -Original Message- From: Pete Skelly [mailto:[EMAIL PROTECTED] Sent: Monday, September 18, 2006 1:00 PM To: Justin Rockwood Subject: Re: [WiX-users] Votive v3 has been released! Justin, Just installed the most recent version (v3.0.2115.0 - after grabbing the ProjectAggregators.msi from you blog post - thx). It appears that the Projects and ProjectItems folders have items that do not get unzipped during the installation. I followed your advice on the users-list and did an uninstall and fresh install, but with no luck. When I unzipped the Templates\Projects\WixProject.zip and then attempted to open VisualStudio, I get the error Make sure the application for the project type (.wixproj) is installed. My apologies for the direct email... trying to get the WiX users mailing list setup... Regards, Peter A. Skelly Senior Consultant ThreeWill L.L.C. mobile - 770.900.6172 office - 678.513.6930 fax - 678.513.6991 [EMAIL PROTECTED] http://www.threewill.com/ -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Monday, September 11, 2006 2:14 PM To: Pete Skelly Subject: RE: (votive, wix, vsip, and all things microsoft) : Votive 3.0 And Source Control It was checked in last week, but the build hasn't been pushed out to SourceForge yet. I think we'll have the build out on Wednesday. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, September 11, 2006 7:34 AM To: Justin Rockwood Subject: (votive, wix, vsip, and all things microsoft) : Votive 3.0 And Source Control Importance: High Hello Justin, I saw in a recent blog you indicated upsoming support for Source Control in Votive / WiX projects. Is this implemented yet? If yes, what build, if not, any idea on when it might be? Thanks in advance, Pete Skelly ThreeWill, LLC [EMAIL PROTECTED] -- This message was generated from a contact form at: http://blogs.msdn.com/jrock/default.aspx Your contact information was not shared with the user. - 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] Votive v3 has been released!
Well, after many weeks of work, I've finally checked in Votive v3. It is now available after any build = 3.0.2115.0. You can download it from http://wix.sourceforge.net/releases/3.0.2115.0/Votive3.msi. For details about what is in the new version, you can find out on my blog. It also has some screen shots. http://blogs.msdn.com/jrock/archive/2006/09/15/757144.aspx Let me know what you think! Thanks, Justin - 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] Cannot add new file with votive
Did you use votive.msi or votive3.msi? The votive3.msi has a brand new Votive that you'll probably want to use if you do use Votive. It's got all sorts of new stuff and a lot of bug fixes. I think you'll find that it's much more usable than votive2. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Torsten Rudnick Sent: Friday, September 15, 2006 3:32 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Cannot add new file with votive Today I switched to the latest version of votive from yesterday. Now it is not possible to add new files to the WiX project. There is no template available. A bad workaround is to add an empty text file and rename it to example.wxs. Additional I am not be able to create a new WiX project in VS 2005 Prof. Edition. The new project will be created but not be opened. In VS 2003 the project will be opened fine but adding new files still not work like on older projects. Any suggestions? - 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 - 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] Moving my wix 2 project into wix 3...
Unfortunately, extensions arent supported in Votive right now, so youll have to build via the command line. Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Monday, June 26, 2006 4:00 AM To: 'Harrborg Richard'; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Moving my wix 2 project into wix 3... You need to place WixDifxAppExtension.dll and the difx wixlib file (I dont know its name) in the same directory with candle, lit, light, etc Then when calling candle, you need to provide ext WixDifxAppExtension on the command line. Im not sure if this is possible from within Votive at this point. Justin would have to comment on that. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harrborg Richard Sent: Monday, June 26, 2006 2:56 AM To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Moving my wix 2 project into wix 3... WixCop produced the same code as I tried, so the syntax is right. But Votive still says: error CNDL0200 : The Component element contains an unhandled extension element 'difx:Driver'. Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/DifxAppExtension' namespace has been provided. I have tried putting the file difxapp.xsd in my Microsoft Visual Studio 8\Xml\Schemas folder. At least that trigged the IntelliSense function I believe Im sure there is a really simple solution to this =) // Richard From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: den 21 juni 2006 17:08 To: Harrborg Richard Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Moving my wix 2 project into wix 3... Harrborg Richard wrote: Hello! Trying code from link below in [EMAIL PROTECTED] 2005 (build 3.0.1821.0). http://shmarya.net/?cat=28 I have replaced the smiley with difx:Driver! I dont find any documentation on using the new schema changes in wix 3. For example, what is required to compile with the element Driver? I guess candle must have some link to the difxapp.xsd? DIFx support is in the WixDifxAppExtension. Try using WixCop on your original sources -- it should correctly update them to use the new schema. -- sig://boBhttp://bobs.org DISCLAIMER: This email is confidential and may also be privileged. Please delete the email and notify us immediately if you are not the intended recipient. The Trio Group of companies do not enter into contracts or contractual obligations via electronic mail, unless otherwise agreed in writing between parties concerned. 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
