MuseScore 3 is not available as a PortableApp on Windows
Reported version
3.0
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
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:
- Ensures it can run on both 32-bit and 64-bit Windows.
- Requires solving #281539: MuseScore 3 on Windows 32-bit is not available
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.
Fix version
3.5.0
Comments
Neither installing via Scoop nor the nightlies are portable.
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
Regression? I would say no MuseScore Portable 3.0 is by design.
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 Neither installing via Scoop… 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.
In reply to "Neither installing via… by Riaan van Niekerk
Without administrator access every installer can be opened/unpacked with software like 7-zip. That doesn't make an application portable though.
Almost none of the following points would be fulfilled:
https://portableapps.com/about/what_is_a_portable_app#guidelines
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
one step forward, see https://github.com/musescore/MuseScore/pull/4583
@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.
We do have 32bit version now (and since a while, MuseScore 3.0.3). Wouldn't that make a PortableApp possible?
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:
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 thenFOR_WINSTORE
. I guess 4 of the 5 occurences of the latter in the code also would apply to yourWIN_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'?
In reply to For of all, thank you to… by ABL
Some answers @ABL:
-The readme was for my custom launcher. It seems you're using PortableApps.com Launcher with less features so the readme should be adjusted
-I would continue naming the app MuseScorePortable
-All the icons are needed for PortableApps.com installer and menu. See https://portableapps.com/development/portableapps.com_format#icons
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…
In reply to Thank you both for your… by ABL
A readme is always nice if it's correct. It doesn't make sense to include my readme which describes (INI-) options that you don't have with PAL.
One splash screen is enough. I just added a second one because I couldn't modify the built-in splash. Resource hacking as suggested by lasconic didn't work (https://musescore.org/en/node/8637).
@ABL: I also had to add opengl32sw.dll to bin to avoid a crash at startcenter opening see my PR https://github.com/musescore/MuseScore/pull/4928 and the corresponding issues for it, #285174: MuseScore Crashes Immediately on Startup on Windows and #287283: Version 3 will not open startcenter because OpenGL not supported
Is there any progress here?
Question came up again in the Facebook user group: https://www.facebook.com/groups/musescore/permalink/3425460994146861/
Came up again in https://musescore.org/de/node/292672
Came up again in https://musescore.org/de/node/292829. @ABL any progress on this?
Reminder to self/Jojo/anyone to remove
The latest version of MuseScore Portable is v2.3.2.
from
https://en.wikipedia.org/wiki/MuseScore
once this issue is resolved.
@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 :-)
It would really help to (also) retrofit those changes to all previous 3.x builds, I'm really missing those, for debugging purposes.
@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!
In reply to @Jojo-Schmitz, one thing at… by shoogle
See https://portableapps.com/node/60879 for the beta testing of MuseScore 3.2.3 Portable.
Wonderful! Some observations (just that, not issues!):
Ciao,
ABL
In reply to Indeed, Appveyor updated… by ABL
To repeat Shoogle’s sentiment, “even if that means it is just a portable app and not a PortableApp (TM)”,
would it be possible to release a portable app of MuseScore 3.3 with tech preview / beta / unofficial portable app wrapper and modifications, hosted elsewhere until it is accepted as up to standard by PortableApps.com? This works on the assumption that the current state of the portable app is usable enough, users would be ok use a portable app that mostly works (if it is not currently on feature parity with the previous official 2.3.2 version).
The AppVeyor builds now use Qt 5.12.5 BTW...
Came up again in https://musescore.org/en/node/296255 (and quite a few other times)
and again in https://musescore.org/en/node/20562#comment-961847
See https://github.com/musescore/MuseScore/pull/5508
Came up again in https://musescore.org/en/node/299765
I've just been told that there is a 3.4.1 PortableApp at https://numerico.altervista.org/ALBERCLAUS/en/musescore-v3-4-1-portable/, apparently 32bit and 64bit. Not sure about how save this is
Opening the links tells me that it is for
Windows Management Framework 3.0
which is something different. Searching for musescore via the search box, the only match I get is the regular Microsoft Store version of MuseScore.
Try again, I posted a wrong link at first
our PR #5508 is on MuseScore 3.5 Alpha PRs to be merged #5960
We are so close!
PR #5508 did not get merged in time for Alpha, spilled over to MuseScore 3.5 Beta. PRs to be merged #6027
Fixed in branch 3.x, commit 23382ccf34
fix #281616 : compile for PortableApps.com
Fixed in branch 3.x, commit 199555f5b8
_Merge pull request #5508 from AntonioBL/winportable
fix #281616 : compile x86 Windows PortableApp at release time_
Automatically closed -- issue fixed for 2 weeks with no activity.
Hi all. Even though this particular issue is resolved, I would like to direct your attention to
#309861: MuseScore 3.5 is not available on the PortableApps.com site & Platform application
for your input. Even though this may be a marginal usage case / requirement, and the "Portable version" released on MuseScore downloads should cater for the large majority of users who need a portable app, I still think it can't hurt to ask those that cared about the main issue, and get the issue on record.