I'm developing an Add-in for PowerPoint 2010.
If I try to build it with plataform target Any CPU or x64 I get HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)
My solution uses a hardware dll provided in a SDK and one of its libraries .
I have already registered it with regsvr32.
I had similar problems before and always solved with regsvr32 but now it does not work.
I can avoid this problem building in x86 but when I try to run debug or release build in x86 I get the given assembly name or codebase was invalid. HRESULT: 0x80131047
I don't know what to do.
Thanks
Related
I have not enough knowledge on how to fix this. What I do know is:
Build a Executable in Visual Studio 2010 on Windows 8.1 (hence the 1-2-0.dll)
Running the executable, crashes on Windows Vista with the message: "This application could not be started, because of the api-ms-win-core-libraryloader-l1-2-0.dll"
Under vista you would have the libraryloader 1-1-0 if not mistaken?
this library is linked from mscorlib.dll somehow? But not referencing this dll would not build the project.
Maybe someone could direct me in correct way? Or better have a solution for this?
Is there a way to tell VS to not use this latest dll version?
I am certain I did not reference this specific DLL.
I got the same problem, in my case I was providing the d3d9.dll and d3d11.dll, that I copied from windows 8.1 windows instalation directory and ofc. I cant use those!
And then all Computers like Vista, Windows 7 and even Windows 8 had that Error:
"This application could not be started, because of the api-ms-win-core-libraryloader-l1-2-0.dll"
Because this file:
api-ms-win-core-libraryloader-l1-2-0.dll belongs to Windows 8.1
Solution?
In my instaler, Installshield, I removed the d3d9.dll and d3d11.dll, so my aplication will use the ones already in OS.
The problem was not in the "EXE" produced by Visual Studio, but in DLL dependecies that I was providing.
this problem occurred due to Compatibility with older operating systems.
this link may help you
http://msdn.microsoft.com/en-us/library/hh802935(v=vs.85).aspx
I googled a lot but no answer found. My project is a plugin of a .Net application.
The project was started 2 years ago on WinXp 32bit platform. A 32bit COM component was used for some reasons. Because I have the source codes, I can debug into the COM component freely. Everything is fantastic at that time.
At the beginning of this year, my project is upgrading to x64 because of memory benefit. And the x64 version of the COM component is also ready. Everything works fine except debugging.
Now I can't debug into the COM dlls anymore. There is no any COM dll or interop dll listed in the Debug\Windows\Modules window. Thus, I can't specify the symbol directory for dll.
I know there is no mix mode support for debugging. So When I attach the exe, I select "Native".
I tried VS 2005, VS 2008 and VS 2010, all of them give me the same issue. Then I thought may be it is because x64. So I use the old 32 bit code which was debugged fine on WinXP to try again. But I still can't debug either.
Any idea? Is this because of the win7 platform? Or if I need to add some entries in the exe's config file?
Thanks in advance.
Perhaps, I should ask in this way:
What are the rules for the debugger to decide which module should be in the module list? If you compare the module list between ProcessExplorer and VS, you would find these two are not the same.
I have a problem running my application on other machines.
I am developing with Visual Studio 2008 in a Win7 x64 machine.
The solution contains several C# projects (the main application is written in C#, all others are library projects) and two c++/CLI libraries. The C++ libraries are Win32 and all C# projects are set to x86 target processor. No third party libraries used. Framework used is v3.5.
The application builds and runs fine on my machine.
I copied the whole "bin\release" folder to a Win7 x86 machine and it ran fine, too.
But when I tried on a XP x86 system, it did not start. No error message, not even showing up shortly in the task manager. The XP system has all updates installed, all available .NET frameworks installed and all Visual Studio Runtimes installed.
I checked with DependencyWalker and the only missing dlls are "IEShim.dll" and "wer.dll" which are only for Vista or higher.
I tried another of my applications that's not using C++ libraries and they work fine. So I guess I am doing something wrong deploying the C++ dlls.
Registering the C++ dlls with "regsvr32" failed with a "DllEntryPoint" not found message. Registering with "regasm" was successful, but had no effect.
What is it that I am missing?
Well, seems like I was a bit hasty stating "no third party components".
Actually it was the SQL Server Compact who was missing its runtime.
I am using the code from
http://www.codeproject.com/KB/cs/OpenGLNavigation2TaoCShar.aspx
and trying it to run in Visual Studio C# 2008 Pro Ed installed on Windows 7 64bit
Whenever I run the code it stops abruptly and says the following
"An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
Please advice what to do
In your project properties, under "Build," try setting your platform target to x86. IIRC, the Tao libraries load 32-bit versions of the OpenGL libraries, and thus will only work in 32-bit projects.
I have a c++/cli dll that I load at runtime and which works great in debug mode. If I try and load the dll in release mode it fails to load stating that one or more dependencies are missing. If I run depends against it I am missing MSVCR90.DLL from MSVCM90.DLL. If I check the debug version of the dll it also has the missing dependency, but against the debug (D) version.
I have made sure debug/release embed the manifest file. I read something about there being issues with the app loading the dll being build as Any CPU and the dll being built as x86, but I don't see how to set them both to x86.
I am using VS2010.
Anyway, I've been messing around for a while now and have no idea what is wrong. I'm sure someone out there knows what is going on. Let me know if I need to include additional info.
alt text http://www.freeimagehosting.net/uploads/fb31c0e256.png
UPDATE:
This ended up being the resolution to my problem: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/07794679-159b-4363-ae94-a68fe258d827
MSVCR90 is the runtime for Visual Studio 2008. If you are running your application on your development PC, then you should have the debug and release runtimes installed (as part of Visual Studio) but it is possible something has gone awry with your install, or that VS2010 doesn't actually include the older runtimes. If you're trying to run the Release on a different PC, then it just needs the runtime installed.
Either way, you may be able to fix it by installing the Visual Studio 2008 redistributable - but make sure you get the right download for your PC (x86 or x64).
In previous versions of VS, you needed the runtime for the version you were compiling with, so if VS2010 follows this precedent you'd need MSVCR100, not MSVCR90 - which suggests that you may not have recompiled the dll with VS2010 - doing so may be another approach to get it running on your PC (using the redist that is in your VS2010 install) but beware that you will still need other users to install the appropriate (VS2010) redistributable on their PC.
As for "Any CPU" versus "x86", this is a problem only on a 64-bit computer. On those systems a 64-bit application can't link dynamically to 32-bit dlls. If you compile your application as "Any CPU" it will be JIT compiled to be 64-bit on an 64-bit OS, so will crash if it tries to call any 32-bit dlls directly. THe solution is to build the application targeting "x86" as that forces the JIT compiler to generate 32-bit code (even on a 64-bit machine) and thus ensures compatibility with the dll you wish to call. If the DLL is a managed assembly, then you can use Any CPU on both the app an dll as they will both be JITted to the same format.
It happened to me something similar running a website in Vistual Studio 2012, after migrating from Visual Studio 2010. The error message was saying that MSVCR90.DLL was missing. The solution was:
1) Delete the folder _bindeployable located at the project path.
2) Rebuild.
I hope it helps.