Best practices of sharing files between programs

Question

The company I work for is looking to finally upgrade from VB6 to .Net, and hoping to start off on the right foot, doing things right.

Currently, all of our VB6 programs share files with each other in common folders. It's a mess. Paths are hard coded in in some programs, and forced to App.Path in others. Installing a program where we don't expect causes things to break, and files to get dumped in directories not checked. On top of that, our 'standard' installation location has changed in the last few years, forcing us to update all the software that spoke to each other.

So that's what we have.

What we want is some way to share files between programs in a much, much more robust way. For example, one program may generate log files, and another watches the directory, emailing us with changes. What is the de facto way to share common folder locations between programs? Furthermore, what is the best way to determine if another program is actually installed, and if so, where it's at?

The registry seems like a natural place for this type of information - somewhere under HKEY_LOCAL_MACHINE\SOFTWARE\Company Name\Common, but I know software is tending to move away from the registry more and more. Would a shared settings file in the users AppData be a good alternative? Again, something like AppData\Company Name\Common\Locations.xml.

What have other developers done in similar situations?

Answer 1

Store fixed configuration based filepaths as settings in app.config

Answer 2

If the shared files are source or resources then build a shared assembly which is then reused.

To share information and settings there are options, but they depend on things like: are all the different apps deployed to the same folder (yes => use a shared config file, loaded explicitly within a shared assembly, so it is only written once).

Furthermore, what is the best way to determine if another program is actually installed, and if so, where it's at?

Assuming you are doing the installation properly (i.e. MSI) then there are WMI classes to list what is installed.

(It is hard to be very specific to a general question since small details in your approach can make big differences to the best solution.)

Answer 3

If you really want to, you can keep track of everything in a database. It would only be used by applications and administrators to understand what's going on with other applications and shared components. You can expect each app to update the admin database with who ran which version when.

Tracking what the setup did is a different issue. It might be easier for each of your custom components to update a common database with where it is, what version, and who's the logged in user.