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.
Related
During installation I get "The feature you are trying to use is on a network resource that is unavailable" and prompt to specify some path to vc_runtimeMinimum_x64.msi. After providing some path to required file I get error states that this file doesn't match required version Minimum Runtime 14.14.26405.
I finally found the solution reading this question: Install vcredist_x64 with VS2017 installer project
I realized that specific VC_Redist.x64.exe files could be downloaded by links like https://aka.ms/vs/15/release/26405.00/VC_Redist.x64.exe, where 26405.00 is exactly the version I was required to fix. Note, that you need version from error text after clicking OK, not from window title.
And the last point is that this exe must be executed from cmd with argument /repair to help me with this issue. Regular execution by double click made no effect.
I found the solution elsewhere. It said to
Fix problems that block programs from being installed or removed
https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
download troubleshooter button on the link.
Run it - choose option - have problem with installing - it lists programs - choose the missing / problematic visual c++ runtimes in the list
it will run and get fixed.
Repeat for each visual c++ you having problems with. I ran the program multiple times.
I have to thank this comment section for helping me with this problem, since I have not been able to work more efficently with my school, since I din't know what and if a single file somewhere deep down in the computer had to be deleted for this program to work.
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.
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.
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.
The Visual Studio 2012 Professional Edition installed on my PC keeps on showing in error list
"csc.exe" exited with code 1 in Visual Studio 2012
instead of the actual error (e.g. syntax error).
How can I fix this?
I turned on detailed logging in Tools -> Options ... -> Projects and Solutions -> Build and Run.
When you rebuild your solution, you can see the command that gives the error. Copy the command, open a cmd window, go to your project folder, paste and run the command. The output will give you the actual error.
It's some sort of bug in VS2012 I suppose. You could try cleaning your solution, restart Visual Studio and try rebuilding? The above solution should point you in the right direction for finding your error. When opening the file containing the error, the errors should appear in the error list.
This happened to me because I enabled the "treat warnings as error" switch in my project settings and had an unused class member in some file.
I agree that the output window's message is misleading and should be replaced by some message that shows which member cause the build to fail.
Maybe my unswer is too late, but I want to say, that such error could also happen if you copy that project from another solution. That project was sign with .snk file and you added it to TFS (for ex). VS does not upload .snk by default and when you will use your code in the other place, you will not have that file, but in AssemblyInfo.cs there will be mention that your project contains that file. So, c2c2.exe will not build your solution because of this. Quick solution will be just to commnet this line
[assembly: AssemblyKeyFile( #"....\sn.snk" )]
in AssemblyInfo.cs
I had the same issue.
I tried cleaning the solution, deleting the bin/obj folders, repaired visual studio 2013, dump out detailed build info, nothing helped, CSC still exited with error code 1, no more info than that.
In the end it was caused by two variables (a double and double[]) with the same name in the same code block. Strange error to cause it.
If this happened to a project that was working before, verify no devenv.exe is running after closing VS:
-Close all the instances of VS
-Open the task manager
-Verify all the devenv.exe actually get closed, or kill the processes
For me, I still had 3 devenv.exe working; I ended these processes, started VS again, and it worked correctly.