Make VC++ Recompile All Files - visual-c++

I am writing a simple C++ application using the Visual Studio IDE and the VC++ compiler.
In this application I have an erroneous file that affects the other files as well. When I compile it, as expected I get errors. Now, if I remove all references to the file from my project, and then run it, the compiler will still exit in an error. In the compile message I then see the filename of the erroneous file. The only way to prevent this from occurring is by either removing all contents of that file, or remove the file, and then recompile it.
My guess is, because VC++ is 'smart' it saves compilations and when they are unaffected it doesn't recompile it. But because the erroneous file affects the other files, some compile errors (not all) simply stay.
Does anyone know how to disable such behaviour?

Can you show the errors ?
If the file contains actual functional code then fix the compilation errors ?
If the file does not contain functional code, then what is it doing in your project.
I expect this "erronous" file to be a header (.h) file that is included in other c++ files, so when it tries to compile the c++ files it will generate an error (or more) per c++ file.
If you just remove the file from the IDE project; the compiler will still include the file (because it still exists on disk); and will continue generating errors.
If you actually remove the file on disk, then you will have other types of errors.
In all cases, just fix the compilation errors.

To recompile all files you can rebuild all, or make a clean build.
Yes VC++ will save compilations if things have not changed, it will probably say up to date.
I don't think that you can disable it, but a clean build should be able to solve it. If that is the entire problem, also check how it is linking things, there you should be able to remove references to files.
The build should be under the build tab.

MSBuild and the Visual C++ compiler to an excellent job producing a correct binary when you make changes such as adding or removing a file. Chances are, even without a complete rebuild the compiled executable will be correct. If you are seeing unexpected behavior, it is most likely caused by one of the following things:
Check that Visual Studio is configured to build your project before running it. Check the following options under Tools → Options... → Projects and Solutions → Build and Run:
Before building: Save all changes
On run, when projects are out of date: "Prompt to build" or "Always build"
On run, when build or deployment errors occur: "Prompt to launch" or "Always launch"
If Visual Studio asks if you want to run an old version of your program, you may have introduced a compile error by removing the file, so the compiled binary will certainly be out-of-date until you correct it.
If your project contains a file that directly or indirectly #include "yourRemovedFile", then removing the file from the project may have no effect.
The Visual Studio Errors List reports issues independently from the compiler. You might be seeing old errors reported that are no longer relevant to your project but have not been cleared from the UI yet. In these cases, when you run your program you would still get the same results. You can also see if this is your problem by restarting Visual Studio and seeing if the error messages persist.

Related

Visual Studio gives an incorrect "fatal error LNK1107: invalid or corrupt file" for large static libraries in Release builds

In Release mode, Visual Studio 2015 is giving me an error about a corrupt static library file, while in Debug mode, it does not. I've carefully compared the settings of each mode, and do not find any differences that I think would cause this.
Here is the actual error:
C:\repositories\svn\code\Main\Libraries\WindowLib\x64\Release\WindowLib.lib : fatal error LNK1107: invalid or corrupt file: cannot read at 0x37F5C5C
Everything I have found on the web and SO seems to indicate that this error stems from accidentally linking to a .dll instead of a static lib, or that the .lib file is corrupt.
The file is definitely not a .dll - so all the questions/answers regarding that as a solution don't apply.
As for it being corrupt, I'm not sure why or how Visual Studio would create a corrupt static lib file. I've tried it on 2 different computers, multiple times, and the error is consistent. That doesn't seem to indicate a corrupt file.
Since this exact same setup used to work correctly, I'm leaning toward thinking that this has to do with the size of the static library file (which is just over 2 GB). However:
1) The static .lib file built in debug mode is larger (3.5 GB), and it links just fine.
2) I haven't seen any references to file size causing this type of
error (Visual Studio seems to report something more like "I can't
file this file" or "I can't open this file" when the files are too
large).
3) I've carefully implemented all the settings from the Visual Studio Debug mode in the Release mode that seemed to help with file size issues.
Just in case this helps anyone else...
This does indeed seem to be a bug in the x64 linker for Visual Studio 2015.
I changed my code to create 2 static library files instead of 1, where each was about half the size. After that, I ended up with two .lib files of about 1.2 GB each. I did not change any other settings for the Visual Studio projects.
The release version then linked fine, as the debug version had been doing all along.
I can't think of any explanation for why the debug version could link a 3.5 GB file, while the release version could not even link a 2.4 GB, other than a glitch in the linker code.

Extend Visual Studio functionality for Installshield ISPROJ Project type

InstallShield must be the crappiest "industry standard" application in existence, for reasons too numerous to enumerate here. However, one of those deficiencies is something I'd like to be able to fix, and with my first foray into writing an extension for Visual Studio (currently using 2015 version).
InstallShield has created a .isproj type, to allow integration with Visual Studio. This allows a developer to create an installer that references the output of a project as the files to include in the installer (rather than having to manually select individual files to include). This works well enough as long as the .isproj is being built in Visual Studio, and in a solution that references the project for which you need the output.
However, I also have an automated build for my installer projects, that we run on a build server using MSBuild. When attempting to build this way, we were getting completely opaque error messages indicating that the project output references above couldn't be resolved.
As with all InstallShield errors, Googling for answers turned up nothing except for multitudes of other people having the same problem. So I decided to dig into the plain text of the .isproj to see what I could find.
As it turns out, the .isproj type is a just a regular MSBuild script, and it even has lines commented out that explain options that can be added to the project; one of those things that can be added is an ItemGroup containing ProjectReference nodes. Manually adding the nodes helped solve the problem. Command-line build now works.
However, I am dissatisfied with a) having to manually type this stuff in, b) having no visual representation of what projects are being referenced, and c) not finding out about a problem until the build fails. So, I would like to be able to extend Visual Studio to help me with this. Here's what I'd like to do:
1) Add a "References" node to the project in Solution Explorer that acts like the References node for any normal .csproj.
2) Restrict the available References to other projects in the the current solution.
3) Visually represent a project with missing references (e.g. by underlining the project name with a colored squiggly, as with errors/warnings), and potentially failing the build if missing (depending on whether I want to treat it as an error or a warning; TBD).
To these ends, I've downloaded MPF for Projects - Visual Studio 2013, which provides an SDK for creating a new project type.
However, before digging too deeply, I need to know if it's even possible to EXTEND an existing project type, as described above, as I obviously don't have InstallShield source code. Also, any links or guidance as to a starting point for doing so would be greatly appreciated.

Cannot open include file 'rpcerr.h': No such file or directory

I was happily compiling and running source code today. Then I added a few lines to one of my modules, and suddenly Visual Studio 2012 refused to compile the code, with the error message:
error C1083: Cannot open include file: 'rpcerr.h': No such file or directory.
I'm not sure why the compiler suddenly needs to find rpcerr.h. I'm not doing anything I wasn't doing yesterday, but now I can't make the error go away.
I also have not been able to find rpcerr.h, myself. The reference is in rpc.h, which is part of the Visual Studio library. I'm guessing it got linked in because I included <windows.h>. But I don't know where I can find rpcerr.h, or what this file is supposed to do.
I would really like to go forward with this development. I'm guessing the code tried to compile rpcerr.h for a good reason, and that if I'm going to be using rpc.h for whatever reason this gets compiled into my source code, then I should get rpcerr.h as well. But trying to find it is sending me into a mobius loop.
Currently, the compiler is only complaining about rpcerr.h.
I'd better write this up, this is bound to happen again sooner or later. The <rpc.h> SDK file is stone cold old and dates back to the days that Microsoft supported writing code for an Apple Macintosh. It still supports it, there's an #include for rpcerr.h. But that file is no longer supplied, only rpcnterr.h is available.
You need to scan your source, or recently added #includes, for the a #define for MAC or _MAC, the one that Microsoft uses to select a Macintosh target. Using the editor's "Go To Definition" context menu command is the easiest way.
Or use this as a workaround:
#undef MAC
#undef _MAC
#include <rpc.h>
Or change the order of #includes. Beware that these workarounds might have side-effects, depending on how the other definition is used.

fatal error LNK1104

When I compile my code in visual studio c++ 2008 I get the following error:
fatal error LNK1104: cannot open file 'C:\Users\...\Documents\Visual Studio
2008\Projects\...\Debug\....exe
I just copied my code from another project in visual studio C++ and pasted it in this project again in VS C++. Can it cause this error?
This can happen because, for example, the executable is currently executing or opened by another program, or because you don't have the right permissions for that directory.
open TASK MANAGER and see if the process of the .exe is running in background even after closing it. if yes, then kill the process and then try to run it again.
This can happen if you have turned on preprocessor output, e.g. in Properties | C/C++ | Preprocessor | Preprocess to a File == YES. Creating a preprocessor output file (of file type .i) is mutually exclusive to creating an object file (of time .obj).
In my case it was caused by the "Incremental Linking" option of the projects (Visual Studio 2015). Maybe because the files were also dependencies of other projects from the same solution, not sure...
I had the same problem (I don't say that this is exactly your case, but still) and it was quite strange because when I changed the code a bit everything worked normally... And I just found out that my antivirus blocked the .exe file as a possible threat (idk, mb it didn't like how I worked with memory by my C++ program). So, the source of LNK1104 can also be the antivirus.

Strange Dependency Behavior in VS.NET 2005 (Unnecessary .CPP Compilation)

I work on a large Visual C++ (MFC) project in VS.NET 2005.
I have noticed strange behavior in Visual C++ 2005. Often, I will change one line of code in a .CPP file but many .CPP files will compile as a result of this. I have never seen this until VS.NET 2005. Theortically, changing a line of code in a .CPP file should simply require recompilation of that .CPP file and re-linking of the PE file.
What am I not understanding about the build process.
I found this link helpful when solving a similar problem, was under pressure at the time, I tried a few things and the issue went away, for the life of me I don't know (or can't remember) which - if any - helped.
Hope this helps
This is a strange bug in the VS2005 dependency behavior. To find out one suggestion would be to take the following steps:
Go to Tools -> Options ->
Projects and Solutions -> Build and
Run -> MSBuild Project Build output
Verbosity and select Detailed
Compile your project.
This will give you a detailed output of the build which "may" help you arrive at a solution to your problem.

Resources