Updatelogic / Deploy for Application

Question

0.00/5 (No votes)

See more:

Hello CP'ians,

i got a Question about how to update a program (selfwritten software).

On the forehand, the software is written by me and at first for internal purpose.
Therefore i thought about about a selfwritten software updater that would just replace the outdated .dll and .exe files. On the other side, this piece of work could be transferred to our friends in Japan.

Therefore i wanted to ask if im going the right way or if someone might have a better idea than me.

To describe you the situation:
The software is splitted into different parts and applications. That's why i have to implement a update logic that seperates each application. Currently i would have 3 different states.
State 1: Project-App is installed -> only update necessery stuff for that
State 2: Admin-App is installed -> only update necessary stuff for that
State 3: Both are installed -> update everything

My idea is to provide the new files on a build server, so that everyone has "access".

Currently i am thinking about an XML file that serves as config and stores what has been installed and knows the needed files + location. This could be initialized on installation. Then my Program checks if an update is available, if yes starts the updater which is copying the files and restarts the program.

Now i encouter several problems, i don't have an installer and since the one VS provided isn't there anymore i guess i have to write my own?

Another thing is, how could i cope with new added (modules) .dll/.exe/whatever files that are not listed in the xml?
-I thought that my program always checks if the xml changed, but that means i have to have an xml file on the server for every program and have to maintain it by hand.
So how would one cope with that?

Last but not least, when we ship the program, they can't maintain the stuff i can do for internal purpose.
So what should i go for? Is VS's patchthingy sufficient for that? Does it work if you would host the patches on a own server?

That's why i question, should i go for the integrated tools that VS provides, like creating patches and stuff and using "their installer" or does someone of you know a better idea, less MS attached and am i missing something?

Please feel free to ask if you need additional info
Regards and thanks
HobbyProggy

Posted 10-Jan-16 23:37pm

HobbyProggy

Add a Solution

Comments

dan!sh 11-Jan-16 6:46am

Assuming this is a client server based application, here is what I can think of. When the client application is installed, create a JSON file with all DLL names and versions. Keep latest DLL files which are needed by client on some location at server. When the client application runs, it should first send this JSON to server which can be matched with latest version. If the client is outdated, server should then push the latest DLL files to client installation directory. Of course, you will need a user name that does have access to push the files to all the client computers.

BillWoodruff 11-Jan-16 8:54am

I think your comments here deserve to be posted as a solution, so you can get the +5 you earned !

dan!sh 11-Jan-16 22:14pm

Done!

HobbyProggy 11-Jan-16 6:53am

It will be client <-> server based as soon as i transfer my SQL into a Observer. That's actually not a bad idea, i didn't work with json yet but i guess that should be rather easy? But if understand correctly i have to write an installer and an updater right?
And additionally, what about new modules?

dan!sh 11-Jan-16 7:19am

I just mentioned JSON since that will be lightweight compared to XML. It is plain text and you can use NewtonSoft provider to parse the data. It should not be an issue.

I don't think you will need an installer. If your initial install merely copies DLL files in to a specific folder, then you just need to replace the files. Nothing else should be needed. In case you are writing some registry entries, user under which server code will run should be able to modify the entries if needed.

You do not need a separate updater. What should happen is that on start of client, this data with DLL versions should go to server. If there are updates, splash screen opens up stating update in progress. During this time, server is busy replacing files on client computer. Once server has done this, it can notify client application. Then client should exit and start again on its own thus loading new DLLs.

In case there are no updates needed, server can just send back a success flag and then login etc can commence.

For new modules, I would assume you will need fresh installer or if the application is loose coupled and kind of plug and play like, then you may be able to push new modules too.

dan!sh 11-Jan-16 7:23am

Note that assemblies are loaded only on demand so if you check for version mismatch before anything else, you should be good to go with this approach.

P.S. Previous one has to be my biggest comment in Q&A.

HobbyProggy 11-Jan-16 7:32am

We have assemblies on one side like the Business layer and DMS plugins on the other side that are loaded depending on the configuration.

With new modules i thought about a reporting Module that will come surely.
It is a very informative one, thanks for that :)

HobbyProggy 11-Jan-16 7:30am

I see, thank you for all that information :)
But this whole thing might only work if i use it internal right? Because i don't think our server is allowed to install/copy stuff to clients not in the network. In this case i have to transmit the files right?

I don't wanna annoy you with all these questions but i thought when i do it, i'll do it right and fitting for all possibilities. Because selling the software would be a "dream" but handing it to our enterprise is a must.

dan!sh 11-Jan-16 7:42am

Yes this is suited for internal purposes only. If you are deploying it to customers, you can still check for versions, and then show a popup asking upgrade available. Do you need it? If user states yes, ask them to download files. Download location should be your install location. In this case, client computer will be pulling the files from server to the folders. If the user has rights, good. If not, they will need to contact their system administrators.
In this case you will need to consider about server security though. You do not want to keep a folder of your server unprotected out in public.

HobbyProggy 11-Jan-16 7:46am

Okay good :)
Yeah currently i do not need it, but if i start as if i would need it i have a solution at hand when it comes to this point. Then i will start to worry about server security and ask a question XD

Thanks for everything so far. Have a virtual +5 for your efforts :)

dan!sh 11-Jan-16 7:47am

Not a problem.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

*dan!sh* · Accepted Answer · 2016-01-11T16:12:00

ClickOnce[^] probably does exactly what you are looking for. However if you looking to write something on your own, here's an idea.

In client server based windows application that runs within the organization network, you can perform updates using following logic.

1. There must be file containing name and version numbers of all your DLL files.
2. When client application starts, before anything else, it sends content of file in #1 to server. DLLs are loaded on demand so I would recommend doing this as step one.
3. Server will have a similar file but with latest version details.
4. Server will check for version mismatch and if
a. Versions are same, success flag is sent to client application to continue.
b. In case of version mismatch, server will then push the latest files to client system. This will require a user account with privileges across the network which is generally not an issue in organizations. Once files are pushed, server sends back notification to client application which can then restart if needed.

In case your application is deployed on client networks, #1 through 4a remain same. However, 4b would change as following.

4b. Server notifies that DLL files are outdated and prompts user to update. If user choses to upgrade, they can download the files from server to the installation directory. In this case end user must have required access on his computer.

If you are creating newer modules, there can be two ways to deal with this.

1. Provide updated installer file to users. This would be viable solution assuming the assembly that runs first is also changed.
2. If you have a plug and play architecture where starting assembly is not affected even if you are adding newer modules you can go with same approach as you would for updates.

P.S. Should we delete the comment chain?