I am working on a vb.net winforms application that compiles against the 2.0 framework. My issue is that I am running Windows 7 32 bit machine and my app works fine but when the code is copied over to a Windows 7 64 bit machine some of the controls on the form are strangely disabled. In Project Properties it is set to compile as x86 target. Has anyone experienced a similar problem and does anyone have an answer as to why I am having problems on the 64 bit machine?
Set it to compile to Any CPU instead of x86. The framework will deal with the rest for you, you should only target a platform if you have references/controls that require it or if you're playing around with application performance.
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 running visual studio 2008 visual studio 2010 vs 2012 on windows 7 platform with visual basics windows form application. No matter what i do , installing and targeting .net frame work 3.5 or older . The EXECUTABLE file built in this setup fails to run on windows xp SP3. what am i missing ?
Problem is being reported it as invalid win32 application , faulty start-point!
I had something similar issue a few years ago, but in reverse.
It might not be a .NET version issue though: it might be a 32 / 64 bit problem. After spending a lot of time on .NET framework requirements and re-re-reinstalling, once I compiled to 32 bit rather than Any CPU it would run on XP SP3 (even though it was 64 bit XP).
I am working on SharePoint domain. Sometime I need to do development for event receiver and windows service etc.
Last week I have installed a Windows Service on my server to upload the documents from a local folder. Server is 64bit machine and "Windows server 2008 R2" installed on server as OS to run SharePoint Foundation 2010. Service was running properly.
The requirement was, no user will go to the server to upload the document. So I have installed the service on local users machine. Some users were having 32 bit Machine and 32 bit OS and other users are working with 64 bit. while installing the service I got an error on 32 bit machines. Error was "This solution is for 64bit machine". After changing the target platform from 64bit to x86, the service was installed successfully on 32 bit machine and started working properly.
Now the question came:
To work with SharePoint Object Model, I am using SharePoint 64 bit
dll in my Windows service which is installed on 32 bit machine and 32
bit OS.
Is it possible that the 64bit dll will work on 32 bit machine?
In what scenarios we can face the problem of "64 bit dll will not
work on 32 bit machine"?
What should I do if I want to install the same solution on 64 bit
and 32 bit machine? I don't want to change the target platform
each and every time.
UPDATE:
After R&D I found "32 bit solution can be installed on 64 bit dll with some terms and conditions" refer http://www.samlogic.net/articles/32-64-bit-windows-folder-x86-syswow64.htm.
In 64 bit machine we are having Program x86 and SysWOW64 folders to handle the 32 bit dll functionality.
Now the question is:
How we are handling the 64 bit dll on 32 bit machines?
And
Is it confirm that the SharePoint dlls are "any CPU"?
Regards.
Not sure I understand what you are trying to do, so I'll try to be exhaustive:
SharePoint Object Model are only available on SharePoint servers, not user workstation. They indeed rely on 64 bits DLL that only work on 64bits OS.
SharePoint 2010 allows you to use the "Client Object Model" that work on remote computer like use workstation. They are .Net DLL, not specific to 32bits or 64bits. Just compile your exe with "Any CPU" and it will work just fine
Generically speaking, 64bits exe only work on 64bits OS. In .Net you can however use "Any CPU" that will work for both 32bits and 64bits. This however will only work if you exe and its dependencies are full .Net (no native code).
We purchase a licensed Control for Biometric from Griaule biometrics.
we are using this Control on a Window Application's form.The AxInterop.GrFingerXLib Dll control is working fine on the 32 bit operating System.
But due to some reason we change the Operating system from 32 bi**t to **64 bit.
On the 64 bit operating system the window form on which we are using the AxInterop.GrFingerXLib DLL Control is unable to Create.
And if we remove the Control from the Form working fine.
We use the the latest release of Fingerprint SDK 2009 but it still not working.
We also did that we remove the Control from the form and then again include the control on the form then it gives some ActiveX control not find related Error.
We are using Visual Studio 2008 and Windows Server 2008 64 bit operating System.
Its urgent issue and we want to resolve it as soon as possible.
Please provide a needful support.
I Have Found The Solution
When I build the .EXE with x86 Configuration the Problem have been resolved
Steps i Followed
Build-->Configuration Manages
Here set the application's target platform. to x86
Build the Project
u will find a Newly created Folder x86 under Bin Directory
use this Exe in 64 bit Machine it will work fine!
I am working on an application which is in 32 bit. This app is working fine in 32 bit machine .
But when I install it in 64 bit machine it does not work properly. So we planned to compile it in 64 bit configuration. We could compile it and tried to run, It works properly.
But problem is; we have a 3ed party library which is in 32 bit. If I try to call that library from 64 bit, will it create problem, will it work?
I am running it in windows 7 64 bit amchine.
Please guide me to supporting my application to 64 bit.
The JET database engine will never be ported to 64-bit. You will have to consider a different engine. SQL Server Compact or Express are excellent choices.