I use Visual Studio 2013 to make a CLR-compatible version of my C++ code library ('mylibrary.lib'). It's been working fine for years, but all of a sudden I'm getting 'LNK1104' errors because Visual Studio is looking for 'mylibrarymdd.lib'.
Why is it suddenly, magically tacking on 'mdd' to the library name instead of using the .lib file I specified? And how do I get it to stop doing this?
I've found two workarounds for this problem, but don't like either one of them. Hopefully someone is able to explain why these steps were unnecessary and then all of a sudden necessary.
The first and most obvious work-around is to modify the dependency's project settings so the target output filename matches what the consuming project is expecting -- namely, 'mylibrarymdd.lib'.
The second work-around is to use "/NODEFAULTLIB:mylibrarymdd.lib". This is required for every individual dependency with the auto-naming issue.
To get to the correct (IMHO) solution, one would need to know WHY Visual Studio is creating a "default library dependency" of 'mylibraryMDD.lib' in the first place. As I stated, it wasn't doing so before and there have been no recent updates to Visual Studio or the project files themselves.
I did find that there was a change to a dependency of 'mylibrary'. It pulls in the static OpenSSL libraries and those were updated. It's unclear how that would cause the above behavior, however.
When I go to debug my C++ project in Visual Studio, up pops a little warning dialogue box that tells me:
A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.
I'm having trouble understanding what this is even trying to tell me, let alone how to fix it. At first I thought it might be complaining that I'd accidentally duplicated a file in the directory, which I checked, and found nothing of the sort, which leaves me pretty stumped. I also tried excluding the file from the solution and adding it again, which didn't fix the problem either.
The warning doesn't appear to actually hinder the development of my project, but I suppose warnings exist for a reason, so if anyone knows what's gone wrong, any advice would be greatly appreciated. To my knowledge, I didn't change anything to cause the message to appear, it just popped up one time I went to debug the solution and has kept on appearing ever since.
Also, more copies of the same warning have started popping up, pertaining to other header files in my solution (I haven't recieved any about .cpp files yet, but it could be a coincidence, because it's only been going on for about 20 minutes).
Try removing breakpoints from the file in question.
This worked for me when it occurred with Visual Studio 2013 for a header file in debug build.
Source: Release mode file sync issue - current source code different from the version built
Additional notes: Clean / Rebuild also works, but that is painful for regularly changing code. Enabling the break point after starting debugger merely delays the message.
I solved it:
Close the window of the .h file in Visual Studio if it's open.
Close Visual Studio.
CUT the .h file from its normal location and paste it into a temporary folder that VS doesn't know about.
Restart VS and compile. It'll complain about the missing .h file. Good -- Make the bastard beg for it!
Paste the .h file back into its original location.
Compile. VS will gratefully accept the missing file. (Damn I hate Microsoft!)
This occurs if you rename an implementation file (*.c, *.cpp, etc.) to a header file.
This is because the Item Type still remains as C/C++ Source File, making it get compiled as a separate translation unit rather than as an actual header, preventing Visual Studio from recognizing its inclusion as a header elsewhere.
It took me quite a while to figure this out.
To fix this:
Right-click your header file in Solution Explorer and select Properties.
Select All Configurations, All Platforms.
Under General, change Item Type to C/C++ Header.
Press OK.
Force-recompile any file that #includes your header (or just Rebuild the solution).
The problem is that the debugger thinks that the checksum of the source file is different from what the compiler calculated and put in there. The debugger will then refuse to apply breakpoints in the files that mis-match, to prevent you from seeing data it can't guarantee is correct.
I have had this keep happening even after a clean rebuild. This is with VS 2015. My guess is perhaps the debugger and the compiler disagree on how to hash newlines or something like that? The fix is to turn off "require source files to exactly match the original version" in Debug -> Options -> Debugging -> General
Could you by any chance be debugging another executable (not the one actually built?). This is a common issue in scenarios where Visual Studio builds the binaries in one directory but then they are copied over to some other directory for debugging. I'd suggest you compare the target path under the debugging settings and the output directory under the general settings in Visual Studio.
This would explain the issue, since you are actually debugging some older version of the binary (not the one built currently) and thus the warning, since Visual Studio can't find the version of the source files for that version of the binary.
The reason may be circular header dependencies. datum.h may includes another_header.h (directly or indirectly), which includes datum.h.
I see the real reason of this question is not answered. So for someone still looking, here it goes...
The most common reason of this problem is that the source files used to build the existing obj files are different than the existing ones. In other words the
particular project did not build after new modifications to source. The solution to this problem is to rebuild the project after modifying.
This happened to me in situation where I had modified my static library projects files and then without building that project I started my application project which was using this static library project.
this worked for me:
close VS
delete *.vcxproj.filters file
restart VS
problem should be gone.
this worked for me:
clean project
debug/delete all breakpoints :)
This worked for me (as of March 2019):
Click the 'Build' drop-down menu in the top left of your Visual Studio window
Select 'Rebuild Solution'
I've changed the file name and it works now.
Just encountered this. In my case, one of my .h files contained implementation (a class with static methods), which was #included by one of my .cpp files, but the Project Settings were also telling Visual Studio to compile the .h file.
I manually edited both the .vcxproj and .vcxproj.filters project files, moving the .h file from the <ClCompile> ItemGroup to the <ClInclude> ItemGroup.
This did the trick for me; I never saw the "A copy of...is different from..." pop-up again.(Note that this was after I had thoroughly failed in attempts to get <DependentUpon> to work.)
My solutiion:
Build -> Configuration manager
Switch to another configuration (any, example Releas or Debug)
Switch to previous configuration
It is possible to have multiple projects, each with their own entry point within a solution. Make sure that the correct project is being run.
The source code is different message can appear in a project A's source when you are running project B. In this case, the message can mean This breakpoint won't be hit because you're running a project that doesn't include it
I am starting to learn DX11 and running into trouble with the effects framework. I know it was released as source and I have to build it, but the output from the build is not what I expected.
According to the research I've done on this question, the output from the build should be
D3DX11EffectsD.lib for debug
D3DX11Effects.lib for release
However, when I look into the 'Effects11\Debug' directory after building the project, I only see a file Effects11.lib (well, an Effects11 Object Library file which I assume is a .lib, I'm new to c++), and the exact same file in 'Effects11\Release'. Whats going on here? I've never used VS 2010 for c++ before now but I think I am building the solution correctly.
Is this a matter of renaming the files or have I done something wrong without realizing it? There really isn't much documentation on building and linking libraries in vs 2010 that I could find. Anybody have any suggestions?
Thanks
If you compiled exactly what you got off the web, then I think it would be just a naming convention problem.
You should try compiling it into your end application and see if it yells about debugging symbols missing.
You can also go into the build settings (it has been a while since I have used visual studio for anything other than C# so I don't know exactly where that menu option would be (I assume right clicking on the project should yield some useful results)...I generally do my C++ stuff on linux) and check to see what the built targets are for debug and release. If it turns out that the names are the same for both, but the build targets (i.e. the folder and a few other options, like including debugging symbols) are different then you should be good and it is just a naming problem.
Also, if the files are the exact same size it is likely that they are the same since the debug file should be at least a bit larger than the release one.
If it turns out that they are the same file, try re-downloading or re-extracting the source and just compiling the project again without any changes and see if that gets any results.
Greetings fellow programmers! I am trying to create a C++ library to use in other projects. This library is to be a static library that will be linked to other projects.
Problem: The compiler doesn't seem to catch errors that it otherwise would if it were configured as an executable program under Project->Properties>General. In fact I purposely made a syntax error and the compiler
gave me a success regardless.
Is there a way to force the compiler to check everything while building a static lib?
Build Environment: Visual Studio 2010
EDIT: As it turns out, it was a rather simple, yet incredibly subtle mistake. It turns out that Visual studio was treating some of my .cpp files as header files. Because of this, the compiler was not running through the code at all (no one includes .cpp files). When adding files to the library, I must have accidentally selected header instead of C++ file. I thought Visual Studio would only rename the header file. I guess I was wrong!
This is nonsensical. It cannot happen. What is probably happening is that you think that the compiler is compiling your source file, (the one with the syntax error,) but it does not. Perhaps you have not added your source file to your project.
(Then again, C++ has a pretty quirky syntax; I hope you are sure that what you made was in fact a syntax error, and not a syntactically valid language construct.)
If you have more than one project in the workspace (solution) like exe and lib, make sure you click on the exact one to build or set it as the startup project (showing up in bold letters) if you hit the F7 button.
I have an online repository with some .h and .cpp files that make up part of a project. I'm trying to check these out and use them in a new project, but am getting errors (C4627 and C1010). All the files have been added to the project (with Add>Existing Item...), and the subdirectories that contain these files have been added to the "Additional include directories" of the project.
Would I be better off having the entire project tree in the repository? My reason for not doing so is that my colleague and I are working on different parts of the code and so want to use different main methods to test things as we go, and I didn't see any need to be passing around any compiled code etc. since I assumed that given the .h and .cpp files (with the correct settings), visual studio would be able to compile the project.
What's the best way to make Visual Studio 2008 and TortoiseSVN work well together (without spending any money)?
Would I be better off having the entire project tree in the repository?
Most certainly yes. You should be able to check out and build without much effort. Creating a new project every time you want to build the source and having to configure it is way too much work.
My reason for not doing so is that my colleague and I are working on different parts of the code and so want to use different main methods to test things as we go, and I didn't see any need to be passing around any compiled code etc.
Ok, just put more than one project in the solution. There's no reason you can't have separate executable projects for separate tests.
I assumed that given the .h and .cpp files (with the correct settings), visual studio would be able to compile the project.
If all of the settings are the same, then, yes, it should compile fine, but why bother with the hassle when you don't have to?
Also AnkhSVN which isn't too bad and it's free. Also, lots of the windows it displays look like TFS (if you're familiar with it)
What's the best way to make Visual Studio 2008 and TortoiseSVN work well together (without spending any money)?
There are a bunch of programs that integrate SVN into Visual Studio. VisualSVN is one of them.
Apologies for the VisualSVN recommendation. We used to use it in an old project and I'm positive it was free then. Maybe they changed their license?