I'm trying to browse to my Slb.Ocean.Petrel.dll in my install path so that I can get the controls in it, mainly DropTarget, but I just get an error...
Could not load file or assembly 'InventorNet, Version=8.1.2.2, Culture=neutral, ....' or one of its dependencies. The system cannot find the file specified.
Any ideas?
AFAIK, there's some collision between VS2010 (32bit) and Inventor's dlls (64bit). So, to be able to use functionality in VS2010, try to copy 4 (32bit) dll's to 'Public' folder:
InventorBase.dll
InventorNet.dll
SbLinear.dll
SbLinear.netmodule
If you use 64-bit Petrel, you will need to copy those dll's from any 32-bit location.
Hope this helps.
Related
I am facing the following (fairly common) problem: I am running my program in Debug mode in VS2010 and/or VS2012, but at startup it crashes, saying:
The programme can't start because MSVCP100D.dll is missing from your
computer. Try reinstalling the program to fix this problem.
Now I found a number of possible solutions, but none of them work for me:
Compile with /MTd instead of /MDd: actually this does solve the problem, but I am not allowed to: my program is part of a bigger program, and /MD[d] is mandatory.
Install the VS 2010 Redistributable package: This doesn't work because I have VS 2012 installed, so this installer tells me: "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
Finding, dragging and dropping a version of MSVCP100D.dll into the correct directory: I am not dropping unknown DLLs into places where they might interfere with other things.
Last resort: reinstalling VS2010/VS2012: possible, but as it would also mean reinstalling lots of other packages and plugins I need, I'd like to avoid this if it's not absolutely necessary.
Are there any other options left?
The Visual Studio REDIST packages never deploy the DEBUG versions of the CRT files. This is by design.
With VS 2012 or later, the easiest way to deploy the DEUBG versions of the CRT is to install the "Remote Debugging Tools" package on your test machines.
For VS 2012, the latest Remote Debugging Tools package is here
For VS 2013, the latest Remote Debugging Tools package is here.
Another option is to just use application local deployment of the DLL (i.e. copy it into your app directory). Again this is only for testing purposes. For actual deployment of your application, you are required to use the non-debug versions of the CRT.
If this error is happening on your development machine, however, then you have other problems because with VS 2012 installed, you should have the VS 2012 DEBUG CRT on that machine.
UPDATE:: Sorry, I would have expected the debug CRT DLLs to be included in the remote debugging tools package along with the remote debugger bits and the Direct3D 11 Debug Device. Alas, it's not. See Preparing a Test Machine To Run a Debug Executable. You have to either use the MSMs in Program Files (x86) directory in \Common Files\Merge Modules or copy the DLL-side-by-side from Program Files (x86) directory in \Microsoft Visual Studio <version>\VC\redist\Debug_NonRedist\. The VS Team probably assumed you would have already been doing that, but I'll suggest to them to roll it into the remote tools package.
I had a similar issue (the project made in VS 2012 but I was running VS2013) and resolved it by:
Open the project (or the solution ) in VS2013(or the newer one)
Open Project menu and select "Retarget the project" option (it was the first option but after applying it, this option vanished).
Rebuild your solution.
I am new to openCV and C++ and had the same problem using openCV 2.4.10 with Visual Studio Express 2013 on a Windows 7, 32-bit platform. If I made a simple program without using OpenCV, the program ran but when I used OpenCV I got the missing DLL error.
This post made things clear:
I guess the problem I had was not with my Visual Studio but my OpenCV. The OpenCV was compiled on a version of visual studio which required MSVCP110.dll. I could have tried another version of OpenCV or compiled OpenCV again using VS2013 but I was short of time. Instead, I found the dll file elsewhere and placed it in my system32 folder (not sure if that's recommended). This fixed the problem. However as #slater mentioned, I won't recommend downloading the dll from external website due to security issues.
This is a debug runtime DLL. If (and ONLY if!) you just want to run the debug build of your own application on a system without Visual Studio installed, then you can find the missing DLLs in
C:\Windows\System32 (for 64-bit builds)
C:\Windows\SysWOW64 (for 32-bit builds)
Just keep copying DLLs until your executable will run.
If this is NOT what you are trying to do, refer to https://stackoverflow.com/a/27386721/2279059, which is the CORRECT, but less practical answer.
I had the same problem, I found out that the cause is that I used dll compiled with VS2012 in a VS2013 project. JUST downloaded the missing dll and put it in my linker path and wala: the program worked. I downloaded it from http://www.dll-files.com/.
Particulars: My program was working in in release mode but not in the debug mode as it says the MSVCP110D.dll is missing. My code was an opencv image processing program. I put the missing dll in opencv linker path in the VS2013 project options.
How to replace a strong named DLL in GAC by the windows installer?
I am having two installers that shared some common DLLs from the GAC.
suppose there is any change in any common DLL then
running any one installer with latest DLL is not replacing the existing DLL.
from some old post, it is suggested that changing file assembly version will replace DLL.
that approach is not working. Is there anything else needs to be done apart from that?
Windows Installer will not update an assembly in the GAC if you only change the assembly file version unless your install authoring tool also sets the fileVersion attribute for the assembly in the MsiAssemblyName table of the new MSI.
Aaron Stebner addresses this in his blog posting.
I know that this works when using WiX, as I've done this in several installers. I don't know how this might be done in other authoring tools.
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
I'm a bit confused as to what's happening here.
My understanding is that when an assembly is required at runtime, the runtime will first try to load the assembly from the executing directory (or the directory where the dependant executable is located). After which it will attempt to find the assembly within the GAC.
First of all, I am on Windows.
Now, when I'm compiling my solution is VS, everything works fine (as expected), but when I compile the same solution in MonoDevelop, the compilation stops due to errors pertaining to a missing log4net reference (the exact assembly for which I manually installed into the GAC to avoid this situation).
So, my question is this: Does MonoDevelop look at the GAC at compilation time to determine if an assembly is available, or is there another location in which I need to provide the required assembly?
Thank you for your help!
From MonoDevelop site:
I added an assembly to the GAC, why doesn't it appear in the assemblies list when I try to add a reference in a MonoDevelop project?
Bacause MonoDevelop does not look for assemblies in the GAC. On Mac
and Linux, MonoDevelop uses pkg-config to locate installed packages
and get the list of assemblies that each package provides. A package
specifies this list of assemblies in a .pc file which has to be
installed in the standard pkg-config directory.
If you are developing a library, MonoDevelop can automatically
generate a .pc file for your project (in the project options dialog,
select "Linux Deployment Settings", and check the "Generate .pc file"
option).
When targetting .NET on Windows, MonoDevelop uses the same
AssemblyFolders mechamisn that VS uses.
I'm trying load a 3rd party DLL but I get an error when attempting to load it. Opening it in Dependency Walker shows that the DLL simply relies on kernel32.dll and msvcr90.dll. However, I get the following error in Dependency Walker when opening this DLL: Error The Side-by-Side configuration information for [full path to the dll that I am loading] contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
The only copy of msvcr90.dll that exists on the system is one that I copied into the directory that contains my third party DLL. I ran into a very similar problem on another machine and installing the Visual C++ 2008 Redistributable package from Microsoft fixed it. However, I really need to get to the bottom of this as I can't install the redistributable package on all machines that I need this to run on.
I've also tried opening the third party DLL in Visual Studio and examined its manifest. In it I can see that it explicitly is dependent upon the SP0 version of the Visual C Runtime library:
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
However, copying that exact version of the DLL to the machine with the problem still doesn't fix it. What gives?
Ok, I figured it out. I had to include a copy of the Microsoft.VC90.CRT.manifest file. Normally, you can get this from the [Visual Studio 9.0 install dir]\VC\redist\x86\Microsoft.VC90.CRT directory. However, I had SP1 of Visual Studio installed which had slightly different versions of these files. I ultimately extracted the appropriate file from the redistributable package from MS. Obviously if I had another 3rd party DLL that depended upon a different version of the msvcr90.dll I would be in trouble. I guess this is why Microsoft created the side-by-side thing to begin with.
In short (for any potential Googlers in the future), you have two options:
Install the Visual C++ 2008
Redistributable package (just Google
that term, you'll find it)
Or manually copy the necessary DLLs
to your application directory
including the .manifest file