Portable versions?

Started by shnbwmn, May 29, 2016, 10:57:15 AM

Previous topic - Next topic


Hi there

Would it be possible to create portable versions of your software? I would like to carry some of these on my USB/ext HDD instead of installing each time. Also some computers don't allow installations, so in this regard a portable version would be really helpful.

Richard Moss

Hello, and welcome to the forums. I'm sure I've said some of the below before, but I can't remember if it was via emails or some other medium. So I'll dump all my thoughts here and use this as the reference in future. Apologies for the slight wall of text.

Firstly, a caveat. As our active products are currently all written in C#, they depend on the .NET runtime and so will never be truly portable in the way a single .exe C application could be. As this is usually baked into default Windows installs however, I don't really consider this to be a problem.

With that out of the way, I would very much like to create portable versions of the products. I actually used to offer two versions for each product build, the first being the full blown setup, the second being xcopy style zip files which just contained the product binaries and help, but no setup. I discontinued this approach as at the time I was creating these files, product builds were a manual process and it took extra time to create the distributions. In addition, they weren't downloaded very frequently and so it just wasn't worth the time.

Some months ago I finally switched all build processes to use a Jenkins CI server - now all the products are automatic built, tested, and deployments created - one being the existing setup, the other being the afore mentioned xcopy style zip archive. However, currently all those zip files are left alone and are not being pushed to cyotek.com the way the setups are as "nightly" builds.

Why? Mainly because it's slightly disingenuous. All of the older applications are based on one version of our application platform, where all settings are stored in the Windows Registry. Gif Animator is the only exception to this, which is built on a new application platform, and by default stores settings in XML files in the AppData folder. However, it has (undocumented) provisions for storing in the Registry or INI files instead, and to be able to customize the location of these files. So Gif Animator at least is on the road to portability, but as it still uses UI components from the old platform there is crossover.

I began the process many months ago of starting to update both platforms to allow the use of portable settings (probably INI files, XML is unfriendly for end users and JSON/YAML is probably too error prone for casual users) and to automatically set the locations of these based on where the executable is, as opposed to Gif Animator's well meant but ultimately undiscoverable methods.

Unfortunately, pretty much any time I try and do anything these days, I get a support request for WebCopy and end up spending an inordinate amount of time working on that. Not to mention, I don't want a horde of angry users with pitchforks chasing me because their settings have been lost! There's also the secondary consideration of shared data files and sample files which are currently installed to AppData.

So to sum up this wall of text (which I'm sure more than ever I've already wrote before  :-\), I can't offer true portable versions but the wheels are slowly in motion to make the software work out itself if it is portable or not and to read/write data files accordingly. However, due to ongoing support commitments, and some technical issues to do with the change itself, I can't offhand say when this might be finished.

Hope this helps, please let me know if you have any other questions.

Richard Moss
Read "Before You Post" before posting. Do not send me private messages. Do not expect instant replies.

All responses are hand crafted. No AI involved. Possibly no I either.


Thank you for the quick (and thorough) response  :)

Personally I (and probably most people) don't mind about .NET, so long as the settings are stored in the program folder. Otherwise it's good to hear that progress is slowly being made towards this.