i'm pretty convinced that i've done that in older Versions of VS. But as sometimes mind tricks you, it could be possible that it is not possible at all:
I have a classLib (plugin) written in C# using Microsoft Visual Studio Professional 2022 ((64-bit) - Current Version 17.2.6). The Output dir is changed into a dir, in which the original Program is located, having a plugin dir. To debug, i've changed the Start action:
Start external programm
Path to program
working dir = path to outputdir
Using the browse feature always gives you an absolut path, you can change that to a relative path ( i know that and i'm doing it, this does not need to be an advice to me!). But sometimes, when changing something in config it overrides my relative path to an absolute again.
Is or was it possible to use something like $(OutDir)\external.exe (with or without backslash)? Any ideas?
no relevant informations below this point!
Why does this bothers me in first place ?
We are Working in a team of 6 developers and are replacing our runsettings so often that i'm quite annoyed...
Not everyone of use has the same directory structure 😪
It seems that paths like $(OutDir)\external.exe cannot be used in starting external programs.
You can try to add this in the .csproj file:
<StartAction>Program</StartAction>
<StartProgram>$(OutputPath)external.exe</StartProgram>
I did this:
I have solved the GL and GLUT part by installing NVidia CG toolkit. But, having continuous trouble with GLEW, GLFW, GL WTF W, etc.....
I want to install .h, .lib,and, .dll files related to GLUT, GLUI, GLEW, and, GLFW in such a location so that I don't need to pull my hairs every time I create a new project in Visual Studio 2003/2005/2008/2010/2012/20....... .
I am using 64 bit Windows-7.
But, others are bothering and confusing me every time I create a new project.
Create an empty project in which you will once setup once all necessary properties in:
C/C++ -> General -> Additional Include Directories
Linker -> General -> Additional Library Directories
Linker -> Input -> Additional Dependencies
All additional properties if any are required ...
Then, use File -> Export Template from the VS menu to export project template, so you can use it every time you are creating a new project. More information about project templates can be found here:
https://msdn.microsoft.com/library/xkh1wxd8(v=vs.100).aspx
EDIT:
Create an environment variable that will hold the path to your directory which contains the necessary libraries and headers (for example, GL_LIBS). Then, when setting up properties of the project to be exported, use this variable value instead an absolute path (for example: %GL_LIBS%\xyz_headers_dir). This way, if you want to change the location of the libraries, the only thing necessary is to change the environment variable and it will work. This is also helpful in situations when several team members work on the same project and don't want to keep these files in the same location.
One more thing, since "Export template" does not work on VS2010 or older, you will have to do additional steps. In case you are using VS2010, it is only a small issue since there is a VS extension which you can use to export project templates:
https://visualstudiogallery.msdn.microsoft.com/57320b20-34a2-42e4-b97e-e615c71aca24/
If you are using an even older version, then you will have to create a custom wizard which enables you to export a VC++ project template:
https://msdn.microsoft.com/en-IN/library/96xz4cw2(v=vs.90).aspx
I do not advise this at all, since if you want to build a project without these libraries, you'll still have them cluttering up your include paths. This can cause conflicts with other libraries if they happen to use the same include files as one of these. But if you insist...
Visual studio has default paths that every project gets. You can simply add the include and library paths of your choice to these paths. In older versions of Visual Studio, they live in Tools->Options->Projects and Solutions->VC++ Directories or something like that. In newer Visual Studio versions, they live in the VC++ Directories property page of the project/solutions property sheet.
I've got a TFS project with a NuGet package installed, and it references an assembly from that package. However, another copy of the same file is in a folder in the tree, and it is somehow overriding the reference and being used instead.
Even if I remove the reference entirely and manually point it to the correct path, the other file still is recognized and overrides the path.
Actual Case:
Correct Reference Path:
c:\Stratigen\Stratigen\packages\MonoGame.Binaries.3.2.0\build\net40\MonoGame.Framework.dll
Overriding Reference Path:
c:\Stratigen\Stratigen\Stratigen\Tools\MonoGame.Framework.dll
The file in "Tools" needs to be there because it is a build against SharpDX (API wrapper for DirectX) and is used to compile shaders for multiple versions of MonoGame, while the game should be running against the OpenGL version (unless I were to purposefully change something).
The especially odd thing about this is that I've had this file in the "Tools" folder this entire time, and for weeks never encountered this issue, yet now it's got this odd behavior.
It seems that having included the "Tools" directory in the project was to blame. This folder is already handled by TFS but since there are a few source files in there (for the shaders) I'd included the folder. However, this for some reason gave priority to the DLLs there over those from the packages. I'm going to re-add the source files but not the DLLs/EXEs from that folder and it should work fine then.
I am building an app for windows phone sdk 7.0 and 7.1, I want to have some extra features for 7.1, but I want to maintain only one code base for both, and only have some code appear if user's phone is 7.1.
I read about Shawn Wildermuth's post: http://wildermuth.com/2011/08/23/Maintaining_a_Project_with_Two_Windows_Phone_Versions. But I am not sure how to do "First off, I took my original project and created two solution folders and created the 7.1 projects as shown here" mentioned in the post.
Could someone help? or suggest other ideas?
Thank you.
The perfect solution is preprocessor directives
[Updated 11/5/2011: removed outdated information about the Marketplace. Thanks for the udpated info #johnforrest]
To do what Shawn is describing take your existing solution with your existing 7.0 project(s). Add a solution folder and name it "7.0". Move your existing 7.0 projects into that solution folder. Make another solution folder named "7.1". For each project in the 7.0 solution folder, create a new matching project in the 7.1 solution folder. These are Shawn's PhonyTools.7.1 and so on. Now follow his directions for populating the 7.1 projects with linked files that are linked from the 7.0 projects.
I find linked files to be a blessing and a curse. If you open the linked file in one project and edit it, Visual Studio does not alway know that the other project containing the linked file needs to be rebuilt. Lately, I've been finding that if I remember to then open the linked file in the other project I will get a warning that the file is opened in another project, but then VS recognizes that the file has changed and will rebuild the other project.
Preprocessor directives, as suggested by #KevinDTimm, don't solve the problem all by themselves, because you still need two different projects for the two different types of projects (7.0 and 7.1 apps or libraries). Additionally the different versions of the apps will reference different corresponding versions of assemblies.
Lastly, while we're on the topic of conditional compilation, don't forget the Conditional attribute, which is often a much better solution than using preprocessor directives. Bill Wagner gives a good description of the merits of the [Conditional] attribute in Effective C#, 2nd ed., item 4, p. 20. Enjoy!
I have been in this situation quite a few times where visual studio does not honor the Additional Include Directories when it comes to lib and header source files. For example, I just downloaded MyGUI source code and made sure the include directories were correct. I even put them to absolute paths, Visual Studio still complained that it could not find specific header files.
Does anybody experience the same thing with projects, and if so, is there a solution to this problem?Blockquote
EDIT: My apologies for not being able to explain fully. I know that the library and source files have different include directories. The project that I received had correct directory paths for the Additional Include Directories and Additional Library Directories but Visual Studio still failed to recognize them properly. I can right click and open the header file within Visual Studio but when compiling it still complains it cannot find the required header files. I regularly make projects relying on a framework I myself programmed, so I am quite familiar with how to set up dependencies. This is however the second time this seems to be happening. I don't recall which 3rd party project I was trying to compile last time, but Visual Studio simply refused to believe that the Additional Include Directories paths is where it should look for the header files. I am not sure how to give the complete details of this particular library (MyGUI) but I can point you to the website where you can download it to try and see if it is able to find the header files that are included in the project (if it doesn't compile, that is fine, and it is probably because of additional dependencies, but it should at least be able to find files in the common folder, especially when I put absolute paths in Additional Include Directories)
This happened to me once. It turned out the inconsistency of the Debug vs Release builds. When I modified one build, the other build was being compiled. Please set both builds with same include folders and see if it works. Good luck.
I've just spent some hours battling with failing #include paths in the compiler, inconsistencies between the compiler and intellisense.
What I finally discovered was that in the properties of the *.cpp file -- not the project, but the individual *.cpp file -- the "Additional Include Directories" property was blank. I had to explicitly set it to "inherit from from parent or project defaults" -- there's a checkbox near the lower-left corner of the dialog for editing the directory path.
I had copied this file from another project and used "Add > Existing Item..." to add it to the current project. My hypothesis was that maybe the "Existing Item" procedure skipped a property initialization step that "New Item" would normally perform. But I just tested that hypothesis by Adding another Existing and a New. Both of these files had their property set to inherit from the project, so I don't have an explanation for why my problem file was not initially set to inherit.
Anyway ... after much frustration, found and fixed that one.
I have found (stumbled) on the solution (I think). It has something to do with the character limit imposed by the OS. Although the limit should be 260, for me it falls in the below 150, see this discussion and links to it. I downloaded and unzipped the file to C:\Users\MyUserName\My Documents\Downloads\Downloads From Chrome\MyGui3.0...[and so on]. I learned quite some time ago not to try to compile projects under such long paths, but this time it completely slipped my mind as VS did not give me a warning at all and pointed me in the wrong direction. Anyway, cutting and pasting the project to D:\ fixed the issue. I am not going to checkmark the answer however until someone confirms this.
I have the same problem : Can't find .lib file even though I've added the additional include directory.
From an answer of Additional include directory in Visual studio 2015 doesn't work, I tried:
delete the .suo file and restart VS
Then it works for me.
I had this issue too. Just like sam said - this string value containing path to your framework includes has to be the same for the Debug and Release configurations. So the best way is to choose "Configuration:All Configurations" and "Platform:All Platforms" from the two context checklists on the top of the project properties window before typing it in, or copying from windows explorer adress bar.
Can you elaborate on this? If I recall, there are at least two places in Visual Studio where you can configure this:
Per-installation: Tools/Options/Projects and Solutions/VC++ Directories)
Per-project: Project/Properties/Configuration Properties/"C/C++"/General/Additional Include Directories
If you're adding the include directories per-project (#1), which I think you are, and then trying to include from another project, this will obviously not work. Try adding them at the per-installation level and see if it works.
Also, this may sound stupid/simplistic, but make sure the path is right (i.e. copy-paste into Explorer's path bar and see if the header files are in that folder).
If by lib files you mean library (.lib) files, the directory location is not specified through C/C++/General/Additional Include Directories but rather through Linker/General/Additional Library Directories.
It's logical if you think about it. C/C++ options are all compilation options, settings involved with compiling .cpp and .h files. Linker options are all linking options, settings involved with linking up .obj and .lib files.
I had the same symptoms in my c++ project. Navigating from header to header went fine, but after toggling to the source file of a header (let's say foo.cpp), then the navigation to an #include <bar.cpp> in that source file failed. I got the following error:
File 'bar.cpp' not found in the current source file's directory or in build system paths.
After research I noticed that the system build path given in the error where not extended with the include paths of the project. In other words: IntelliSense didn't know that the source file (foo.cpp) was part of the project, and therefore it didn't use the include paths of the project to search for the #include <bar.cpp>.
The fix for me was creating a file intelliSense.cpp (file name doesn't matter) that is part of the project, but excluded from the build. This file contains an include for each source file. ex:
#include <foo.cpp>
#include <bar.cpp>
...
This way IntelliSense knows that these source files are part of the project, and will therefore use the include paths of the project to resolve the #includes in those source files.
For me the issue was that .vcxproj Project file was read-only and after I added my directory to "Additional directories", the project file did not actually change. I was surprised that VS did not complain about this file being read-only.
So after I made that file write-able I could compile my project.
Here is another 'I had the same...' in vs2015.
For me it turned out that the active setting is also depending on the 'solution configuration' and 'solution platform'. That makes 4 settings which all should be identical.
That solved the problem in my case.
I realize this question is over 10 years old at this point, but I also just ran into this issue and none of the answers fit my scenario. After some playing with my IDE (VS 2019) for a few minutes I realized that the cpp file I was using had it's platform set to Win32, but the libs I was trying to use were built for x64.
As others have stated, make sure your project's configuration is set to
-"All Configurations" when you add the necessary paths to your project as that can also be an issue. I imagine my issue will not be as common, but I figured it was worth sharing. I hope this helps someone else in the future.
One more possible reason not mentioned earlier: make sure you are configuring properties of the correct project in a multi-project solution.
My problem was that I had a solution of two projects each using the same file with includes. Turns out that I correctly configured 'Additional Include Directories' only for one of two projects and totally forgot about another one. Of course error message was stating that only the second project and not the first one had problems.