I've a VS solution which contains two projects, one is c++ and other is GUI in c#. This c# project calls c++ project for calculations. When I'm running this on my machine its running fine in debug mode but when I'm trying to run it on machine without visual studio(debug build) its not able to get c++ dll, but if I build the solution in release mode and then try to run then it runs fine on both the machine. Can someone explain why is this happening ?
You are linking to the debug runtimes for the C++ project.
Either set it to release, or set the linker option to not use the debug runtime.
That is because Visual Studio ships with debug versions of the C runtime (msvcr100d for example) which are not present on machines without it.
Related
On my dev machine everything works fine. On my test machine I can't run my .exe because it says "Lib.dll or one of its dependencies was not found". However Lib.dll is in the same directory as the .exe and I ran CorFlags against both the DLL and the EXE: both of them report "PE32" so they are both 32 bit. The Lib.dll doesn't have any other dependencies. I removed all of them and tested. Why else might it be failing?
I used dependencywalker as someone suggested in the comments. Dependencywalker showed that I had a couple missing DLLs that I traced back to belonging to the Visual C++ 2012 Redistributable. So make sure you have the correct version of Visual C++ Redistributable installed on your testing/production machines. I also switched the project in Visual Studio from Debug to Release mode, a mistake I've also made in the past, so I won't be making that mistake again anytime soon. If you leave your project in Debug mode, the DLL dependencies are slightly different than if you put it into release mode. Visual C++ redistributable does not have the Debug DLLs present, only the Release ones - so even if you are testing, this change might be necessary unless you know where to find the Debug DLLs (which are installed with Visual Studio on your development machine).
I am trying to use this article project in to my WindowsForm application.
I am using visual studio 2010.
You can download and run test application at above link.
My problem is when I use list of below DLLs in my project.
Interop.Office.dll
Interop.VBIDE.dll
Interop.Word.dll
I have to change project configuration settings.
Configuration Manager (open from Solution configuration combo box near Run button) => Platform => to x86.
Why we should have to change platform to x86?
If I change platform to x86? Will project run on 64bit machine?
Please help me..
It's because your C# program's memory model must match that of any unmanaged DLLs that you want to call. Because the Microsoft Office DLLs are 32-bits, so must your program be.
It will still run fine on a 64 bit machine, though!
You will change to x86 because you use platform depended dlls.
Yes, it will run as WOW64.
I have a debug version of a .NET 4.0 application, I install the .NET 4.0 Framework in in this machine, however, I didn't install Microsoft Visual Studio.
Why I can only run Release version of application, but can't run the debug version of application?
I guess dlls in the debug version of application may refer to some dll of Visual Studio? Does anyone know exactly why?
A debug build is specifically for debugging your program. It includes some extra protections and hooks to allow you to step through and test your program. These require special debug runtimes that generally come with Visual Studio.
A release build strips all of this extra functionality, so all you need to run it is the .NET framework.
EDIT: After some more research, it does look like the debug builds should be roughly equivalent to the release builds. The main difference seems to be that the debug build creates a pdb file with the extra lookup info for the debugger, and may be a little less aggressive with optimizations.
I've been writing a program that serves in two primary parts- managed UI and native back-end (C# and C++). However, suddenly, Visual Studio thinks that when I try to run the solution, I'm tryng to run the native back-end (a DLL) and throws an error. When I start the exe manually, it won't break on my breakpoints, and suchlike - even though I've enabled mixed debugging. How can I set it back to the original settings- mixed mode debugging and start the managed .exe when launching? I'm in Visual Studio 2010.
I think that this is probably caused because I had a blue-screen in the middle yesterday, and this is the first serious work I've done on it since.
It sounds like you just need to set the managed project as the startup project in Visual Studio.
Open Solution Explorer
Right click on the project and select "Startup Project"
I use the x64 version of Windows 7. My application use some COM servers (usual native x86 COM Servers) that can't be loaded in x64 context. So I decided run it as a x86 application using WOW so I set platform target as x86.
But Visual Studio 2008 debugger started to show messages like "The source file is different...." for all source files when I try debug it. What is reason for this behaviour? This question was born there "The source file is different...." message in Visual Studio 2008 is result of debugging x32 apps on x64 Windows
Update: I cleaned solution, rebuilt solution, removed obj, bin and etc. folders, restarted computer, reinstalled Visual Studio... So, what else could be the problem?
Update2: If you create new Windows Application project and change target platform to x86 you will see this trouble. But if you delete Settings1.settings from project the trouble will be eliminated!!. Any Idea?
Update3: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/bc297668-65b4-46e8-969e-c7a6340d33b6
The error message you are getting is unrelated to debugging a WOW64 bit application. It's even less of an issue here because Visual Studio runs a 32 bit process inside of WOW64. So instead of x64 -> x86 you are actually doing an x86 -> x86 debugging session.
What's going on here is that Visual Studio is reading the checksum for the source files out of the PDB and it does not match the checksum of the files you are using to debug the application. The most likely causes for this are
Out of date PDB's
Using the incorrect source files. This is more common than you think in branching scenarios where you could easily grab the wrong version of the file.
The way I typically debug through this is
Close VS and manually delete all of the binaries and binary directories
Restart VS and rebuild
Close VS
Restart VS and attach to the running project without opening the solution
Then manually open the files
Windows 7 sets Windows Xp sp 3 compatibility mode for VS 2008 by default. Changing compatibility to Windows Vista SP2 mode have solved trouble.
You might also check the x86 build type. When you created it you may not of copied the settings from the default build and as such none of your code is building when you run your application.
Bring up the Solution Properties and check the Configuration Properties\Configuration page. Then make sure all of the projects are checked under Build for the Config/Platform combo you are using.