A default install of Visual Studio 2013 creates intermediate and output files in the source tree. This is makes housekeeping harder - I can't just nuke a whole directory to get rid of intermediate files, for example. It also makes it easy to accidentally add a whole bunch of said junk to source control by mistake.
How do you tell VS to put the files elsewhere?
Open your proj file in a text editor, and look for something like this, depending on your platform/configuration:
<OutputPath>bin\x64\Release\</OutputPath>
Change it to whatever path you want it to be.
At build time the locations of these files comes from the $(IntDir) and $(OutDir) build variables. These are defined by shared property sheet entries - shared as in shared by all projects built on a system. Updating that shared property sheet to put them elsewhere is a little tedious but only has to be done once.
For example, to change them such that intermediate files are placed in D:\Obj and output files are placed in D:\Exe:
From the View menu, select PropertyManager.
Expand any project node, e.g. MyProject.
Expand any platform configuration node, e.g. Debug | Win32.
Open the Microsoft.Cpp.Win32.user property sheet.
Select the General section
Set the Intermediate Directory to (note the trailing backslash!)
D:\Obj\$(SolutionName)\$(ProjectName)\$(Platform)\$(Configuration)\
Set the Output Directory to (note the trailing backslash!)
D:\Exe\$(SolutionName)\$(ProjectName)\$(Platform)\$(Configuration)\
Repeat these steps for the remaining platform configuration nodes, e.g. Debug | x64
The property sheets are shared by different build types (e.g. debug, release) within a configuration, but not across platforms. This is why you have to repeat the steps for each platform (e.g. Win32 & x64). But you only have to do this for one project because they all use the same set of property sheets.
BEWARE!
There is a possible issue with this setup. Because the full drive and path is omitted from the directories, if you have more than one copy of a project/solution they will both try to write their output to the same location, possibly leading to horribleness.
Related
I have a solution where there is a dependency on 7zip's sfx. Out of desire to keep the entire solution (plus the sfx) managed and coordinated, I want to create a new project to house all the source files that is used by sfx, and when building, execute a command line that tells 7zip to build a sfx from the source files, and place into the output so that it can be then referenced by actual Visual Studio projects within the same solution.
I think I can figure the command line by using Build events and providing the appropriate macros to ensure that the 7zip's output is placed into the target folder with appropriate name so that it can be then correctly referenced by other VS projects. But what I am not sure about is what Visual Studio project I need to use or steps to take to tell Visual Studio that there isn't going to be any code to be compiled in this project and it just has to execute this script I give it.
The closest thing I can come up with is VS's Make project but I don't know if that is the right thing since this has nothing to do with Make at all.
So, what is the Visual Studio project template I need to use? If empty, then what configuration do I need to perform so that it won't try and look for some code files to compile but instead just execute scripts as part of the solution's build?
For now, it seems that using C++ Makefile Project works. I had to make few configurations:
1) I had to specify the project's "Configuration Type" as "Utility"
2) I used Pre-Build event and provided a command to invoke a batch file included in the project. The batch file then takes care of everything.
3) Normally, non C++ files are not considered for determining whether build is needed or if it's already up to date. To ensure that a new build is perform if the batch file or other key files are edited, I set the file's "File Type" to "MakeFile". Even though it isn't actually a Make file, it ensures that any edits made to the file will cause a new build.
The downsides I've found so far are:
1) C++ uses "Filters", not folders. Therefore, keeping the files in same directory structure is a big PITA. One can "include" files and get a one-to-one mapping between "Filters" and the actual directory structure on disk but it's annoying and tedious. Wish it was a C# project
2) I'm a bit wary about how it will detect new files or other changes for files that I didn't explicitly set to "MakeFile". I expect the source to be stable but I worry that when I realize I need a new file and add it, I might forget and not notice that the build is not correctly including the new file.
I'm not sure if this is the best method but this works for my purpose - having a project to manage external tools as part of bigger build process.
What configuration do I need to give QMake to generate a vcxproj file where the object files are arranged in a tree like the original code?
I have been searching for quite a while and even scrutinized the source of qmake but to no avail.
So far I tried CONFIG -= flat which only changed the filters, but not the output paths. And object_parallel_to_source which only works with makefiles as far as I can tell.
I need the feature to avoid name clashes of object files having the same name, because their source files have the same name but reside in different folders.
It is definitely possible to avoid this with MSVC by setting the appropriate output path for files in their properties dialog. However, this is tedious and as I am developing a project mainly on Linux and then porting it over to Windows from time to time I have to do the whole procedure over and over again.
In Visual Studio 2010, how to I set up my VC++ import directories so that I can build my project from multiple machines? For example, my project requires the use of a graphics library that's installed on both of the machines I'm using, but located on different paths.
I imagine the answer is some sort of macro, but I'm new to Visual Studio, so I'm not sure if my intuitions are correct.
I'm transitioning from the Matlab environment, where you can set the path directly per machine, rather than per project. Does Visual Studio have such functionality, or is everything at the level of project properties?
You can indeed use macros to set your include and lib directories on a per machine basis.
if you have your files in your project directory you can use:
$(SolutionDir)\ This will point to the full path of your solution directory root
$(ProjectDir)\ This will point to the full path of your project directory root.
You can place your graphics library in your project directory and point to it like:
$(ProjectDir)\graphicslib, for example, or any other place you want to put it in your solution.
More info is located here http://msdn.microsoft.com/en-us/library/c02as0cs.aspx
use a hierarchy of property sheets, or use a tool like CMake to generate project files for you (as it should automatically find all the libs/includes).
For the property sheets: add the same property sheet to each project. Withing that property sheet, include other property sheets with predefined names. Then on each computer you work, you will have to provide those 'per-machine' propert sheets. For example:
main.vsprops -> include by every project
|- matlab.vsprops -> sets the lib/includes for matlab runtime
|- opengl.vsprops -> sets the lib/include for opengl
Now in your versioning system, you provide a default for matlab.vsprops and opengl.vsprops that contains suitable dfeault values and a batch file to create them. This way you can checkout from the VCS, run a single file, edit the vsprops and start coding without too much hassle. For example:
main.vsprops -> versioned
matlab.vsprops.def -> versioned, contains defaults
opengl.vsprops.def -> versioned, contains defaults
create_vsprops.bat -> versioned, copies *.vsprops.def to *.vsprops
I am building a cross platform product and one of the requirements is across windows(win32,AMD64 and IA61). The product as is relatively simple CLI but we have a separate build team who checks out the code from CVS and build in separate build environments. I am able to build succesfully(using Visual C++ 2005) in one platform(AMD machine). But once I check in the code, check out the build fails.
The cause of the build failure is because the include library paths are wrongly specified in the property sheets. Specifically the output file folder under the Linker in property pages are specified wrongly. So these libraries get built in a different folder from where the other projects are expecting them.
However along with the source I check in the .sln files (and later .vcproj files) also everytime. Morover if I open the .sln file in the folder where the build is not succeeding, there is no difference between the one where I could succesfully build(pre check in). In fact using windiff I could not see any difference between the two build folders (except some .ncb and cvs log files).
So any idea what is going on? Where does VC++ 2005 take the include directories take the output folder path from if not from .sln? Is CVS somehow interfering with the process? Anything else I could try out.
Thanks in advance.
Just to update the problem was resolved. The root cause is the .vcproj files were not getting checked in CVS!! This is where the individual project settings were stored(I was under the impression that this is done in .sln files).
I think the problem can be that after you have changed the settings in one build configuration (for example x86-Release) but forgotten to change them for another configuration (for example ia64-Debug), and when configuration changes, you have this problem.
Another thing that I would check on your place is project dependencies. If those are set in the right way VS will look for project output exactly where it is outputted, even when you change the output folder.
Do you have any binary files checked in as ASCII?
The round trip to and from CVS can corrupt binary files that are incorrectly marked as ASCII because CVS performs character processing on ASCII files (e.g. to give you the correct end of line codes for your OS). Corruption can occur even in an all Windows environment.
See the Binary section in the CVS FAQ for more information.
In my C# client application, I use XSLT to transform XML into HTML.
I would like to be able to edit these files in place, without having to recompile the entire solution. I'm having trouble working out how to set up Visual Studio 2008 to allow this.
The problem is that the XSLT files must get copied to the output directory somehow. Currently this happens during the build process. (My XSLT files are set to "copy if newer".) The build process can take a few minutes, which seems excessive for making small tweaks to the HTML.
I could make my XSLT edits in the output directory itself, but the output directory is not under source control. I have accidentally wiped out my quick edits several times by building my solution.
I'd like to reduce the cycle time for debugging XSLT, while keeping my XSLT files under source control and preventing accidental overwrites.
Summary of Responses: It appears that the most practical approach for solving this problem -- given that Visual Studio doesn't have a nice way of doing it out of the box -- is to create a separate project that contains the content files. These files get copied to the output location when the project gets built. That way I don't have to compile the whole solution, just the one project with all the static information like XSLT, CSS, images, etc.
Several folks suggested using sync or batch copy tools, but while this would work for me personally, setting it up for the other members of the team too would be a lot of extra work.
I am not entirely clear about your question, but you can instruct Visual Studio to copy the file from the solution to the output folder every time that you build.
Let me try to understand your scenario:
You have the XSLT files checked into source control along with your C# code. For example, if your project is in a folder called MyProj, then the XSLT files reside in MyProj/Templates
You want to be able to edit the xslt files in the Templates folder and submit those changes to source control just like you do with .cs or other files in your project.
You want a copy of your xslt files in the bin/Debug or bin/Release folder along with your executable.
If that is the case, add the XSLT files to your Visual Studio project. Then right click on them, open Properties, and set "Build Action" = "Content" and "Copy to Output Directory" = "Always". Whenever you build your project, the latest copy of the XSLT files will be placed in your bin/Debug or bin/Release directory.
One approach is to include a C# Preprocessor Directive to point my XSLT load function to the solution directory when in debug mode, but the output directory when doing a release build.
Something like:
string viewFolder = AppDomain.CurrentDomain.BaseDirectory;
#if DEBUG
// Move up from /bin/debug
viewFolder = viewFolder + #"..\..\";
#endif
But that feels like a hack.
Apparently you're managing two concerns in one project. The first concern is your business logic (instantiating an XSLT transform, calling it to transform some XML content, outputting the HTML result....). The second concern is the Transformation itself.
So why not create a separate project for your xslt sheets? "Building" this project would consist of copying the sheets to the output folder. Changing xslt will not influence the other project, hence reduce the build time.
Separation of Concerns at project level, that is :)
You can edit the file directly in the output folder.
On another note, a lot of people don't know that rich tools are built into VS to allow debugging xslts.
http://msdn.microsoft.com/en-us/library/ms255605(VS.80).aspx
One solution that might work for you is to setup a junction to your Templates in your output folder. This would allow you to use the XSLTs directly without copying them to the output folder. A good idea is to ensure (create) the junction as a build action.
Prerequisites:
NTFS
A tool to create junctions (e.g. junction)
Create a batch file that copies your xslt's from their source-controlled location to all your bin directories (bin/debug bin/release or whatever ones you have defined)
Add the batch file as an External Tool, optionally assigning a keystroke (or chord) to execute the batch file
Edit, run tool (I'd assign a keystroke to this to make this easy), then check your webpage.
Could you use a file synchronization program (e.g. Microsoft SyncToy "is a free application that synchronizes files and folders between locations") to copy the files? This would allow you to avoid the "copy on build" step because the files are automatically copied after saved. Also, if you edited them in the output directory, the changes could be copied back into your source controled directory. Not what the best real time sync program is for this scenario is, but that could be another question.
I have exactly the same issue. I have bought a program called ViceVersa (http://www.tgrmn.com/) in which I have setup sync profiles so that my css, layout and xslt folders are synced from my machine to my dev server as soon as any changes are made. If I make any code changes then I just publish as normal.
I understand this is an older post but I found a different solution to basically the same problem.
Visual Studio allows you to 'link' files.
Right click on the folder in the solution where you want the file link to be located.
Click
'Add'
'Existing Item..'
(select the file)
Go the 'Add' Drop down and select 'Add as Link'