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.
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.
First off, I do most my programming as tools for myself and know just enough to get by. I wrote a VB program which uses a vender's API DLL to communicate with a serial port device. I used VS Express. Works great on my Win 7 32-bit machine.
I handed my program off to a co-worker (didn't expect to share my tools) who has a XP 32-bit machine. I get a windows error that it "is not a valid win32 application" I made sure to include the vender's DLL with my executable.
I really don't want to have to install VS Express on his computer as that is how I have solved the issue in the past. I could use some pointers on cross-platform compatibility. Not looking to make my software universal, just to get it running on a XP machine.
Thank you,
Xp only supports up to .NET framework 2.0 if you want to use it on all versions of xp.
So you need to check with version he has or you want to support.
So if you want it to run on Xp "All versions" you need to make it .NET framework 2.0
Is .NET 4.0 Compatible with Windows XP SP2 or below?
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 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.
I have created an application with VB 2010. My computer runs under Windows Vista. I created the .EXE file as well; simulated an installation and everything works fine. But when I try to install the application in a computer that runs under Windows 7, I get an error message and the application won't install. How can I get the application to run under Win7?
You want to be sure you have the .NET Framework installed on the PC, since VB.NET (and C#, etc.) use the .NET Framework to interact with the CLR, which is not included with Windows by default.
You can either set-up your installer to install the .NET Framework on its own or download the framework separately.