What is the difference of the working directory vs the output path in visual studio?
Is it bad to set both setting to the same directory like '....\bin\'
By default they are the same. Assuming you're debugging some application it will be bin\debug.
Output Directory is where your output files goes. By default, Visual Studio builds each project in a solution in its own folder inside the solution. You can change the build output paths of your projects to force all outputs to be placed in the same folder
Working Directory is the location which Specifies the working directory of the program being debugged. It is the default place in which a program is looking up it's files. Normally the working directory is the directory the application is launched from \bin\debug by default.
So every opened file will be opened relative to the working folder.Let's say if you have an application installed in c:\myapp with all lib files in the same directory then you will set your working directory to myapp folder and you can do so from project properties.
By default, working directory is the output directory. Both can be changed, you can set another directory or common directory for all projects for output directory that determines a relative path for the output file that might be an executable or a static library.
Working directory also provides a relative path to put files that are used by the program. You can put a log file into a place that you can use its directory as a relative path in the code instead of absolute path. If your working directory is myproject\src and your log file is in myproject\src\log\log.txt then you can open or write the log file with log\log.txt in the code rather than c:\blabla\myproject\src\log\log.txt.
Related
I am trying to understand how Visual Studio treats paths when they are being run from inside the IDE vs manually opening the executable file from bin. I have two projects that are linked together:
/demos
/basic-triangle
/src/...
/engine
/src/...
/workspace
/MyEngine.sln
/engine
/bin/Debug/assets
/bin/Debug/engine.lib
/engine.vcxproj
/demos/basic-triangle
/bin/Debug/basic-triangle.exe
/basic-triangle.vcsproj
-> references engine.vsxproj
So, in basic-triangle application, I have set up the following path:
Engine::setAssetsPath(
std::filesystem::path("../../../../engine/bin/Debug/assets").string());
This resolves to /engine/bin/Debug/assets, which looks like the path is counted from bin directory instead of bin/Debug directory. However, when I open the executable, the path is calculated from bin/Debug. How can I normalize this so Visual Studio uses the same current working directory as opening the executable file.
I have set up a hosted mac os preview build for a Xamarin app. All the steps complete except for 'deploy ipa' The publish artifact says nothing will be added. Here is are the settings from the copy files to as well as the output
Seems you set the incorrect Source Folder or Contents pattern in Copy Files step. That caused no files were copied to target folder for publishing.
Please check the logs of Copy Files step to see if the *.ipa files are really copied to $(build.artifactstagingdirectory).
If no files copied, then just check the build logs to get the real working directory (Source Folder in copy step) and make sure the *.ipa files are generated in the directory. (By default it's $(system.defaultworkingdirectory) on my side.)
If the real working directory is just the Source Folder $(Build.SourcesDirectory) you specified in Copy step, then the problem should be the contents pattern.
Contents specify minimatch pattern filters (one on each line) that you
want to apply to the list of files to be copied. For example:
** copies all files in the root folder.
**\ * copies all files in the root folder and all files in all sub-folders.
**\ bin copies files in any sub-folder named bin.
For my project, I am using Visual Studio 2015. I have added to my include path the folder $(ProjectDir)Source. In details view of Include Directories, in the list below with Evaluated value, the correct path is listed. When I copy this path using #include "path/file", it finds the file. Or via Start > Run, it opens the path.
In my project I have a .cpp file which includes the file like usual:
#include <file>.
Still, I am receiving the error: Cannot open include file 'file.h' No such file or directory. Error C1083.
I copied an existing solution which had similar includes and adjusted them accordingly. It works now.
The default value of working directory in visual studio property sheet is $(ProjectDir). If we have some dependencies (e.g., config files or libs & dlls), we have to put them in the working directory.
Since the default $(ProjectDir) is different from the output directory (namely $(TargetDir), folder where the EXE file resides), we have to copy the dependencies to the output directory if we run the EXE file by double clicking it.
So I'd like to change my working directory to $(TargetDir), in case I have to copy my dependencies twice. The question is: Why is the default working directory set to $(ProjectDir) but not $(TargetDir)? Is there any good reason for visual studio to do so?
My Visual Studio 2013 Custom Build Tool step is failing because the directory in which the step is being executed is not the directory where the project file is (which was by default the case up until recently). I can patch it by adding a cd command to the start of the step to change to the project directory but I was wondering if anyone could tell me
how this directory path is set
how to change it.
The build always assumes the project directory as 'base' directory.
This gives msbuild a set location (Builds to bin\debug is a subfolder off 'Base', reference hint paths and a lot more besides).
I would just change the execute of your tool to be reference based (i.e ....\tool.exe or similar) or make use of the path environment variables ($(OutDir),$(TargetPath),$(ProjectPath),$(TargetDir) etc).
Another option that I make use of is to have a batch file called 'post.bat' that has the necessary steps to execute a custom tool. This is then placed in the project folder and added to the project as an artefact.
Without knowing exactly where your custom tool resides relative to the project (or solution) or what the 'working directory' requirements of the custom tool are I cannot suggest more.