MuseScore 3 is not available as a PortableApp on Windows

• Jan 11, 2019 - 13:51
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
Yes
Workaround
Yes
Project

The PortableApp format is open source (instruction here), so the portable build should be added to the AppVeyor scripts in the main repository to ensure it is always up to date.

PortableApps are self-extracting, so it could potentially offer a more convenient way to provide nightly builds than the 7zip archive currently used.

The PortableApp needs to be 32-bit. This:

Workarounds

  • Users on Windows 64-bit that do not have Administrator access can install MuseScore 3 using Scoop (via Scoop Extras). This uses the same 64-bit .msi install file that one would use to install MuseScore interactively. Administrator access is not required to install Scoop or MuseScore via Scoop. See MuseScore now available via Scoop on Windows for instructions.
  • The more adventurous Windows 64-bit users can try the development builds (a.k.a. nightlies) of MuseScore. This page contains full instructions to use the nightlies.
  • Users on Windows 32-bit: no workaround. (32-bit) MuseScore 2.3.2 PortableApp is currently the latest available MuseScore PortableApp.

Comments

Regression No Yes
Workaround No Yes

Well, both are in the sense that both don't need installation, but at least the development builds (AKA nightlies) are not in the sense that they do store settings on the machine rather than leaving no trace there and storing everything on the thumbdrive (or wherever the pottable app is 'installed') only.
This does make it a workaround, whether it is good enough is for the user to decide.
The regression is that for 2.x portable apps do exist

MuseScore 1.x and 2.x are available as a PortableApp, MuseScore 3 is not (yet), that is a Regression.

MuseScore 3 64bit is not possible as a PortableApp is by design, as far as I understood, but as soon as we have a 32bit MuseScore 3, a PortableApp is possible, isn't it?

In reply to by Bart.S

"Neither installing via Scoop nor the nightlies are portable."

However both fulfill the PortableApp usage case of the user not having administrator access to install the .msi version. I said as much in the initial post. That feature is what brought me to PortableApp to begin with, not the thumbdrive portability.

Unpacking an msi doesn't neccessarily make them run too.
If it does here, we have yet another workaround.

But yes, we still want a fully blown PortableApp! That's what this issue here is all about and why it isn't marked as fixed, by design, won't fix or closed

@Bart.S, not every installer can be unpacked that way: some (bad ones) are custom EXE files that you have no way of knowing what they will do without running it. Besides, scoop makes the process of extracting much easier even for the good installers.

@shoggle, you never know what an installer does without source code. Even the good ones can add, create, modify, delete move, download additional files (depending of your upgrade path). Extracting installers isn't recommended, they are installers for a good reason.

The point is that some can be extracted while others cannot, which is all that matters to people who need to run an app and do not have the necessary user account permissions to be able to run installers that modify the Windows Registry.

It has always been possible, even with a 64 bit executable. It is strongly recommended that portable apps are 32 bit, but it is not a strict requirement.

The real issues are:

  1. Adding the accompanying resources that go alongside the executable to make it portable.
    • Generic instructions are here.
  2. Creating scripts to do this automatically on AppVeyor.
    • Generic instructions are here.

The problem is nobody seems to have both of these skills already, or the time to learn them.

However, it doesn't necessarily have to be the same person that does both (1) and (2). If somebody is willing to do (1), and write step-by-step instructions for what they did specifically for MuseScore, then that would make it much easier for somebody else to do (2).

It's no good doing (1) without writing a guide, but the guide doesn't need to be overly detailed. as it can just link to relevant parts of the PortableApps guide. If there were any decisions that had to be made (e.g. why do something one way instead of another way) then the reasoning behind your decision should be explained in the guide.

For of all, thank you to Bart.S for the great work done up to now. I tried to dig into this problem and a lot had to be done to make it completely portable, and, most importantly, to verify what actually is written to the disk and the registry and cope with it.
I think I have almost completed the automation of building MuseScore in the proper format for PortableApps launcher and installer creators.
See here the changes:
https://github.com/AntonioBL/MuseScore/commit/f630bb377e9dc1a0c334a32c8…
The compilation simply requires launching msvc_build_portable.bat (after having properly set the enviroment for MuseScore 32bit msvc compilation), and then calling PortableApps.comLauncher ( https://portableapps.com/apps/development/portableapps.com_launcher ) and PortableApps.comInstaller ( https://portableapps.com/apps/development/portableapps.com_installer ) on the resulting MuseScore3Portable directory.
Here is the resulting PortableApps installer (based on 3.1 development build):
https://drive.google.com/open?id=1ePPmpoMrpmB-X24_PnqlSheqXV9LeYN8

I still have some doubts I need help about:
- I am not 100% sure that I managed to find all the files and registry keys written by MuseScore and Qt and redirect them to the portableapp folder (especially Qt ones); more tests are needed. I think in my build the crashreporter was not built, this must also be checked for leftover files and registry keys.
- I copied some file directly from MuseScore 2.x portable, for example the help.html, the readme and license file; should they be modified, and how? Is it correct how I modified the information stored in the .ini files?
- I named the app MuseScore3Portable, should it still simply be MuseScorePortable? In principle, MuseScore 3 is more than a simple update of MuseScore 2.x (most of the code was reworked).
- I found only .svg icon files for .mscz and .mscx, but in 2.x Portable the .ico files are present; are the .svg enough, or are the .ico needed?
- Should .mxl and .musicxml icons be added as well?
- I tried to disable WinSparkle, is anything else needed to disable the updater?
- A new splash screen with "Portable" and reference to portableapps.com is needed.
- Should also the "About..." be changed to include the "portable" name and reference to portableapps.com?
- Is it possible to automate the creation of the installer on Appveyor? I tried the compilation locally and found that it is possible to call the launcher and installer generator via command line with the target directory as argument, but they still open up a graphical window: will this give problems with Appveyor?
- Should we submit the test installer for reviewing at portableapps.com? On their forum?

Thank you for your help.
Ciao,
ABL

With regards to disabling WinSparkle/autoupdate, check the changes/settings needed for the Windows store, which too doesn't allow for autoupdates, BUILD_FOR_WINSTORE and then FOR_WINSTORE. I guess 4 of the 5 occurences of the latter in the code also would apply to your WIN_PORTABLE (the 5th is the one about the musescore.org website, where to get updates and about donations and should be OK to show in the PortableApp but apparently isn't in the Windows store). So yes, there's a bit more to do ;-)

(even if you didn't ask that question) Not sure how/whether to deal with the crashreporter, I believe your version doesn't use it (yet) due to be tagged as 'unstable'?

Thank you both for your comments.
@Jojo-Schmitz :
actually, I would like not to completely disable the checking for updates. I'd like MuseScore Portable to notify the users (if they chose so) when newer versions are available, even if it should not automatically download them. So I'd like only to disable building WinSparkle (and I think I did in the .bat file), but still have an update checking options, for both the program and the extensions.

@Bart.S :
- so, if the PortableApps.com Launcher Generator is used, the readme file should not be included? I don't know if their launcher generator can ba used for an automated creation of the launcher, since it opens up a graphical window (showing generation progress) even when launched from the command line with the app folder as an argument.
- ok, I updated the github branch (and corrected a couple of silly leftover typos I made)

@everybody :
- for what concerns the icons, in MuseScore source I could find only .svg files for the .mscz and .mscx file association; from what I read in PortableApps docmentation, they explicitly ask for .ico files. Is there a way to automatically create the needed .ico? Or is it possible to create them and put directly in the build folder for the PortableApps installation?
- what about the splash screen? How should it be modified?
I think we could simply replace, at build time, MuseScore default splashscreen (similar to what is done for the Nightly builds), so that it is dealt with within the application preferences instead of creating an additional splashscreen governed by PortableApps launcher.
For the current (2.x version) MuseScore Portable the splash screen is an additional splash screen shown by the launcher, while MuseScore default splash screen is hidden by the preference flags.
- for what concerns the crash reporter, I tried to use git submodule and define env variable CRASH_LOG_SERVER_URL, but I still don't think it is really working.
- I tried with a vanilla Windows 7 Virtual Machine (one of the trial versions given by Microsoft https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ ) and found that I have to install Microsoft Visual C++ 2017 Redistributable 32bit for this version to run, but this may depend on the fact that I am using msvc 2017 for my local compilation. I also had to add opengl32sw.dll to bin to avoid a crash at startcenter opening (but it still showed remote content as void black regions).

Here is the current code modification state:
https://github.com/AntonioBL/MuseScore/commit/60efb02b7e25142b24d62c4fd…

@Jojo-Schmitz :
Actually, not much progress, because I had three very intense months in terms of work and concert bands.
I am slowly writing the script to automate the creation of a portableapp with Appveyor.
My idea is to enable a build option (triggered by an environment variable) which builds and packs (with launcher and installer) a tentative PortableApp MuseScore to be submitted for approval at PortableApps.com site (from what I understood, this should be the correct procedure for a PortableApp).
Hopefully, I will have a little more time next week, when my vacations start :-)

@Jojo-Schmitz, one thing at a time ;)

@ABL, on your first attempt, I recommend doing the absolute minimum necessary to get it working, even if that means it is just a portable app and not a PortableApp (TM). We just need to see where the "magic happens" to make the binary self-contained. Niceties can wait for later.

Thanks for your effort so far!

Wonderful! Some observations (just that, not issues!):

  1. that version uses Qt 5.12.3, the official one uses Qt 5.12.2 (which too is available on AppVeyor, but needs to get asked for explicitly, via build/AppVeyor/before_build.bat). Shouldn't be a problem, just an observation and a difference to be aware of just in case...
  2. it contains some few outdated translations. the official one does too probably, still might be a chance to have them all updated?
  3. it has a different build number and commit SHA, nothing to fix, probably gets fixed once its build gets integrated with the 'official' builds. Just something to be aware of on support requests
  1. Indeed, Appveyor updated their Qt 5.12 version in the meantime. From what I understood, only Qt 5.12.4 is giving problem, so maybe this is not a dramatic change
  2. But a simple update triggered by the user should work. I didn't want to add other additional changes, since my plan is to port and adapt these changes to current master, once (and if) I have the green light from the guys at PortableApps.com and a "stable" and approved posrtable version. In principle, when triggering the x86 build for a release, a candidate PortableApp will be created, ready for submission for approval.
  3. Yes, I know: I could have tinkered with revision.h, but in reality it is a different build than the official release and as you said, better to know this information if bug reports are filed.
    Ciao,
    ABL