Feature Requests item #1585281, was opened at 2006-10-26 11:43 Message generated for change (Comment added) made by justinrockwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642717&aid=1585281&group_id=105970
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: votive Group: None >Status: Open Priority: 8 Private: No Submitted By: Justin Rockwood (justinrockwood) Assigned to: Justin Rockwood (justinrockwood) Summary: Add solution and project variables back to Votive v3 Initial Comment: Votive v2 had a feature which has not yet been added back to Votive v3, and that is automatically defining the following preprocessor variables as part of the build. You should be able to right mouse click on the .wixproj file’s "References" node and add a project reference to another project in your solution (a C# DLL project, for example). Once you have one or more project references in your .wixproj file, then before the compile happens, I generate 10 sets of preprocessor definitions per project. For example, if my reference project was named MyCSharpProject, then I’d have the following preprocessor definitions: $(var.MyCSharpProject.ProjectDir) – example C:\MySolution\MyCSharpProject\ $(var.MyCSharpProject.ProjectExt) – example .csproj $(var.MyCSharpProject.ProjectFileName) – example MyCSharpProject.csproj $(var.MyCSharpProject.ProjectName) – example MyCSharpProject $(var.MyCSharpProject.ProjectPath) – example C:\MySolution\MyCSharpProject\MyCSharpProject.csproj $(var.MyCSharpProject.TargetDir) – example C:\MySolution\MyCSharpProject\bin\Debug\ $(var.MyCSharpProject.TargetExt) – example .dll $(var.MyCSharpProject.TargetFileName) – example MyCSharp.dll $(var.MyCSharpProject.TargetName) – example MyCSharp $(var.MyCSharpProject.TargetPath) – example C:\MySolution\MyCSharpProject\bin\Debug\MyCSharp.dll This then lets you do things like this in your wxs file: <Component Id=”MyCSharpProjectComponent” Guid=”…”> <File Id=”MyCSharpProjectOutput.dll” Name=”$(var.MyCSharpProject.TargetFileName)” Source=”$(var.MyCSharpProject.TargetPath)” KeyPath=”yes” /> </Component> ---------------------------------------------------------------------- >Comment By: Justin Rockwood (justinrockwood) Date: 2007-06-27 13:30 Message: Logged In: YES user_id=1054914 Originator: YES You're probably using native C++ project references, which aren't supported yet. The reason why they're not supported is because they're not MSBuild-compiant projects. I'll have to write a lot of custom code to parse the vcproj file format to extract the needed information. It's something that I'll probably do, but it will be a little bit before that's in. ---------------------------------------------------------------------- Comment By: Josh Korn (joshkorn) Date: 2007-06-26 18:18 Message: Logged In: YES user_id=1829360 Originator: NO Justin: I can't get this to work at all. I've added the project references, but the compiler still complains that the references don't exist. I even put a small macro at the top of the file, just to see what I'd get: <?ifndef $(var.OtherProject.TargetPath) ?> <?error var.OtherProject.TargetPath ain't defined - sorry?> <?endif ?> Of course, I get the "ain't defined - sorry" error. Any idea what might be wrong? Thx Josh ---------------------------------------------------------------------- Comment By: Justin Rockwood (justinrockwood) Date: 2007-05-21 14:16 Message: Logged In: YES user_id=1054914 Originator: YES Thanks for logging the extra bug. I'll treat that as a separate bug, since it works in non-batched builds. Thanks for testing as well! Here's the other bug: https://sourceforge.net/tracker/index.php?func=detail&aid=1722849&group_id=105970&atid=642714 ---------------------------------------------------------------------- Comment By: Doug S (tpaxatb) Date: 2007-05-21 09:38 Message: Logged In: YES user_id=1342505 Originator: NO This works from the command line as expected and also when doing a single solution configuration's build. However (and I don't know if this is a VS2005 issue or a WiX issue), when doing a batch build of multiple configurations, the target directory of the dependent projects is always set to the target directory of the currently selected solution configuration. e.g.: ConsoleApplication1 - executable WixProject1 - depends on ConsoleApplication1. Two configurations - Debug and Release (any cpu). Do a Batch Build on both configurations (Debug and Release), regardless of what the configuration manager says, if I have Debug|Any CPU as my currently selected solution configuration, it will always use bin\Debug\ConsoleApplication1.exe as the dependency resolotuion. Same for Release|Any CPU. In addition, the properties "Configuration", "FullConfiguration", and "Platform" of the dependent project are not defined unless a command line build is occuring (i.e. they are not set by the IDE build). This may also be why the managed C++ references aren't resolved completely. Also logged as new bug. ---------------------------------------------------------------------- Comment By: Justin Rockwood (justinrockwood) Date: 2007-05-17 21:36 Message: Logged In: YES user_id=1054914 Originator: YES This is finally done! For each project reference the following are defined as preprocessor variables: Configuration (i.e. Debug) FullConfiguration (i.e. Debug|AnyCPU) Platform (i.e. AnyCPU) ProjectDir ProjectExt ProjectFileName ProjectName ProjectPath TargetDir TargetExt TargetFileName TargetName TargetPath So, to use them you author this into your .wxs file: $(var.YourProjectName.TargetPath). There is still a known bug. If you have a managed VC++ project reference, you'll only get project references for this project if you build the solution from the command line. Building from within Visual Studio (in Votive) does not pick up the VC++ project reference correctly. If I find that people want this feature (i.e. somebody logs a bug on this), then I'll eventually fix it. Also it's important to note that native VC project references don't work either. That's because VC projects are not MSBuild-compliant and so I'll have to write a lot of custom code to dig into the VC project file that isn't technically supported (I'd be in no-man's land). Again, if people want this feature (it's a feature request and not a bug), then I may be able to get to it. ---------------------------------------------------------------------- Comment By: Justin Rockwood (justinrockwood) Date: 2007-05-14 13:28 Message: Logged In: YES user_id=1054914 Originator: YES I already have a local fix and plan to check in for next week's build. ---------------------------------------------------------------------- Comment By: Doug S (tpaxatb) Date: 2007-05-14 13:21 Message: Logged In: YES user_id=1342505 Originator: NO I've created a poor-man's version of this partially (by hijacking the ResolveProjectReferences target from Microsoft.Common.targets and adding that to a CustomAfterWixTargets file and depending AfterResolveReferences on this target) but is there any word on an ETA for this feature in an 'official' build? ---------------------------------------------------------------------- Comment By: HeO (heo) Date: 2007-03-01 06:42 Message: Logged In: YES user_id=1732464 Originator: NO Adjustment of priority highly appreciated :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642717&aid=1585281&group_id=105970 ------------------------------------------------------------------------- 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-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
