I have got an old project, C++, 64 bits compiled on VS2008. The project is built using some Python scripts (SCONS). I have got to compile it in VS2010.
All is working pretty fine except one small detail: in VS2008 all output goes to Debug\Win64 or Release\Win64, where scripts are looking for it, while in VS2010 it goes to Debug\x64 or Release\x64.
I know that there are PLATFORM/PLATFORMNAME macros being used by VS. Anything I did trying to change these values is mighty ignored by VS, or, if I am changing it manually in vcxproj files, VS refuses to compile at all.
For some company-related reasons scripts could not be changed. So for now I just added to a batch file that runs the script some xcopy commands to copy all the files from\x64 to \win64 before the script starts. It's kind of working, but I would like to know about a more elegant solution.
Thanks,
fLot
Another solution that might work is to create a file system junction so that \Win64 and \x64 becomes two different names to the same physical folder. You have to create a junction for each configuration instead of copying the files but once created it should stick between builds and ensure the two folders have the same content. See Wikipedia: http://en.wikipedia.org/wiki/NTFS_junction_point.
Related
I have a fairly large application (~750k LOC) that I distribute using the Package and Deployment Wizard. I fully understand that it would be nice to migrate to .NET (that ain't happening - see the code size above), and that the PDW is deeply flawed. However, for the most part I've made it work well for my end users, by customizing the Setup1 application, writing a menu-driven wrapper for the Setup application, and by running it in silent mode. (Note that the problem I'm about to describe occurred even before I started using silent mode.)
The issue I'm having is that my application requires quite a few auxiliary files, which I've added to the PDW project in the "Included files" section. When a user does a clean installation (either from scratch, or after un-installing a previous installation), everything works fine. However, if they simply run the installer to update the existing installation, the executable file and any OCXs I've updated get copied over the previous versions just fine, but my auxiliary files don't - I have to have the user manually delete them, and then the Setup1 program will re-install them as it should.
I've checked in the Setup.lst file, and all of the files are listed there, with their current date stamps. In fact, in my "BuildAll.bat" file, I do the Windows equivalent of a "touch" (copy /b "TheFile.dat" +,,) to force the date stamp to be current. However, if the file exists on the target machine, it won't be over-written even though it's older. There are no errors reported, either visibly or in the .LOG file (which is required if using the silent option).
A couple of additional points: Some of the auxiliary files are themselves VB6 applications - just the .exe files. Those do get copied correctly if they're newer than the existing files. Other than being files with internal versioning information, there's no difference between them and the other auxiliary files (which are things like media files, or text-based .txt or .dat files).
So, what's going on, and how do I fix it (besides moving to Inno or some other solution that won't work for me...)? Thanks in advance for any help!
~~
Mark Moulding
I need to include all the output from some of the programs projects in the installer... my question is similar to the one in this post: How to add a whole directory or project output to WiX package
However, I am afraid I don't really understand the answer given in this link. From all the reading I have done, I think I need to use Paraffin to do this. But is there a "start from the very beginning, how-to" resource for using paraffin?
I have read this page: http://www.wintellect.com/CS/blogs/jrobbins/archive/2008/12/22/paraffin-3-0-now-with-full-wix-3-0-support.aspx
and one of the posts mentions calling paraffin from a bat file. Is this how one would "use paraffin" in their installer? If it makes a difference, I have been using Visual Studio to work on this project, and am also not sure how to use command line from within Visual Studio. Does anyone have any resources for a very new beginner? Thanks.
I ended up including each .dll and .exe manually, since they don't change very often. It was fairly easy to format them in this style:
`<File Id="WhateverId" Name="NameToDisplayAfterInstall" Source="$(var.ProjectName.TargetDir)Filename.ext" />`
I used Excel to format a list of files quickly and easily. I put all of these File tags in the <DirectoryRef Id="INSTALLLOCATION">
tag.
I did figure out how to scrape all the dlls and exes from the project output by using Heat (not paraffin) and harvesting a directory, not a project. Harvesting a project yields only the main exe and dlls. The problem with harvesting a directory, at least in my case, is that I ended up with a lot of excess files, (like .pdb and .xml) that I didn't want.
I'm looking for general advice. I created a Visual Studio 2010 project that outputs an ocx file that is used on XP and Vista machines. The DLL on which it depends has been updated on our Win7 machines. I simply needed to rebuild for Win7 using the exact same code with an updated .lib file. I created a second project configuration (ReleaseW7) and it only differs from the original project config (Release) in that it points to the new .lib.
So now I have 2 files both named xx.ocx. Besides looking at the name of the folder each file resides in (or looking at the creation time of each) there is no way to determine which is which. I thought of using different file version numbers but as far as I can tell (and I'm relatively new to this so I could certainly be wrong) that would require two separate projects each with a slightly modified resource (.rc) file, instead of simply having two configurations within the same project. If nothing more, that seems like a waste of hard drive space. It also feels like the "wrong" way of using file version numbers
Is there a cleaner or more "standard" way of handling this? All I really want is a way for the folks who install the ocx and support the end user to know for certain that they are working with the correct file.
Long story short, I decided to use different version numbers. I was able to setup a preprocessor definition for the resource compiler and use that to handle different versions of VS_VERSION_INFO in my .rc file.
In case anyone is interested, this is the resource I found:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/605275c0-3001-45d2-b6c1-652326ca5340/
This is not a work-stopper in any way, but I thought I should ask anyway because it is a little annoying. Let's say I create a new project and start putting source files in a directory other than the default that shows up the first time. Afterwords, whenever I open the project, I have to navigate to the source directory once during that session. Like I said, not a big deal (but if solvable, then it's icing on the cake). Quite a few times I absentmindedly put the source file in the default directory and end up committing that file to the SVN and if I am lucky, going through all the files, removing them, then adding them again.
So my question is, is there any way to specify the default source directory on a per project basis?
I have run into the same nuisance. I like to put the public interface header files for a library in a separate directory, but end up with file directory typos because I forget to navigate to the correct directory when saving a new file. Unfortunately, Visual Studio does not offer a setting to change the default directory for new C++ source files.
I had the same problem when I started using build systems (CMake, Premake) which requires me to keep my project files separate from my source files, which hampered my workflow.
Although changing the default source directory seems impossible, if you aren't afraid to spend money, the workaround I found was to use the Visual Assist extension.
You can bind a shortcut of your choise to the Create File command which creates
a new file relative to the directory or your open file.
I'd also recommend to base one's workflow around the wonderful
Create from Usage command (which I think greatly boosts
productivity) which almost eliminates the need to manually create files.
The extension is great, albeit a bit costly. I would love to see Microsoft incorporate these features directly in the IDE eventually as they are found vanilla in a lot of other IDEs e.g. Eclipse, Intellij.
There might be some free extensions available that does the same thing, but I haven't found any.
Changing the Default Project Folder may help. This page demonstrates how to change the default for Visual Studio 2005, and it should be the same for later versions.
I'm looking for a utility that copies all files from a VS2010 solution folder, which are necessary to build the solution, but ignores all other files (.obj files etc). My intended use is for emailing solutions or making them available on a blog etc.
I'd prefer a utility that's portable (runs without having to be installed), but if there is none, I'll settle for whatever's available.
You may want to consider something as simple as a script (via .bat or powershell) that simply runs the solution's build with a /clean and then zips up the entire folder structure into an archive.
No need to be fancy, especially when project can need any number of impossible-to-know files to build. (What happens when a new language is released like F#? If you'd written your tool 3 years ago, you'd have to modify it for that. What happens if someone needs a .txt file or a .mak file to build?)
In the past I've created a new configuration within VS.NET (e.g. Deploy) which builds the code in release mode. I also set the output path for the main application project to build into a separate folder in the root of the project.
If it's a web application, this is a little more problematic as it won't copy the support files. To get over this I use a nant script to copy all of the appropriate files, that are needed but aren't included in the build, into the aforementioned build folder.