I want an auto updater that detect modified game files (by comparing files on the client-side and a server) and only download modified files.
The scenario is that there's about one thousand clients in a network, that use same application. If a new version of the application is available, they all have to get the new version.
I see a www.aldera.to game if you install the files their Aelra_patcher application auto patch the files from the server side. It do the exact thing I want:Getting the newest files from server when the patcher is run. But the problem is that clients wrote in C#, and I can't use IcePatch2 inside my application.
So far, the best solution I found is to get .NET Application Updater Component and customize it to fit my needs. But I prefer a solution that dose not require me to maintain another application.
Any idea?
Managing file locks is fairly simple. The process should go something like this:
The game application downloads the installer, if there is any
The game application runs the installer and exits
The installer starts doing the work of updating files as needed. If any files are locked it may wait a short while and try again, or ask the user if it is ok to close the application that have locked the files.
But the topic of minimizing update time and bandwith is a fairly complex. You might want to read Raymon Chens articles on Windows Update Formats to get some appreciation for the various issues.
I'm not familiar with IcePatch2, but it seems to be a fairly generic file synchronization tool. This may be appropriate for your specific use case, but I would expect some use cases to benefit from a more specialized approach. You could for example use knowledge of things like file or resource versions to avoid much of the work a more generic tool has to do.
Related
I know this question has been asked lots of times but mostly I couldnt find the answer I was looking for.
How do popular applications update themselfs ?
I found some libraries that update applications but mostly they just replace all the application files. This way my Updater would need to download around 200mb everytime.
Also ClickOnce is used a lot but this in my oppinion is an ugly way to update and install because the GUI is not really fancy and you can't even specify where to install the application.
I know some applications also replace the installer and just run the new one to deinstall the old version and install the new one but that cant be that right way...
So how do Programs like Mobirise, Discord or Teamspeak update themselfs ?
I have a have made a POS Solution(C#), working in 4 Shops.
This is what i've done to give client side updates.
Used Google Drive to upload installer file + a text file mentioning installer version, once uploaded each time the programe starts up it downloads the version text file from Google Drive, if it doesn't match the current version of the software which the clients Has, Messagebox Prompts a newer version is avaliable. Client then can click Upgrade and it will download the installer file, once downloaded software exits completely calling a python script which will Run the installer file.
This is not the best way but it works, becouse Google Drive has its own file version history which makes it easy for me to keep track of updates i send.
Hope I Helped <3
You can design the application to be patchable.
Patching is not a hot flavour in windows world.
I'm currently searching for a way to make it possible to deploy and update a C# .NET application over SFTP. Background is that most of my users do not have admin rights, internet access rights or common file structures/group policies. The best I could actually get was the ability to also use the SFTP-infrastructure the application already uses for data transfers.
So I tried using Visual Studio publish, which can deploy the application initially, however it does not support the update mechanisms (it only supports URLs and File Paths). A manual update/deployment process is out of the question, however, purely through the sheer size of the userbase (1000+ users).
I then had a look at wyBuild, a third-party build-tool that can actually use sftp to upload Updates. It can not, however, download them via sftp.
So I'm reaching somewhat the end of my rope here. Writing an updater myself seems like a large time investment, but I could not find any other solution. How would this problem be solvable? Thanks for any help in advance.
Oh, and before somebody flags for "asking for a tutorial", I tried hard to stay within the guidelines stackoverflow provides here
This is the situation I have:
I created an installer. It has python scripts, executable, and other file types. In the installer, I run a C# executable as a custom action, after registering the product. The C# executable moves the files into different locations (i.e. a text document will be moved to My Documents). I understand I can do this without the custom actions, but I was not aware of that when I created the installer.
Now, after I have distributed the software, users are running into small bugs. For instance, there is a bad if check in one of the python scripts.
Question Is there a way to fix the portion of the python script/executable/text document that is broken, and simply update those files (without having to redistribute the software to the users, and having them reinstall it)?
A patch probably won't help you. If the locations are fixed within the install, a minor upgrade could do the trick, if you make all the files that need to stay the same "never overwrite" (unless the custom action ignores this, then things might get difficult).
If the locations are determined during the execution of the custom action, or the locations are based on user input during the install, then you have a problem if you haven't saved the location paths (in the registry, for example). I don't think you want a custom action to scan all the drives of the computer just to find the files.
If the files are put in their new locations by the custom action, windows installer probably won't see them as key files and probably won't "repair" them in any scenario. If the fixes are few, you might be better of distributing the files separately with a clear instruction, in stead of spending many hours on a difficult new custom action.
Cheers, B.
I'm sorry, apparently I missed the trigger that you had placed a comment.
If this is this something you would like to know, look at this table. It shows when to use major, minor or small fix (patch).
Hope it helps.
Cheers!
http://helpnet.installshield.com/installshield17helplib/MajorMinorSmall.htm
I'm using SharpDevelop to create a WinForm-based C# application. After studying my target audience, I believe it is in my best interest to use a no-install application. While creating my HelloWorld! program to get to know SharpDevelop (I have just switched from VBExpress), I found that the file it outputs is a .exe without any setup process. However, I'm worried that some of the features I want won't be compatible with this format. I don't want to get deep into this app and find out users are going to have to keep the program in the same directory as 548 other random files.
Here are the features I'm concerned about:
+Save user data (XML) in AppData.
+Access internet feeds (XML and/or JSON).
+Minimize to tray on close.
Also, are there any common pitfalls with this type of deployment method?
EDIT: I understand the enduser will need the .NET framwork for C# programs. I am not worried about this.
It will execute with the same privileges.
The only thing you will want to look out for is making sure the end user has the correct .NET framework installed since you don't have an installer to do that for you. But now reading the end of your message it appears you already have that covered.
If you are concerned about the deployment technique you can test it on a non-dev machine, though the results should be the exact same.
One of my favorite things about owning a USB flash storage device is hauling around a bunch of useful tools with me. I'd like to write some tools, and make them work well in this kind of environment. I know C# best, and I'm productive in it, so I could get a windows forms application up in no time that way.
But what considerations should I account for in making a portable app? A few I can think of, but don't know answers to:
1) Language portability - Ok, I know that any machine I use it on will require a .NET runtime be installed. But as I only use a few windows machines regularly, this shouldn't be a problem. I could use another language to code it, but then I lose out on productivity especially in regards to an easy forms designer. Are there any other problems with running a .NET app from a flash drive?
2) Read/Write Cycles - In C#, how do I make sure that my application isn't writing unnecessarily to the drive? Do I always have control of writes, or are there any "hidden writes" that I need to account for?
3) Open question: are there any other issues relating to portable applications I should be aware of, or perhaps suggestions to other languages with good IDEs that would get me a similar level of productivity but better portability?
1) There shouldn't be any problems
running a .NET app from a flash
drive.
2) You should have control of
most writes. Be sure you write to
temp or some other location on the
hard drive, and not on the flash
drive. But write-cycles shouldn't be
a problem - even with moderate to heavy
usage most flashdrives have a life
time of years.
3) Just treat it
like's it any app that has xcopy
style deployment and try to account
for your app gracefully failing if
some dependency is not on the box.
If you want to use com objects, use reg-free com and include the com objects with your program.
You should always have control of your writes. Applications should be loaded into RAM at startup, and then memory past that is allocated in RAM, so nothing is written to the flash drive.
The most important thing for a portable application is that basically no installation is necessary for your application. You do not want to be dependant on registry values especially, since your application will not be 'installed' on other computers.
One of the issues with portable applications you may consider is data persistence. Generally, you write to a user's Application Data folder to save data. If this is the case, any data saved will only apply to the user on that computer. If you want some local application data, you may wish to create a Seralized XML file for your settings and store it locally within your application's directory. This file writing would then likely be the only write actions you'd need to worry about.
For your .NET portability issue, you could also write a small entry program in C++, which checks if the computer has .NET installed. .NET has registry values you can check to see the versions installed, so if .NET is installed, run your application, else display a message stating that .NET needs to be installed first.
Edit: I'd like to add that I do application development for Ultrasound machines using XAML in C# 3.0. The application I write works perfectly from a USB Flash Drive, while all user settings are stored on a local AppData basis, so nothing is written to the USB. While the application can be installed through an .exe installer, the installer does not write any registry values the application depends on.
I don't really have answers for #1 or #3. But for #2, the .NET CLR shouldn't be writing to an app's "installation" folder (i.e. the flash drive) unless your code specifically tells it to or is using and modifying file-based settings (ini, xml, etc) that live with the app.
Number 1 is really the kicker if you're not just writing things for personal use. Obviously hosting a portable copy of the full CLR on the thumb drive is impossible. But there are tools that can scan your assembly for its dependencies and package them up into a standalone .exe so that the CLR doesn't necessarily need to be installed on the target system.
I don't actually have any experience with this so it might be best to take what I say with a pinch of salt. But here is my take on it:
You don't need to do anything special.
It is not really a consideration of an application developer as to how and when writes are made to a drive, that is something that is far better controlled by the OS. I know that Windows caches writes to USB drives so I would trust it do handle that.
The only thing you need to consider is that your application will not be installed. So you need to make sure that you design it to run entirely self contained within the directory it is deployed to. You could optionally also make some writes to the users home directory but this needs to be done through the appropriate environment variables.
I would get writing and see if there is anything special about a flash drive that the OS doesn't handle.