0

I am writing in-house applications used by multiple users in a factory.

Those different applications may refer to same dll. Any changes done on the dll requires running setup for all the applications that use it on all the user's PC that it is installed on.

Is there a way to deploy the dll on the user's PC so they will get the last version without having to run setup on each machine?

I could make it by creating a batch file which will first copy the dll to the installed folder and then run the application. But it really not seem acceptable to me.

Not sure it is relevant for the answer but I am creating the setup by using the InstallShield Limited Version

ehh
  • 3,412
  • 7
  • 43
  • 91

3 Answers3

1

Maybe your DLL belongs to GAC (see What is the GAC in .NET?) where given proper policy files you can update it for all application that use a specific version (or a range of versions). This way you can even leave some of the applications to use old version if you've made a change that is not backwards compatible anymore.

Community
  • 1
  • 1
Alexander Balabin
  • 2,055
  • 11
  • 13
1

It might be arguing semantics, but writing a batch file, a PowerShell script or an update package are all sort of "setup" processes.

If I ranked ways to create a setup I'd rank them:

  1. Setup.exe
  2. Click Once
  3. PowerShell
  4. Batch

A simple solution might be to deploy the app as a click once, where the user must check for the latest version (and it's dependencies) each time it is run. If an update is required, the Click Once will handle it seemlessly. The issues around Click Once in my experience are very tight security in some domains, and not having a multi-user install.

If you go the route of a script, I would encourage PowerShell, it's more modern and has more flexibility as well as being more readable.

The last option I'd offer however I think attacks your core question directly. You can avoid having a setup at all by embedding all of the resources directly into the assembly.

Community
  • 1
  • 1
Austin T French
  • 5,022
  • 1
  • 22
  • 40
1

You can create a separate MSI that installs just that Dll. It's already shared by multiple applications, and there is no reason why you cannot have one more "shared" setup that includes only that Dll. Then you'd just deploy that install (and major upgrade it) every time the Dll changes. The catch is that it must be at the same common location AND all the setups must use the same component guid to ensure that the sharing works correctl, and it's not clear to me that InstallShield LE exposes those guids. The way to avoid that is to create a merge module for the Dll, and include that in all the setups, including the one that installs only the Dll.

It is a bad idea to update Dlls in a non-Windows Inmstaller way if they were installed by Windows Installer setups. Windows knows what the installed versionsd are and which MSI they came from and the version. If the version on disk is not the same as the version that was installed you could get a repair triggered that would ask for the original MSI. Also upgrades and patches will ask for the original MSI file. If version 3.0 is actually on disk, but the original MSI installed 3.2, then an incoming patch or upgrade cannot know if the file needs updating on disk without first doing a repair.

PhilDW
  • 20,260
  • 1
  • 18
  • 28