I have project I've made in visual studio that contains an executable and dll which it calls. Everything works fine when I build them for the 64 bit machine I have visual studio on, but when I change the platform to Win32 compile the executable and dll and attempt to run it on my win8 32 bit machines I get the following error two messages on (two different machines):
The program can't start because MSVCR110.dll is missing from your
computer. Try reinstalling the program to fix this problem.
and:
The procedure entry point
?in#?$codecvt#DDH#std##QBEHAAHPBD1AAPBDPAD3AAPAD#2 could not be
located in the dynamic link library.
Related
Im developing continually an inventor Addin in VB.Net in visual studio 2019 ,
i have multiple machine different builds , but once in a while some machine just don't want to load the Addin f.e. the current version i have now works on all machines except one AMD machine .
When i compile the same project with the same settings no changes at all on the AMD machine with ANY CPU build option it runs without problem . When i do it on my primary developing machine it does not work on this other computer.
I checked dependencies with dependency walker , i do not get any error messages .
When i make breakpoints in DEBUG mode and debug dll compilation in the first methods called in the "StandardAddInServer.vb" file it does not reach it on the AMD machine when it is compiled on the Intel machine. But in reverse it runs smoothly .
I have no idea what this could be and I'm only speculating that is has to do with AMD/Intel difference of the machines . Any help would be appreciated to come to a solution.
Inventor 2018.3.7 Professional Build 287 is on the Intel i7-4771 machine Visual Studio Community 2019 16.3.9 , .NET 4.8.03761
Inventor 2018 Professional build 112 is on the AMD Ryzen 7 3700X machine Visual Studio Community 2019 16.7.2 .NET 4.8.03752
Any more information which could be helpful will be provided gladly .
Well.... i tought lets make the maschines identical in regards to software .. i started installing inventor updates one by one at Version 2018.3.1 the Addin magically was working .... so i hope i help somebody if the , addin automatically unloads without any error , its probably autodesk inventors fault ...
Are you using ANY CPU ,or are you forcing the project to a given bit size?
If you don't set this, and leave it at ANY CPU? Well, if you launch the application from Visual Studio (such as installing on that target machine), then the application will run as x32 bits.
HOWEVER if you launch the program from the windows command line (command prompt).
Well, if you use the x64 bit command prompt, you get a x64 bit running - in-process program. If any of your external .dll's or libraryes are x32 (or not compiled with ANY cpu), or you using any un-manage code libraies (say like ghostscript or some such)? Then your program will run (or try to) as x64 bits.
However, if you launch a x32 bit windows command prompt (there are two of them - one is x32, and one is x64). So, if you launch the .net exe (your program) from a windows x32 bit prompt, then your program will run in-process as x32 bits.
So, be careful here. Using ANY CPU from Visual Studio will ALWAYS get you a x32 bit program - including debugging. But RUNNING the program (launching outside of VS) will not always be x32 bits.
And the above behaviours seems to explain your issues/problems on the AMD machine. It was NOT that you installed VS on that machine, but that using VS to launch your program in fact FORCED it to run as x32 bits.
Bottom line:
do NOT use ANY CPU unless that is exactly what you need, and that you are VERY sure any external libraries are also compiled as ANY CPU, or in fact that any external libraries doe NOT USE any un-managed code.
All in all? I would config your project to force run as x86 ALWAYS, and thus you not get some surprises of code not working.
I doubt very much that the AMD CPU is the issue, and installing VS only worked because of forcing your project to run as x32 as opposed to x64 bits. It has zero to do with AMD here.
You could try with a former framework version like 4.6.2. That should fix the problem. It could be that the newer service packs of Inventor can deal with addins created with newer .net versions. When 2018 Inventor was released, .net 4.8 was not available.
Was Albert wrote is true as well. If the architecture of your dll doesn't meet that of your host process, it can't be loaded. A 64bit process can use 64bit dlls only whereas a 32bit one can deal with 32bit dll only. A .Net project won't be compiled by Studio into fully functional machine code (nowadays you can do this as well), but intermediate code only, which will be compiled finally by the .net framework on the target machine. If anyCPU is selected, you don't have to provide different versions for different hardware because of this behaviour.
I am a .NET developer with limited experience in C, C++, and C++/CLI.
We have an old program which is still being developed in Visual C++ 6.0, strictly in C (no C++ features). I've been asked to develop a C++/CLI DLL for this application which allows the application to run some routines that were written in .NET. I'm using Visual Studio 2013.
The machine being used to develop the C application is running Windows XP, has .NET 4.0 installed. We have gotten it to link with the C++/CLI DLL and everything compiles fine. However when we run the software, nothing happens. The user interface doesn't show up and there are no error messages. The process just shows up in the Task Manager for an instant, then goes away. Kind of hard to debug when we don't have any error messages. If we comment out the DLL function call, the software works as usual.
We're using good DLL practices such as extern "C" {...}, __declspec(dllimport), __declspec(dllexport), deploying msvcr120.dll along with my DLL, etc. We set up a dummy test DLL without C++/CLI support to make sure we are creating DLLs correctly and everything worked fine.
Does this mean it's impossible to use a C++/CLI DLL in an old C program?
EDIT: I got it working on my development PC (Windows 8.1), but not the Windows XP development PC with VC6. On the Windows XP PC the program crashes before it even calls the DLL function.
It turns out this is an operating system issue.
After I noticed that it works just fine on my Windows 8.1 PC, I took a look at my platform toolset settings for the C++/CLI DLL. To get to those, right-click on the project -> Properties -> Configuration Properties -> General. I was targeting "Visual Studio 2013 (v120)" when I should have been targeting "Visual Studio 2013 - Windows XP (v120_xp)". After I changed that setting, the DLL started working on the Windows XP machine.
Using VS 2010 Ultimate on my Windows 7 64-bit machine, I wrote a Windows Forms Application with Visual Basic and then compiled it with "Build" command specifically for x86 platforms ( I have tried assigning both "x86" and "Any CPU" on Active solution platform options in Configuration Manager). I have also made sure that TargetPlatform is set to x86 on Project Properties.
However, when I'm trying to run the .exe or the .msi file on my XP 32-bit machine, I get this message:
"This product is designed for x64 platform but is being installed on Intel. Obtain the correct setup from the manufacturer."
.NET Framework 4 client profile, which is a Prerequisite for my application, is also installed on the XP machine.
Does anyone have a clue for this? How can I fix this?
Thank you for your time.
I'm not sure about 2010, but in VS2008 it is sometimes necessary to go to Project Properties, Compile, Advanced Compile Options, and change the target CPU to from AnyCPU to x86.
I'm trying to install Testacular (using nmp) on a Windows 8 Professional (64 bit) laptop, but it fails when it tries to install socket.io as part of this process. The error I get is
Could not load the Visual C++ component "VCBuild.exe".
To fix this, 1) install the .NET Framework 2.0 SDK, 2) install Microsoft Visual
Studio 2005 or 3) add the location of the component to the system path if it
is installed elsewhere.
I apparently have .NET framework 3.5 installed (it's checked under the add/remove Windows components bit in Control Panel), although I've not managed to find a vcbuild.exe. I tried installing an old copy of VS2005 but this resulted in a different error about an invalid project (.vcproj) file.
Can anyone suggest how I might get this working? Weirdly it installed fine on my work computer, which is very similar to the one on which it won't install (they're both 64 bit Win 8 Pro).
I ran into the same issue. I fixed this by adding this to environmental variable PATH: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages so that it can find vc build.
In Visual Studio 2010, the command line tool vcbuild.exe is replaced by msbuild.exe. So, please make sure you have right Visual studio.
I developed the project in visual studio 2010. That exe file is not supported for other PC's.
which dotnetframework to be installed? other than dotnetframework is there any other requirements needed?
Are you sure it's not the CPU type you specified during compiling (x86 vs x64 CPU). If you compiled in 64-bit and a user only has a 32-bit processor (x86), your code won't run.
The .Net Framework should work on any PC-based system, but be sure to include it in your deployment or setup package. (you can provide Excel, .NET Framework, and many other packages with your package.)
You should also try to find out what error messages your users are receiving -- which will point you in the right direction.