0

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.

You 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.

Community
  • 1
  • 1
Tom Wright
  • 11,278
  • 15
  • 74
  • 148
  • 2
    "The app won't work" What does that mean? How does it not work? Do you get an error message when trying to start the program? If so, what does that error message say? Does the program just not start? Does it start but fail to function as you expect it to function? Are you sure that you have the correct versions of .NET and the CRT installed? Are you possibly trying to load a native library that was linked against a debug CRT? – James McNellis Apr 26 '11 at 14:45
  • Sorry for being vague guys, I've updated my answer. – Tom Wright Apr 26 '11 at 14:53
  • Which DLL is missing? The one Audiere.Net lives in? Are **all** your class library assemblies being built for "Any CPU"? – ThatBlairGuy Apr 26 '11 at 15:21

5 Answers5

3

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.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • The only 32/64 things I've done are to set the managed libraries and the executables to target x86 and recompile one of the unmanaged DLLs on a 64 bit machine (the correct DLL is copied over during installation). – Tom Wright Apr 26 '11 at 14:55
  • @Tom: It sounds like in this case you should *either* use the 32-bit native libraries on all architectures, *or* change the executable to ¨Any CPU¨ so that it loads the 64-bit CLR on x64 and the 32-bit CLR on x86 - i.e. the same as the libraries you´re installing. – Jon Skeet Apr 26 '11 at 14:57
  • That seems like good advice and I'll give it a go, but I should point out that the app (as installed with my installer) works fine on both x86 and x64 machines - as long as they have VS installed on them. – Tom Wright Apr 26 '11 at 14:59
  • @Tom: That sounds pretty odd... I´m somewhat suspicious of your diagnostics there. Maybe you´re right, but it sounds unlikely. No offence meant :) – Jon Skeet Apr 26 '11 at 15:01
  • No offence taken - I've been wrong before! in case you (or anyone else) is curious enough and has some elusive spare time to burn, I've uploaded the VS solution. See my update. – Tom Wright Apr 26 '11 at 17:02
2

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.

Tom Wright
  • 11,278
  • 15
  • 74
  • 148
  • 1
    you may need to install the vs2010 redistributable http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84 or link with the runtime statically – brainiac Apr 26 '11 at 22:27
1

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.

Shadow The GPT Wizard
  • 66,030
  • 26
  • 140
  • 208
0

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.

Gregory A Beamer
  • 16,870
  • 3
  • 25
  • 32
0

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?

Community
  • 1
  • 1
manojlds
  • 290,304
  • 63
  • 469
  • 417