Deploying and Updating my app and content

Started by
3 comments, last by Dave Haylett 6 years ago

Hi all,

I’ve nearly finished my C# WPF project (using VS2017) and am now thinking about deployment and managing updates. This is my first time doing this, and I wanted to run my current thinking past you to see if you can help, as I don’t think my current solution will fully work. I have drawn a quick mock-up of what’s in my head at the moment (attached).

My app needs to be able to update itself, but also to add in new content once I create it (this is in the form of small .zip files, ~100kb each, and due to the volume of these files [currently 3000, hopefully expanded up to 5000 in a years’ time] I have kept these separate from my project, i.e. not as Content). I welcome comments on this decision.

Due to keeping the content separate, this kind of broke my initial intention of “simply” using ClickOnce deployment, and letting Windows manage the updating for me, and so I’ve been thinking of how to manage i) initial app deployment, ii) ongoing updating of the app, iii) ongoing addition of new content.

I’m currently intending to use my *free* DropBox account to host all the files, I think this is possible. Does anyone know of any better web hosting I could use?

If you could refer to my attached diagram, what I’m currently thinking of is:

Deploying the initial version of the app using ClickOnce by Publishing to DropBox or wherever (my project A publishing to web host D). Users can then download the Installer from here, and install on their local machines as usual. This initial installation wouldn’t have any content (the 3000 zips) and so these would be pulled down to the local machine by the below step (the initial batch of 3000 zips would only need to be downloaded the first time the app is run, after then it’d just be new content that’d be downloaded):

Also, I have as a second Project in my overall Solution a small Updater app, which when run by the users will connect to DropBox and pull down an xml manifest of my project files and the content (I create this manifest myself), and synchronise any files which are newer. This Updater app will be downloaded and installed by the users too. In the diagram, I publish Updater app code C to web host G, downloadable by users. Please see below question:

Question: my main app and my updater app are two separate projects under the same Visual Studio Solution. Is it possible for me to build/publish these together so that the two executables are together in the same output (in the same folder)? The reason I have them separate is so that the main project’s executable file and any resource files can be overwritten by any new files pulled down by the Updater app without the Main app being open and locking these files out.

The 3000-zip Content on my PC (B in the diagram) I just manually copy over to DropBox (F), and keep these up-to-date when I create new zips.

Also, whenever I update my app code, I intend (this is probably the most painful bit) to manually copy the “\bin\release” folder contents from my PC (A) over to web host (E), so that the Updater app on user’s PCs can synchronise the executable and resource files with any newer versions I have created, without the user having to download a new version of the installer, and potentially uninstall/reinstall to go from v1 to v2 of the app.

This above bit I think is the least possible, as I have found out that just by moving the \bin\release\ executable and resources from one location to another on my PC, it no longer works if I double-click the .exe file, it only works from the project’s original \bin\release folder :( . Is this expected? In my naivety I was thinking that once the user had installed v1 of the application "properly" using ClickOnce (and therefore their PC was checked for .Net framework etc) I could then just have my Updater overwrite the .exe and other embedded resource files (like bitmaps) with updates and it’d just work. I guess this would have worked with VS2005, but not with VS2017 hey.

So, after writing all that out, and thanks for reading this far, I guess that if it wasn’t for the 3000 zips, I could package all the above as ClickOnce, and let Microsoft manage the updating for me. I don’t fancy adding the 3000 zips to my project as Content [copy if newer] to enable this to happen, but I did fancy having a go at writing the standalone Updater package, which would synchronise the files between DropBox and the user’s PC, based on the xml manifest I create.

Any feedback you may have would be greatly appreciated, as this community has proven invaluable to me so far :)

Untitled.png

Advertisement

If you are serious (enough) the "best" or should I say most common way to download an update is using a REST API.

For example, you can run a small web server on a VPS (virtual private server) hosted by some web hosting company, and write your own API that implements urls like this.


Your game client could then query the rest api to check if new versions of the game is available and get a response containing a download url.

REQUEST:

GET http://mygame.myserver.com/api/versions?only_latest=true


RESPONSE

{
     "version": "1.3",

    "download_url:" "http://mygame.myserver.com/api/versions/1.3/package.bin"

}


REQUEST
GET http://mygame.myserver.com/api/versions/1.3/package.bin
RESPONSE
binary_data...

Then you could have an admin interface which allows you to create new versions
POST http://mygame.myserver.com/api/versions/1.4
POST_DATA
 


{
    "package": "C:\MyGame\package.bin"
}

 

Another viable option some PC games do is updating using a p2p (peer to peer) protocol, however, you must probably have a server up that is online 24/7 to seed your updates since you can not trust clients will always be online.

Downloading updates from dropbox would in theory probably work, but as far as I know, their protocol is closed to if you need to do something special, you are probably out of luck. 

I am not sure what would happen if thousands of people started to download rather large files from your dropbox account, maybe you should read their terms of agreement and see if you can find that they reserve the right to shut your account down if some bandwidth limitation is reached.

An alternative to dropbox is Mega, which I think might not even require an account to upload files:
https://mega.nz/

Hi Flodihn,

Thanks for your responses. I've managed to redesign my way around most of the other sticking points I had. One of which was to do away with the separate Updater program, and have the main app download the files it needs to a temporary folder, and then build a .BAT file containing delete/copy commands, shell to the batch, shut down the main app, and have the batch file restart the main app once the sync is complete. I'm sure I've seen this happen plenty of times elsewhere.

I've also (hopefully) managed to avoid having to create a separate ClickOnce copy of the app, as I've managed to get the app working from a non-development machine simply by copying the contents of the Bin\Debug folder over. I'd done this before, but had neglected to check the Event Log for any errors, and assumed incorrectly that the app wasn't working because it had been copied over instead of installed "properly", when in fact it was looking for a temporary file that resided on the development machine only. Newbie mistake.

This just leaves me with hosting and downloading files, which you've given me some pointers to. I'll avoid the P2P solution, as my app is very niche and I suspect will barely have a couple of hundred users.

This topic is closed to new replies.

Advertisement