I have downloaded both Java 8 and Anypoint Studio. I have tried setting the path to Java, but it never loads.
I keep getting error 13enter image description here
The -vm configuration seems correct. It might be that the Java version used is 64 bits and this version of Studio is 32 bits (I see a library for x86 which indicates 32 bits architecture in the error, it would be x86_64 if it were 64 bits). Studio and Java architecture have to match.
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 have ubuntu 16.04 and monodevlop editor, I have added AnyCpu option and trying to compile f# code , when I check the exe it is 32 bit, I have ubuntu 64 bit.
When I compile the same code on windows using xamarin and AnyCpu option I can see in task manager that its not 32 bit exe. So it works in windows but , anycpu option for monodevlop is not giving 64 bit exe in ubuntu.
Any idea what I should do to get 64 bit exe as output
Mono Version is 4.6.2 on ubuntu.
Regards,
Amit Bhagwat
I am working in a 64-bit Windows 7 environment and running a 32-bit version of LabVIEW.
I need to link up a specific instrument to LabVIEW, using a LabVIEW library which was given to me by the company that made the instrument. The library includes calls to a couple 32-bit DLL files which were also given to me by the company.
LabVIEW is having trouble reading those DLL files, and whenever I try to open a file I get a popup message that says "Error loading DLL". Is this because of a 32-bit/64-bit incompatibility, or is it due to something else altogether ?
Thanks,
Check the DLL in the dependency walker, there must be a DLL dependency problem.
You should be able to call at 32 bit DLL from 32 bit LabVIEW in a 64 bit OS. I believe the issue is something else.
Is it possible to load a 64-bit dll into a 32-bit process ?
Generally speaking, I know it can not happen.
Yet, maybe there are some exceptions ?
No, and neither a 64-bit process can load a 32-bit DLL.
If you're on a 64 bit OS, you can load the DLL in a 64-bit process and have it communicate with your 32-bit process through IPC.
If you're on a 32 bit OS, you're out of luck.
In .NET, it is possible to load a 64-bit DLL into a 32-bit process for reflection only. For details please check "Analyze 64-bit DLL from within T4 template in Visual Studio (32-bit) using Reflection".
I know that this is a special case, but I thought I'd add it anyway because it might help others looking for a similar solution as me.
Yes, you can load 64 code in 32 bit module. example:
vmprotect
metatrader4
above software mixed x86 and x64 in one process.
I found metatrade4 for win7 has a function it exeucte a instruction like :
jmp 0x33:0x175328
segment selector 33 is a 64bit segment. after execution this instruction, cpu will switch to 64bit mode from 32bit mode.
if you use windbg to trace some windows api on windows x64 OS, you will find similar code.
for example:
NtQueryInformationProcess
But new computer bought today at least have 4G ram. We cannot prevent using 64-bit OS to avoid problem. We must face 64-bit positively! Server 2008 R2 only have 64-bit.
Issues around EXE AnyCPU / x86, 32-bit COM / C++ dll must be handled.
Ideally compile both 32 and 64 bit COM / C++ dll.
I have an old project which uses a 32 bit dll. This works fine on 32 bit processor, however when I install the same project on a 64 bit OS it does not work.
Is there any way to convert 32 bit dll to 64 bit? Is there an alternative solution solution to make my 32 bit dll work in a 64 bit OS?
Your 32 bit dll should work just fine on a 64 bit machine as long as it is loaded into a 32 bit process - attempting to load a 32 bit dll into a 64 bit process will fail.
If your project is a .Net (e.g. C#) application then you should be able to target your assembly at x86 in order to get your 32 bit dll working correclty:
Right click on your project in Visual Studio and select Properties
On the Build project properties tab ensure that the Platform target drop down reads "x86" instead of "Any CPU"
If you platform target is "Any CPU" then your project will normally be targeted at whatever platform is available, i.e. x64 on a 64 bit OS - this will prevent your 32 bit dll from being loaded.
If your project is not a .Net assembly then the equivalent steps needed to do the above will be different.
Alternatively you can attempt to obtain a 64 bit version of your dll - if it is a dll that you have produced then you will need to migrate it to 64 bit yourself. If not then you are dependent on the original suppliers providing a 64 bit compatible version.