What voodoo does VS do to a system to get apps to run? (And how can I get these apps to run without it?)_问答_开发者

I'm past the point of despair with this one guys. I was so sure I'd got it all boiled down to a simple x86/x64 problem, with a simple enough solution. But no. It's back. Back again to bite me on the ass.

Yo开发者_StackOverflow中文版u see, I've made an app and was previously having trouble installing it on a laptop running Vista. Then I noticed the laptop wasn't just running Vista, but running Vista on a 64 bit architecture. So I installed Visual Studio 2010 on the laptop and recompiled one of the DLLs for x64. The app worked. Everything is groovy.

Except now I'm trying to install the same app on some 32 bit machines running XP. And the App won't work again. Even after ensuring that .NET 4 and VC++ 2010 are both installed on them.

So now I'm taking stock and a common pattern emerges: The app only works if VS2010 is installed on the same computer.

My question then, is what steps does Visual Studio take to ensure an app will run? And how can I do these steps on other computers without installing Visual Studio?

Update - my app and how it fails

My app calls two main managed libraries - both of which are wrappers for unmanaged libraries: EnguCV for image processing and Audiere for audio output.

When I say it doesn't work, what I mean is that it crashes before it fully opens. The error is a DllNotFound error and cites Audiere.Net (the wrapper) as the cause. Unfortunatey, ProcMon seems to dislike these machines and invariably hangs after a few seconds (taking the whole OS with it).

Update 2 - the VS solution

In case anyone wanted to try it out for themselves, I've uploaded the full (22mb zipped) VS solution. If you want to play with audiere.dll, Audiere.Net.dll and libaudieresharpglue.dll, you'll need to grab the Win32 Audiere DLL, lib, and header as well as Harald Fielker's C# binding.

If anyone is mad enough to have a play around, I'd be very grateful for a sanity injection.

If you've recompiled the DLLs to require x64, then the app won't run on a 32 bit machine, no.

Unless you're using interop with native code, it's usually best to compile executable assemblies as x86 and class libraries as "Any CPU". Only force the 64-bit CLR if you really need it - most of the time you don't, and the x86 CLR will make more efficient use of memory. If you want to run on both x86 and x64 and want to use lots of memory when running on 64-bit Windows, then you can make the executable target "Any CPU" too (in which case the default CLR for the architecture will be loaded) but again, only do so if you really need to.

See this post by Rico Mariani for more details.

I did it. (Almost crying with joy here, but that's manly right?)

The error makes it pretty clear that the cause is somewhere downstream of Audiere.Net.dll. Reflector tell us that this only depends on mscorlib and only P/Invokes libaudieresharpglue.dll. Dependency Walker indicated that libaudieresharpglue.dll depends on just msvcr100d.dll and audiere.dll.

Since we know that both libaudieresharpglue.dll and audiere.dll are present, the fault must lie with msvcr100d.dll.

On the dev machines (where the app functions as expected), running Process Explorer shows that this guys lives at WINDOWS\system32\msvcr100d.dll. I had assumed (from previous chatter) that VC++ 2010 installed this DLL, but I can't find it on the target machines (upon which I have just installed VC++ 2010).

Anyway, have copied him over and everything is now working as expected.

It all boils down to what DLL files exist (or don't exist) in the target machine, either in the same folder of the EXE file or any folder that is part of the global PATH.

If you can track down what DLL file(s) is/are missing just make sure to add those to the EXE when sending to the clients.

You have the option to compile for all CPUs, if you just want a generic approach to getting software to work. NOTE, however, that all of your dependencies need to be generic for this approach. When you are using interop for native DLLs, you end up having to create two versions (1 32 bit and 1 64 bit) for at least some of your applications. A pain? certainly. But it is a growing pain.

As for the "I need Visual Studio installed", it is more likely you are using a DLL that is installed with Visual Studio, or you need some type of runtime on the computer. You need to examine the software dependencies and determine what needs to be boostrapped to your installer. If this is native, rather than .NET, you need a tool that shows COM dependencies (if COM) or similar. There is a COM explorer, for example. Not sure, but sys internals (now Microsoft) may have a free dependency tool.

Until you determine the dependency, installing Visual Studio is your option. After that, you can make sure the dependency is installed, and registered if COM, so the software works.

Make sure that your project is built with "AnyCPU" cponfiguration.

Look at the link below for a similar question which answers difference between AnyCPU, x86 and x64

http://social.msdn.microsoft.com/Forums/en/netfx64bit/thread/0b21d7a4-d929-4ac3-8447-f51b9c28ec9c

Explanation on Platform target: http://visualstudiohacks.com/articles/visual-studio-net-platform-target-explained/

Also: What does the Visual Studio "Any CPU" target mean?