A VB.Net application developed in Windows 7 64 bit machine but it can not run in Windows XP 32 bit machine.

Question

1.00/5 (1 vote)

See more:

How can I run a application in Windows XP operating system which developed VB.Net platform on Windows 7 OS 64 bit machine?

Posted 24-Apr-13 9:25am

S.Sls76

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Gregory Gadow · Answer 1 · 2013-04-24T09:47:00

Solution 1

The first thing to check is: Does the target machine have the same version of the Framework that you wrote the application in?

The second thing to check is: Are there any additional DDLs referenced on the development machine that are not registered on the target machine?

I could give a better answer if you could provide more details.

Posted 24-Apr-13 9:47am

Gregory Gadow

Comments

joshrduncan2012 24-Apr-13 15:48pm

Are you referring to dlls that are missing, not ddls? Otherwise, I agree with you.

S.Sls76 24-Apr-13 16:01pm

The application is developed in Microsoft Visual Studio 2005. But the machine also loaded Microsoft Visual Studio 2010. Now how can i understand which version of Framework required?

Gregory Gadow 24-Apr-13 16:08pm

Open up your application in VS and double click the "My Project" icon in the Solution Explorer (or use the menu and use Project -> MyApp Properties). Select the Compile tab, then the Advanced Compile Options button in the lower left. A drop-down at the bottom of the form will tell you the framework your application links to. All target machines MUST have that framework to run. If you are using VS 2005, I believe it will default to Framework version 2.0. And yeah, I meant DLLs :D

Gregory Gadow 24-Apr-13 16:11pm

And, I don't think that later Frameworks can be used in place of earlier ones: a machine with the 4.0 Framework (VS 2010) cannot run an application written for the 2.0 Framework (VS 2005.) The Frameworks are not mutually exclusive, and you can have several on the same machine at the same time.

S.Sls76 24-Apr-13 16:25pm

In my application the Advanced Compiler Settings windows set Target CUP : x86
But there are more two options AnyCPU & x64. Now which option can i need to set here ?

Sergey Alexandrovich Kryukov · Answer 2 · 2013-04-24T10:21:00

If some assembly is targeted to one of the two 64-bit instruction-set architecture there is no a way for it to run in a 32-bit system. At the same time, a 32-bit application will work on any 64-bit Windows version via WoW64:
http://en.wikipedia.org/wiki/WOW64[^].

You should always prefer the target "AnyCPU". Is all the assemblies used by your applications are like that, your application will work on any of the architecture. Actual code will be generated by the JIT compiler, depending on the actual platform during run-time. If only the entry-point assembly (usually, EXE) is compiled to a certain instruction-set target, it will actually define the instruction set used by the whole application.

There is no a way to mix assemblies (or any executable modules, including unmanaged ones, use by any of the assemblies) compiled to different instruction-set architectures in one process. Such application cannot work, no matter what platform you would try to use during runtime.

Those unmanaged executable modules (PE files) presents a special problem for multi-targeted software. They are usually compiled to once certain instruction-set target architecture, so it dictates the target of the assemblies using them, and those assemblies dictate the instruction-set architecture of the whole application. If you want to make a project working on different instruction-set target architectures, you should provide a way to replace those modules with the versions compiled to different target. This is the usual situation, when the installation package (like MSI) detects the actual platform and provided appropriate versions for the modules sensitive to the instruction-set architecture: unmanaged modules and assemblies directly depending on them (such as assemblies using P/Invoke or assemblies compiled as mixed-mode C++/CLI projects).

Please see also:
http://en.wikipedia.org/wiki/Instruction_set[^],
http://en.wikipedia.org/wiki/Just-in-time_compilation[^],
http://en.wikipedia.org/wiki/Platform_Invocation_Services[^],
http://en.wikipedia.org/wiki/Managed_code[^],
http://en.wikipedia.org/wiki/C%2B%2B/CLI[^],
http://msdn.microsoft.com/en-us/library/xey702bw.aspx[^],
http://www.ecma-international.org/publications/standards/Ecma-372.htm[^].

—SA