When I build solution in Visual Studio (2022), it generates an EXE (or DLL if I chose a class library) just as expected, except it also generates some files, like PDB, and some CS files. I know what most of them do, but if I am making a software, which consists of multiple of these files, I wouldn't want or like some people looking at the application directory and find source files and/or source code and solutions. This makes me come up with a question: Would deleting every single file except the compiled EXE or DLL impact their usability, or is there any other circumstance(s) to avoid creating these files, like SLN or PDB?
Thanks in advance :)
I have not tried anything, because, I simply don't know how to prevent VS from creating these files, except compiled files.
The .pdb files are outputs of your compilation. You can suppress them with:
<DebugSymbols>false</DebugSymbols>
The other files, like .cs and .sln are inputs to your project. Deleting them will mean you cannot build your program any more. I don't understand why you would want them to be deleted. If they're appearing in your output directory, check that you don't have "Copy local" (CopyToOutputDirectory) set on those items in your project.
I have a 20+ yo .dll, written in C that none of my colleagues want to touch. With good reason, it uses macros, macro constants and casting EVERYWHERE, making the symbol table quite lean.
Unfortunately, I have to sometimes debug this code and it drives me crazy that it doesn't use something as simple as enums which would put symbols in the .pdb file to make debugging just that little bit easier.
I would love to convert some of the #defines to enums, even if I don't change the variable types as yet, but there is a genuine fear that it will cause possible issues in terms of performance if it were to change the code generated.
I need to show definitively, that no compiled code changes will occur, but it would seem that the .dll is actually changing significantly in a 64 bit build. I looked at one of the function's disassembly code and it appears to be unaffected, but I need to show what is and is not changing in the binary to alleviate the fears of my colleagues as well as some of my own trepidation, plus the bewilderment as to why any changes would propagate to the .dll at all, though the .dlls are of the same size.
Does anyone have any idea how I could do this? I've tried to use dumpbin, but I'm not that familiar with it and am getting some mixed results, prolly because I'm not understanding the output as much as I like.
The way I did this was as follows:
Turn on /FAs switch for project.
Compile that project.
Move the object file directory (Release => Release-without-enums)
Change #defines to enums
Compile that project again.
Move the object file directory (Release => Release-with-enums)
From a bash command line. Use the command from the parent of the Release directory:
for a in Release-without-enum/*.asm; do
git diff --no-index --word-diff --color -U10000 $a "Release-with-enum/$(basename $a)";
done | less -R
The -U10000 is just so that I can see the entire file of each file. Remove it if you just want to see the changes.
This will list all of the modifications in the generated assembly code.
The changes found were as follows:
Symbol addresses were moved about for apparently no reason
Referencing __FILE__ seems to result in not getting a full path when using enums. Why this would translate to removing the full path when using enums is a mystery as the compiler flags have not changed.
Some symbols were renamed for apparently no reason.
Edit
2 and 3 seem to be caused by a corrupted .pdb error. This might be due to the files being used in multiple projects in the same solution. Rebuilding the entire solution fixed those 2 problems.
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.
I am migrating a complex mixed C++/.NET solution from VS2008 to VS2010.
The upgraded solution works in VS2010, but the build system is always refereshing one C++/CLI assembly. It doesn't recompile anything, but the linker touches the file. The causes a ripple effect downstream in the build as a whole bunch of dependent then get rebuilt.
Any ideas on how to find out why it thinks it needs to relink the file? I've turned on verbose build logging, but nothing stands out.
Turns out the problem was that the PDB filename was defined under both the compiler settings and the linker settings (with the same name).
This seemed to cause a problem in VS2010 as somehow an 'old' pdb from the intermediate directory (compiler output?) was being copied over the one in the output directory (linker output?). This resulted in the pdb in the output directory being older than some of the obj files and forcing the relink next time around (rinse and repeat).
Clearing the pdb name settings seemed to fix the problem, and the defaults were fine.
I'm just adding this for the record, in case anyone else gets this problem in the future.
We had a similar problem with a large, mixed FORTRAN/C++ project relinking whether or not anything had changed. It seems to have started when the solution was upgraded from VS2008 to 2010, although no-one could quite remember.
Eventually, I took a serious look at it (it was annoying, but not enough to do anything). By process of elimination, I have found the solution:
Remove any quotes in the "Additional Library Directories" of the top-level FORTRAN project (i.e. the one that makes the executable).
Now, I wouldn't believe this myself without evidence, so if you have the urge to reproduce this error yourself:
Open a new VS2010 session.
Create a new FORTRAN project that makes an executable.
Leave it empty, but link it to a non-inbuilt lib file (i.e. one of your own), and add your library's directory to the Additional Library Directories.
Check this compiles and links correctly.
Now try adding double quotes (") around the directory, and click on "Build" several times. If your session is like mine, then it will relink every time. When you remove the quotes, it stops.
This only appears to be a problem on the top-level project, and when those projects are FORTRAN - the quotes have no effect on C++ projects or those that create libs.
The relinking does not occur if VS does not need to search for libs (for example, if all of your libs are inbuilt, like kernel32.lib), but will occur whether or not your lib is in the directory which has quotes or a different one.
If anyone can justify this "feature", please let me know!
I'm having a problem compiling files in Visual Studio 2008 (Express edition).
I have two folders with an Entity.cpp file in them, they're both added to the solution but only the first is compiled.
If I change the name of either one of them it compiles correctly, but if both have the same name they're ignored. (Though changing included headers does make it try to recompile.. but it says no relevant changes are detected and linking errors still happen)
Thanks in advance!
The problem with Visual Studio is that Folders and Filters are not related.
You say that they are in different Folders (physically, on your disk), but are they in different Filters in your solution?
I don't remember having any problem of this kind, but I sure got kicked more than once because I had not put the file in the solution...