I'm using a Makefile project in Visual Studio 2012 express just fine. However, regardless of the Build Command specified, Visual Studio always makes an 'obj' folder containing empty subfolders obj\Win32\Debug and obj\Win32\Release.
To reproduce the problem, simply create a "Visual C++ - General - Makefile Project" and use a DOS command like 'dir' in the Build Command Line. As soon as you build, the empty obj\Win32\Debug folder will show up.
I can simply skip these in my Mercurial ignore file but it'd be nice to find a fix. Anyone know how to make Visual Studio not generate these empty folders?
Found a trick: to set the intermediate output directory on an existing directory. I modified the project file by hand and added this:
<IntermediateOutputPath>$(ProjectDir)</IntermediateOutputPath>
inside the configuration PropertyGroup. I used the project directory, which obviously already exists. No more useless obj directory!
The obj folder represents VS' own metadata about your project for intellisense support and designer support (for WF/WPF apps). For the most part you can ignore the folder completely without issue.
On occasion though this data can become corrupt and cause VS to show invalid Intellisense options and the workflow/WPF designer can cause errors. Closing VS and deleting the obj folder will quickly resolve this though.
Related
In a directory where source code resides, there are also Visual Studio related files, like *.user, *.vcxproj. And Debug and Release folders.
I would like to change project directory layout so it looks like this:
For example, the project is named ProjectX.
In the ProjectX main folder, there would be only two subfolders:
ProjectX/Source
ProjectX/Build
In ProjectX/Source there would be all source code files, but nothing else.
In ProjectX/Build there would be all Visual Studio-related files.
How can I do it?
To move the vcxproj into the build directory, move the vcxproj into the build directory.
To move your source files under a source directory, move your source files under a source directory.
After either or both of the above steps, you'll need to re-add the files to Visual Studio, but I'm sure you knew that. Visual Studio isn't psychic and can't guess where your files are if you move everything around.
The SDF file can be moved by asking Stack Overflow how to move the SDF file: How to change ipch path in Visual Studio 2010
Visual Studio 2015 should not be creating .user files any more. Perhaps you're not fully updated?
At this point you have everything you wanted, even though it's weird. Except for portable projects, people aren't generally moving their vcxproj files. The vcxproj file is typically considered the root of the project, just like a makefile would be; under it is build and source.
Now let me give you advice. Don't do all of that. Do this instead:
Move your source files in a source directory. Now in Visual Studio, go to project properties and change Output Directory and Intermediate Directory to $(ProjectDir)Build\$(Platform)\$(Configuration)\
Now you have one Build directory instead of a Debug and Release directory. That means a lot to some people. It means more to people with more build configurations.
I had a solution/project that was going just fine until I made changes to locate the source in a different folder.
Everything compiles just fine but when I debug the Command Arguments and Working Directory are not correct. So I used Configuration Properties->Debugging and set them but when I click OK they always go back to the defaults. Even if I use Apply I can see the entries I made change to the defaults.
My only clue is that I restored my folder that contains the .sln and .vcproj files from a backup but I can't come up with an explanation for this behavior.
I'm using Visual Studio Express 2013.
Does anyone have any suggestions?
I'm using Bazaar and Visual Studio 2010 in a C# project. I have prepared an ignore list but still I think all the files in Solution Output directory could be ignored.
I search a lot but nobody had mentioned it. So I'm going to know if I can ignore this directory because output files are changing regularly and seems are not important for repository copy.
What do you suggest about this issue ?
In general, any file that is automatically generated by compiler or build tools should NOT be committed into source control. This includes object files, executables, generated resource files, symbols, etc. Committing those files does not serve any useful purpose. Also, sometimes there are configuration files which look like can be committed, but really should not if they only contain local user specific info - for Visual Studio there are *.user files.
By that logic, solution output folder should be always put into ignore list.
I have a (C++) project that I originally developed under Linux using make to build it. I would like to also have it run in Windows and am using Visual Studio 2005 to build it. The problem I'm running into is that Visual Studio places all objects into the same output directory. This doesn't work for me because I have source files with the same name in different sub-directories. This means that the last object (with the common name) overwrites all previous ones and thus I get link errors for the "missing" code.
Setting the output directory (even using the Visual Studio variables like $(InputDir)) at the project level doesn't work because Visual Studio passes all of the source files to cl.exe at once (i.e. $(InputDir) is evaluated once rather than for each input file). It appears that this problem can be solved by manually setting the output directory for each file (at a minimum, for the affected files), but this is less than optimal and error-prone.
Is there a better way to solve this problem? I would even appreciate it even if someone is able to suggest a way to get Visual Studio to compile files one-at-a-time so that setting the output directory at the project level would have the desired effect.
You might consider using different project for each directory or so. Otherwise, using the exactly same filename within a certain project might seem a bit strange. (Sort of a hierarchy within the project structure; something I've never seen before anyway.)
I have a visual studio solution that contains a project that builds a joystick handling library. Unfortunately, the output .lib file is placed in an unrelated folder on the drive. It is placed in another project. I noticed that $(TargetDir) is expanding to the unrelated project's path and not the current solutions path. How do I change this? I searched the visual studio project files for any matching path text and nothing turns up so I can't see how it is pointing to the wrong directory.
Ok, I screwed up. The project was pointing to the wrong directory (obviously) :-)