I have C# VS 2010 project which uses Shell32.dll. Shell32.dll is used for creating zip file.
The machine is Win7 64-bit. The projects compile and runs fine when .net target version is 2.0 or 3.5.
However changing it to 4.0 results in compilation failure. I tried by removing & adding refernce to Shell32.dll again and changing the target platform as X86. But still failed to compile.
Looking for reason & resolution.
Update: I tried creating new project and added reference to Shell32.dll. This time I refered the dll from C:\Windows\SysWOW64 insted of C:\Windows\System32. Now this time it compiled fine. But I am not sure if this project will run on 32-bit windows and XP and other versions.
What do you mean by adding a reference to shell32? That is a native dll, you can't directly reference it from a C# project, you would use pInvoke to call methods it exports but you don't need a reference in your project.
Ryan
Related
I just built the project that I'm supposed to fix. I double checked that correct DLLs are loaded - the project uses Qt 5.3.0, and the dlls are loaded from 5.3.0 directory. I am not sure where is the problem. Is my project using incorrect Qt headers? Or is the DLL build incorrectly?
I'm building in Debug with Visual Studio 2017. The DLLs are also built with visual studio. I tried Vidual Studio 2010 instead, since it's 2010 project, but the error was the same.
Are you in release or debug mode? QtCoded.dll is related to debug profile.
Another explanation could be how your Qt was built.
If I remember correctly Qt was built with msvc2015 so you have to use msvc2015 to build your exe with Visual Studio and it is not possible to use a msvc version before or after that.
Please remeber that you can't use the Qt framework built with mingw with msvc.
In other words I suggest you to check which version of msvc are you using with Visual Studio and which version of Qt framework.
Regards.
In my case, the problem was following:
One of the sub-projects was accidentally configured to use Qt 5.6.1, whereas the rest of the solution used 5.3.0. I found out by opening the result binary in dependency walker.
I just had the same problem with QT 4.
The solution was found on this post: The procedure entry point could not be found
I ran into the same problem, and in my case, this was due to the fact that I had two versions of the same library installed on my computer.
In the end, the problem was that I was linking my program against the new LIB file while my PATH was pointing to the old DLL. When the library version number is not included in the LIB or DLL file names, it is very easy to mix the versions.
I my case I was using a QtCored4.dll and others from an older version of QT. The solution was copy the DLLs directly from my QT installation directory which was used to build the application (as it was set by my QTDIR environment variable): C:\Qt\4.8.7\bin to my application directory.
The desktop software (.Net 4.0, compiled under Visual Studio 2010, target: x86) I'm developing is shipping with System.Data.SQLite (1.0.86 for x86, from system.data.sqlite.org*) for the first time.
On the development machine (And every other machine where the System.Data.SQLite-installer has run), everything works correctly.
On the testing machine however, after installation (a standard MSI setup created with the Visual Studio Installer) launching the application and showing the splash screen, before showing the GUI, the application creates an exception with the error:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Data.SQLite.dll' or one of its dependencies.
The mentioned file itself is found in the application directory (correct version), along with all the other referenced DLLs.
I assume this works on the development machines because of the setup option 'Install images'. I didn't install SQLite in the GAC. The application project is directly referencing the pre-build System.Data.SQLite.dll with local copy set to true.
Are there any dependencies I'm not seeing?
Or is it a missing Microsoft Visual C++ Runtime Library (Not present in the application directory)?
Or a missing SQLite.Interop.DLL (Not present in the application directory)?
How could I fix those?
= The installer I've used: http://system.data.sqlite.org/downloads/1.0.86.0/sqlite-netFx40-setup-bundle-x86-2010-1.0.86.0.exe
Ensure that you have the latest Microsoft Visual C++ 2010 Redistributable Package installed.
http://www.microsoft.com/en-gb/download/details.aspx?id=5555
Why? The sqlite DLL has some unmanaged code embedded in it that is run directly from the assembly at runtime. This manifested for me as a bad image format exception but you never know!
I have a web application developed under Visual Studio 2005. I have a dll (home made) that I need to add as a reference to my project. I do "Add reference", the dll is added to the Bin folder but It's not added to the list of the references ! So the project doesn't compile. Could you please tell why the dll is added to the Bin folder but it's not added to the list of references of the project? Many thanks !
Walloud
If your "home created" assembly targets a framework newer than .NET 2.0, you won't be able to add a reference to it in a .NET 2.0 project in Visual Studio 2005.
Make sure your project for the DLL you created targets .NET 2.0, and not a newer framework, such as 3.5 or 4.0.
Since VS 2005 didn't know about the newer frameworks, you don't get proper error messages about this (from what I recall, though I no longer have a copy to test), which is likely why you're confused.
The problem is resolved. I was working on an XP virtual machine and it appears that there is some issue with it. When I used a real XP machine it worked !
I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.
According to Li Shao's (of Microsoft) 2009 blog entry:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.
This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?
HELP!
Have a look at Daffodil: http://daffodil.codeplex.com/
After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.
I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.
When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.
Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?
I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html