On-site 'Steam'-like mechanism for distributing builds?

Question

The company I work at currently builds its .NET products automatically and dumps the resulting installers (.EXEs) onto a shared network drive.

To install new builds, users (potentially 50+ people - whether developers, QA people, consultants etc.) have to manually find the correct build and install/upgrade. The same error-prone process occurs for patches and updates too.

As the company gets larger, I've been wondering whether there is already a solution for distributing builds within a company to many people at once - perhaps something along the lines of Steam? (i.e. a client that auto-updates builds etc. via communication with a server?)

Is there anything, preferably platform-neutral, already capable of this kind of behaviour?

I guess my bigger question is: How do big companies actually distribute their .NET products internally for testing / QA etc.?

---

Edit: ClickOnce is likely not feasible here because the products install services (and I don't think being tied to the current/installing user is sufficient)

Answer 1

OK... a bit strange to answer my own question so long after the fact but here goes:

My experience has been: Don't look for solutions that perform explicit installations/update like Steam et al.

What you should instead seek to do is use a tool that provides 'desired state configuration' and deploy it across all of your nodes.

Classic examples are Chef and Puppet.

---

Specifically, in my own environments, I've ended up deploying Chef for this purpose and it works brilliantly. By using the publicly available Windows cookbook I've been able to script automatic installation + reinstallation of the product when it is deemed to be necessary. (In my case, I'm using WinSCP - which is scriptable - behind the scenes to sync up a folder of build EXEs. I then perform reinstallation etc. if the modification times have changed).

Chef - and this probably goes for Puppet etc. too - makes it very easy to track arbitrary information about what is stored on a particular node. In my case it has been sufficient to just track the build modification time at node-level (as an attribute) in order to work out when the currently installed build is stale.

It's entirely possible that this is pushing/bending the intended purpose of these tools - but they fit the bill very well.

I highly recommend this approach if you are looking to solve a similar problem

Answer 2

You can use a ClickOnce application. Definition from MSDN:

ClickOnce applications can check for updates automatically or programmatically.

Here's an article on MSDN that explains everything you need to know about managing the updates for the application: How to: Manage Updates for a ClickOnce Application.

This is an example from the article:

To check for updates before the application starts:

1. With a project selected in Solution Explorer, on the Project menu, click Properties.
2. Click the Publish tab.
3. Click the Updates button to open the Application Updates dialog box.
4. In the Application Updates dialog box, make sure that the The application should check for updates check box is selected.
5. In the Choose when the application should check for updates section, select Before the application starts. This ensures that users connected to the network always run the application with the latest updates.

Answer 3

We only write software to be used in-house.

We have developed a system where all software is built by our teamcity server, and each piece of software uses a DLL (built using NAppUpdate) which uses the Rest API of the Teamcity server, and determine if updates are available, and pulls the latest "Release" version installer.

Installers for all of the software are built with WIX, and the installers themselves handle in-place upgrades of software installed on a users machine.

We used to use ClickOnce, but moved away from that in favor of using CI.