I have a question regarding VC++ 5.0.
For a dialog-based project I am writing, I have linked it to a particular dynamic link library called File32.dll by adding the corresponding .lib file to my project debug folder as you do.
I also linked to this library in the Project Settings. This library contains functions specific to a particular application which I need to access. All of the necessary header files have been included and the project builds without errors or warnings.
The problem is that once I try to debug and run the dialog, an error appears:
The program can't start because OUTPUT.dll is missing from your
computer.Try reinstalling the program to fix this problem.
OUTPUT.dll is a library I am not linking to for this project. And when I add this particular .dll to my debug folder, the same error appears with a different .dll (SYSINT32.dll).
No matter how much I add these dlls to my debug folder, the error message reappears with a new dll. Bare in mind, the project debugged and ran successfully before I linked to File32.lib. So I feel that the problem lies with File32.lib. Any ideas on what might be happening with the linker?
Use Dependency Walker to open your File32.dll. It will show all DLLs this one (statically) depends on. It will also highlight the missing ones.
As for VC++ 5.0 ... I feel the need to comment ...
Visual C++ 5.0, which included MFC 4.21 and was released 1997-04-28 (...)
that's an amazing 18 years :-)
Related
I am working on a C++/CLI project with VS 2012 in Dynamic Library (.dll) and x64 mode.
If I switch the mode to Static Library, I get the error below.
Error 1 error C1107: could not find assembly 'mscorlib.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable C:\Depot\Main\Current\Sln\ALibraryProject\Stdafx.cpp 1 1 ALibraryProject
I tried removing the reference to the mscorlib.dll then adding it again from:
Project > Properties > General > Common Properties
But that didn't help. As I know that VS handles the reference to the .NET assemblies, I don't want to add a disk file reference to it as it seems illogical! Did anybody face this before?
I had the same problem when converting my solution from the VS2010 compiler to VS2013 compiler.
I resolved it by changing the project settings (for the project containing the managed .cpp file that was throwing this error) as follows: In Project Settings | C/C++ | General | Additional #using Directories I added the macro $(FrameworkPathOverride). This resolves to the reference assembly directory for the version of .NET that you're targeting, which in my case is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1
If I switch the mode to Static Library
This is not the typical error you get when you try to build a static library with /clr in effect. I'd have to assume you've been tinkering with project settings to get rid of the inscrutable linker errors you get when you try to do this.
Core issue is that the C++/CLI build system doesn't support static libraries that contain MSIL. Managed code doesn't use a linker, binding happens at runtime. Which makes the essential difference between static libraries and DLLs disappear. So Microsoft decided to not support it because it didn't make much sense to implement it. Unfortunately they don't yell loud enough when you try to do it anyway, the linker errors you get don't give enough of a hint what you did wrong. Workarounds, like merging with ILMerge don't work either, it cannot deal with mixed-mode assemblies. Merging the native code sections and their associated relocation table entries is very untrivial.
Keep in mind that it is fine to link native static libraries. A typical C++/CLI project has only the ref class wrappers that need to be built with /clr in effect. You can glue any amount of native code from libraries into the final assembly.
I'm forced to theorize about the actual compile error, too many programmers get this error for another reason that doesn't have anything to do with building static libraries and they are harassing me in the comments.
Do beware that targeting a different version of .NET than the one you have installed on your machine is quite a hazardous affair, particularly so if you want to target 4.0 and you have 4.5.x installed. The key element in your .vcxproj file is the <TargetFrameworkVersion>. This will be missing if you started the project targeting an old .NET version, you have to insert it yourself. The IDE also doesn't support changing it if it is present, again edit by hand.
Which is enough to coax MSBuild into generating the proper compile command. You can verify if that panned-out well, look in the *.tlog subdirectory of the Debug build directory for your project. The cl.command.1.tlog file shows the options that were passed to the compiler. It should contain:
/AI"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
/FU"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib.dll"
Note the subdirectory, very important that it matches your intended .NET target. v4.0 in this example. And very, very important that it does not point to c:\windows\microsoft.net, the legacy location for reference assemblies.
I have the same problem. Having a dll doesn't work, as I need to provide a native C++ wrapper for a .net object so it can fulfil a natice c++ interface - I can't use .net in a dll interface - this gives a compile error
This worked as a static library in VS 2010 (with .net 4)
Some of my executables and dlls which also have some code with /clr. They don't have an issue. I'm not trying to make a net Lbirary.
I solved it by removing dependency in old and not updated mixed lib, which was also configured only in Debug configuration, and as result, it started to get the same error as yours after I changed some code.
It was not simple to find it, because error is not clear, and the dependency was set up via "Additional Dependencies" in project settings.
Open visual studio and unload your project then Go to the project folder and open file .vcxproj . Search for tag "targetFrameworkVersion"
(if not present it means ur project is not using dot net frameworks.so no requirement of change)
Change it to required version
Save the file.
And now reload the project .
I have a Visual C++ 6 project that is creating a COM DLL. This is an old project that I have not used in years but I came back to it recently to update some functionality of the DLL. The issue I am having is that when I try to manually register the DLL (using regsvr32) that is created by the project, I get no response whatsoever. It does not say it succeeds and it does not say it fails. I have verified that the DLL is not being added to the registry. I have never seen a situation with regsvr32 when it would not show any confirmation message.
Also, the DLL is set to self-register in the project and when it attempts to do this, it also does not show a message.
I have not touched this project in a long time, but the last time I did touch it, it worked without issue. Now I come back to it, and all of the sudden I am having this problem. It is as if the DLL being created by the Visual C++ project is not compatible with the current version of Windows. I have updated the development software to SP6 but it has not changed the situation.
I ran Depends on regsvr32 when it was pointing to the created DLL, and it shows this message:
LoadLibraryExW("C:\Source32\BIS\Projects\ALFA\DigiPixSvc\DigiPixObj\Debug\DigiPixObj", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned NULL. Error: The operating system cannot run %1 (182).
Can anyone please tell me why this is happening and what I can do to correct it?
Disclaimer: since I don't have VS 6.0 installed anymore, I'll have to use some Google searches to give you the exact steps for the VC 6.0 dialogs - so some of this information may be inaccurate. I believe it's correct - it's really what you'd do in the current IDE, just for VC 6.0.
Before you go through the trouble of debugging your DLL, make sure you run it through Dependency Walker to verify that all your dependencies are on your machine. Don't run Dependency Walker on regsvr32 - what matters is whether your DLL has its dependencies. If they're missing, regsvr32 won't be able to load the DLL.
To see if your DLL is getting loaded by regsvr32 when you try to register it, you need to debug through the DLLRegisterServer() function and see what happens there - this is one of the 4 entry points a COM DLL must have and regsvr32 calls this function when the DLL is about to be registered. In order to do this, you'll have to set regsvr32 as the startup program of your project and pass the full path to your debug-built DLL as a command-line parameter to regsvr32.
Bring up Project Properties for your project.
Go to the Debug tab.
Make sure the General category is selected.
Enter the full path to regsvr32 in the Executable for debug session textbox.
Enter the full path to the debug version of your DLL in the Program arguments textbox. Make sure you have a PDB file for your DLL so you can see symbol information during debugging.
Put a breakpoint on the first line in DLLRegisterServer(). The code in this function may be long or short, depending on how it was created: generated by a wizard, written by a developer, etc.
Start debugging.
Your breakpoint should be hit and you should be able to step through the registration code and see at which point it fails.
I have run into this problem, which although is a warning, I suspect is a sign of something wrong under the hood. When I build in release mode I get this warning:
MSVCRT.lib(cinitexe.obj) : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
I'm building a dynamic DLL in Visual Studio C++ Express Edition. When I do it in debug mode no warning arises. I've googled a bit and it looks like msvcrt and msvcrtd are both for multithreading, one for debugging and the other not. I could use /NODEFAULTLIB with MSVCRT.lib, but I don't think that avoiding symptoms really helps with the problem.
I really don't know if this is a huge problem. The DLL and .lib files are generated correctly.
Check that your runtime library settings are correct in the Release configuration of your project. Basically it should be the same as your Debug build, but without the word 'Debug' in the description. Visual Studio docs on this issue are here.
Check your settings as follows:
in Solution Explorer right click the Project and select Properties
make sure the Configuration (at the top of the Properties window) is Active (Release)
go to Configuration Properties -> C/C++ -> Code Generation
check that Runtime Library for Release is not a Debug version of the CRT.
The problem is related to your libraries.
They are linked differently than your program.
Your program may be single-threaded, while your libraries may be linked as multithreaded, for example.
Look under
Project Properties
Configuration Properties
C/C++
Code Generation
Runtime Library
to see the setting (e.g. "Multi-threaded Debug DLL (/MDd)").
This is a huge problem, since it can lead to many unexpected crashes of your application, AND you can't distribute an application which links msvcrtd.lib, since you are not allowed to distribute the debug C++ runtimes of Visual Studio.
Though /NODEFAULTLIB should fix those, you should fix the issue itself.
Like casablanca said, msvcrtd.lib is linked in release mode, but it should only be linked in debug mode.
This does not mean that your own application has wrong linker settings. Any of the libraries you use in your project could have incorrect settings as well.
What I usually do to fix this is, to open all the release .lib files which your application links, with a text editor which can open such large binary files (like SciTE), and then I search them for e.g. VC80.DebugCRT (VC80 == Visual Studio 2005 in this case), and if I find this string in one of those libraries, that library should be recompiled with /MD.
If you are linking dynamic libraries, you can use a tool called Dependency Walker on the .dll files instead of manually searching the .lib files.
If Dependency Walker shows the dependency on one of the debug crt DLL files like e.g. MSVCP80D.dll (note the trailing D), recompile that library using /MD.
Unfortunately this is going to be a pretty open-ended question, but I am at my wit's ends and I thought I would reach out for some advice.
This is a Visual C++ MFC app using Visual Studio 2008 SP1.
A coworker and I both had Office 2007 installed and we have both had strange DLL loading problems with our app since. Specifically, LoadLibrary is failing to load one our DLLs ( the first one it loads ) and returning error code 126 ( module not found ). What's really strange is that if I just run the executable from the windows explorer it works fine.
I took the usual steps to diagnose the problems:
Verify that the file existed and that the current working directory was pointed at it.
Run dependency walker and verify that it's dependencies are loading correctly. They are all loading ok except the ones this question says are ok to fail.
Experiment with loading some different DLLs at the same location in the code. Some of the simple 'stub' dlls succeed, but most of them fail.
Experiment with loading the DLLs that are failing from separate test apps - in an empty console app and a barebone MFC app, all the DLLs are loading fine!
Try to load the DLLs with LoadLibraryEx and the LOAD_LIBRARY_AS_DATAFILE flag, which does succeed but doesn't get us very far except to point out it's probably a dependency problem.
I really don't know what else to do at this point. Like I said, Office 2007 is a common thread in our problem but I don't know what kind of problems it could create. I really don't know even what steps to take next. Any ideas?
edit: I'm pretty sure the current working directory is not in the DLL path for some reason. It seems the DLLs that are failing are ones that need any other DLLs. If I turn on Loader Snaps debug output the current working directory does not appear to be in the DLL loading path. Any idea what could cause this?
edit2: The current build dumped the executable into a directory other than the working directory. For some reason, when I tried to load a DLL which then tried to load ANOTHER DLL, the current working directory is no longer searched. By putting the executable into the directory with all of the DLLs I am trying to load, the problems go away. Based on all of this, and the output by loader snaps, I am 98% sure this is some bizarre Visual Studio bug and I will simply have to work around it.
Office 2007 turns on SafeDllSearchMode in the registry.
http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx
With SafeDlLSearchMode, the current directory is no longer searched. To disable it, they claim you can go into regedit and set HKLM/System/CurrentControlSet/Control/SessionManager/SafeDllSearchMode to 0, but this did not work for me. Calling SetDllDirectory to the current directory DID work for me, although this only works if you are targeting XP SP1+.
The reason this caused problems in my specific app is that when we run the executable from the debugger, we keep the executable in a different directory than the current directory with all the other build files. When we run outside of Visual Studio, we first copy the executable into the directory with all of the other DLLs. The directory that the original executable is called from is ALWAYS in the search path, so if you keep your executable and your dlls together, you would never run into this problem.
Still, it's quite confusing for Microsoft to change the dll search path under us like this.
Does the DLL which fails has MSVCRT80 in dependencies? If yes, the most likely reason is that Office 2007 has overridden MSVCR80.dll
We have an installer application.
In that we have one dll related to our application.
We created setup with all respective files.
We used "Install Shield 6.3" and created a setup file.
After created build. The build is working in xp, not working in 2000.
It is showing error message as Couldn't load .dll only in win2000.
What could be the issue any idea?
Regards
Hara
It looks like one of the system/third party dll you are loading is either not available or of wrong version. Use a tool like dependency walker to check whether all the required dlls are available or not.
You have probbely missing prequsits that exits on XP but not on Win2000.
You need to run the Dependency Walker tool on Win2000 and load the problematic DLL, the tool will tell what is missing.
Try running installation with Filemon in the background, filtering with the missing DLL's name. Then, see where the DLL is searched for, and fix the problem. Hard to say without any further information, but first difference I have in mind is that the system folder in XP is C:\windows\system32, while in win2000 it is C:\winnt\system32. If you've hardcoded the system path for any reason, it might be the problem.