We have a C++ 6.0 (stuck there for many reasons) application that uses COM heavily, and I have one of the COM servers (an EXE) that loads 5 or 6 DLLs. In attempting to debug this monstrosity, I get a pop-up on the first breakpoint that demands I "enter the path for vc60.pdb." The file is in both the source folder and the executable folder, but MS insists "A file with the correct name was found in this directory, but it is not the correct one."
I have verified the copy in both folders IS the copy that is created when the project is built, so I don't know where the "correct one" it is asking for is hiding. Of course, without this file, debugging is almost useless, as you can not view any symbols other than local integers, etc. Even custom classes defined within the project itself cannot be viewed.
Anyone know of (or if there is) a way around compiler stupidity?
Thanks in advance.
Related
I am writing a program in Visual Studio 2012. I am using Windows Imaging component I want to put image files for my program to use without them being resources. I want to make them download with the program when someone downloads it.
So my problem is if I specify the direct path in the program say:
C:\Users\Billy\Documents\Background.
How would I do that without having to specify Users\Billy\Documents. Since it will be different on others computers.
Call SHGetFolderPath to get any of the user-dependent path names. Then concatenate the file name to the retrieved path.
NOTE: This question is not about MFC/CRT DLL linking with/without .manifest file, avoiding manifest-lookup (i.e. force load from current path), VC redist installation and similar issues.
I have set of DLLs, which is used by different applications. These applications and the DLL have some product version (like 7.0, 8.0 etc). To summarize, let me use one DLL, and two applications.
App.exe depends on Core.DLL
GoodApp.exe also depends on Core.DLL
App.EXE of version 7.0 would need Core.DLL of version 7.0. Similary, GoodApp of version X, would need DLL of version X.
Since DLL is to be shared by different applications, I have put the DLL into some common path. This avoids DLL to be pasted on all paths. Some \SharedDLL path is setup for this. And (assume), I have set up PATH variable for this.
So, when any of application would load, OS will simply load the Core.DLL from this common path.
All fine. But what if App.exe is 64-bit/Debug, or other configuration? The common-DLL path cannot have all DLLs (32/64, Debug/Release). On the similar lines, App.exe of version Y, cannot use Core.DLL of version X (It is not that X>Y, or Y>X, but just that X!=Y, and App of X version cannot use DLL of version Y).
In short, App-32bit-Release-VersionX, would need exactly DLL-32bit-Release-VersionX, and nothing else! Since DLL name is same, I cannot put them into one common path. And since, there are dozens of applications (and DLLs too!) that depends on Core.DLL, I just don't want to waste space and time for copying the DLL into EXE's path.
Yes, I use post-build-setup to copy the DLL into all paths, appropriately. This solves time, but waste space. And if new application comes in, PBS must be modified to copy to that new path also.
Question is: How to utilizie the .manifest feature, used by Windows/MFC/CRT DLLs? They do utilize WinSxS folder for such thing.
Maybe this will help you:
How to: Embed a Manifest Inside a C/C++ Application,
Manifest Generation in Visual Studio
Working with Visual Studios C++ manifest files
Also follow the links in those pages
Error 2 error LNK1104: cannot open file 'OgreMain_d.lib' C:\Users\Owner\Documents\Code\C++\Test\ogrevcpp\ogrevcpp\LINK ogrevcpp
This is the error I get when trying to build an Ogre3D application (with steps followed from here).
I've followed everything to the T, yet I still get the error. It honestly shouldn't be happening. I've also followed everything from here.
Edit
What's happening is there are two different files, one is meant for release, the other is meant for debug. I need the one for debug mode to compile properly (which is OgreMain_d.lib).
Update
I figured out what the problem was - I was using the incorrect binaries; there was a few releases which were meant for Visual C++, and one which was meant for MinGW, along with a few other compilers. My apologies.
You need to check your library paths to make sure that the path where OgreMain_d.lib lives is part of the library path.
I guess the library for Debug mode is not present in the lib folder. Try putting two different libraries folder for each Assembly mode in Visual Studio. Go to ProjectProperties -> Configuration Properties -> Linker -> Additional Library Directories on Right hand. Make sure to check the Configuration Dropdown on the top.
I'm developing application for GNU/Linux using gcc 4 and cmake to manage compilation process. I found that is has no problems when there are two files with the same name but in other directory and namespace like this:
.
|-- gfx
| |-- Object.cpp
| `-- Object.h
`-- logic
|-- Object.cpp
`-- Object.h
First Object class is in Gfx namespace and second in Logic namespace.
Then I've tried to compile this project using Visual C++ 2008 Express Edition. Linker threw several errors about non-existing implementation of Gfx::Object class. After few checks I found out that:
Visual C++ is tracking two of Object.cpp files
When change occurs in first or second file the recompilation of Object unit is queued
It always recompile only the second Object.cpp regardless of which file was actually modified
I also found out that Visual C++ don't allow to create two classes with same name.
Is there a solution for this? I don't really want to refactor quite big part of code.
Both Object.cpp files will be compiled to Object.obj. Into the same directory. In other words, the last one that is compiled will overwrite the Object.obj of the first one. Yes, the linker isn't going to be thrilled by that, you'll get multiply defined symbols since it links the same Object.obj file twice.
The fix is easy, right-click one of the Object.cpp files, Properties, C/C++, Output Files. Change the Object File Name from $(IntDir)\ to, say, $(IntDir)\$(InputName)2.obj
The problem is that by default VC++2008 places all the object files into a single output folder, so the existence of the first object.obj file satisfies the dependency for the second so it is not compiled; and even if it were, it would overwrite the first one.
What you need to be able to do is make the intermediate directory setting dependent in the file being compiled. However I have tried setting it to $(InputDir) and various other combinations, but could not succeed in achieving a configuration that works, although it may be possible. The available macros are documented here.
Failing that you could use a "makefile" project, and manage the build with make, nmake, or cmake or whatever, since there is nothing fundamentally wrong with what you are doing (even if it is ill-advised), it is just that it is not easily supported by the IDE.
This has already been answered, but I also want to add Visual Studio 2010 will automatically put the two .obj files into different directories if there is a conflict, based on my experience with Beta 2.
EDIT: Uh oh, this is wrong! The real answer is that CMake was automatically doing this for me.
The accepted solution is not optimal because it does not scale.
In Visual Studio 2010, I set
Properties -> C/C++ -> Output Files -> Output File Name
to
V:\%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj
for OBJ files to end up next to the sources assuming the project lies on drive V (no idea whether there is a macro for it, yet).
Not optimal, either - but at least I can easily fork subsystems of many source files without getting tenosynovitis.
By the way: $(InputDir) refers to the solution/project directory and will cause the same problem in another directory.
I've got a really large project I made for myself and rece3ntly a client asked for their own version of it with some modifications. The project name was rather silly and my client wants the source so I figured it'd be best if I renamed all my files from
sillyname.h
sillyname.cpp
sillyname.dsp
etc..
Unfortunatly after I added everything back together I can't see any way to change the project name itself. Plus now I'm getting this error on compilation.
main.obj : error LNK2001: unresolved external symbol __imp__InitCommonControls#0
Debug/New_Name_Thats_not_so_silly.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
There has to be an easier way to change all this, right?
Here is a Step by Step on Steve Andrews' blog (he works on Visual Studio at Microsoft)
I haven't verified this, but I've done this a number of times and if my memory serves me right, you can actually use the search-and-replace functionality in VS2005 to rename all instances of the string "X" to "Y" in any type of file.
Then you need to close the solution and change the project (and any other file with the same name regardless of extension) file name(s).
You will obviously need to do a full rebuild afterwards.
I find it always annoying too, to do this manually.
So I tried some tools available by googling- two didn't work (VS C++ here), dunno, if they are more useful for C#.
The following tool worked good for me: I have used the trial version, but I will pay 39,- bucks for it. For me it is worth it. It has also a VS add-in. VS 2013 was not supported directly, at least not mentioned, yet, when I looked:
http://www.kinook.com/CopyWiz
In-place rename didn't work (access error), but "rename-while-copying" worked fine.
But I really wonder, if it is so difficult as some programmers claim. For most parts file renaming and a search&replace of all occurences in all text files in the project dir should be a quite easy and working approach. Maybe someone can contibute what shall be so difficult.
The rational part of my brain forbids the dreaming part to program an own tool- I am lucky ! :-)
You can simply rename the .vcproj or .dsp file and then either create a new workspace (sln dsw) and include the renamed project or simply chnage the name inside the sln file (it's just xml) I can't remember the format of the old workspace but it's still text.
You can either manually rename and reinclude all the .cpp of edit the project file and rename them in there.
sorry don't know of refactoring tool that will do all this but there probably is one.
I assume that in addition to the renamed set of files, you also still maintain a complete "parallel" set of the original files in some other directory, am I right?
Assuming you have both versions, what I would do is:
Get a file comparison tool like Beyond Compare or DiffMerge and compare the old SLN file and the new SLN file side-by-side. Also do this for each "proj" file and any other "config" type files.
It is possible to edit these files by hand. Usually looking at what is different between two copies will help illuminate what you should do to get the second one working.
You might as well start tinkering with the renamed project by hand, anyway, given that it already isn't working. You can't make it much worse. And: you might learn some handy tricks about the XML structure of these files.
Even if you do make small mistakes when hand-tweaking this files, I have repeatedly been very impressed by how Visual Studio handles things. Visual Studio will usually tell you exactly where you got it wrong.