Weird file dependency issues

Started by
3 comments, last by frob 6 years, 10 months ago

I'm finishing a .NET project, and getting ready to distribute it. At this point, the only thing I care about is that it will work on whatever computer it's used on.

I used a program called Dependency Walker to see what DLLs, etc. I might need to include with the EXE. When I ran Dependency Walker and then opened my EXE within it, I got a HUGE list of files in a tree structure. I've never used Dependency Walker before, but it seems like a simple program to use, so I think I did it correctly.

Anyway, my program should be VERY simple, in terms of dependencies. It's just using a few built-in file/stream input/output library functions, the open and save dialog windows, and other than that, the only exotic thing it uses at all is the AesManaged class.

Note that I make no assumptions about the target computer this program will run on, either its hardware or software, except that it's using some version of Windows (by the way, is FAT32 compatible with all versions, even new ones?).

So I have a few questions:

1. Why would there be a TON of files listed, or is it just being super-picky? Do I really need to include ALL that, or just like 1 or 2 DLLs, maybe for the AesManaged?

2. I was thinking of including the .NET runtime installer with it, in case a recipient doesn't have it installed. I'm allowed to do that, right?

3. I have the .NET runtime installer version 3.5 and 4.5. Which one corresponds to projects built using Visual Studio 2012 Express?

4. Is there anything else I'm overlooking?

Advertisement

1. The files you see are likely caused by dependencies on yours, .net projects usually have a lot of them.

2. Yes, use the appropriate redist.

3. Depends on the version of .net you used in your project. You should be able to tell by looking at the your project settings. Included the latest is a safe option since they are backwards compatible if I'm not mistaken.

4. As long as you include any other files that might be required by your application (data files) you should be good to go.

A good way to go about testing this is to use a virtual machine to try out your installer and application in a controlled environment, you can also have a VM per OS you expect your application to be released on.

Thanks, but where do I get a virtual machine? Is it like an emulator that I can just install, or is it an option built into Visual Studio somewhere?

All you need to do is ensure your user has the correct version of .NET Framework installed. Your project properties show which version of .NET you are targeting. If your app targets .NET 4.5, for instance, you need to ensure .NET 4.5 is installed. No need to go tracking every single dll. The only dlls you need to ship are your own and those of the libraries you are using (outside of the .NET Framework). Common examples are Newtonsoft.Json, SharpDX, etc.

The laziest way is just to assume it's there (lots of people have it already, either through Windows Update or another program required it) and if it fails, point your user towards a download link where they can install it. That's not a great user experience though.

If you can include the redist and run it automatically on install, that's probably the best way. Steam games all do this AFAIK.


Thanks, but where do I get a virtual machine? Is it like an emulator that I can just install, or is it an option built into Visual Studio somewhere?

https://www.virtualbox.org/

Another virtual machine system, Hyper-V, is included with Windows and can be installed if you don't already have it as an optional component.

This topic is closed to new replies.

Advertisement