MuseScore 3 is not available as a PortableApp on Windows

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?

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:

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'?

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…

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?

@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!

See https://portableapps.com/node/60879 for the beta testing of MuseScore 3.2.3 Portable.

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

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

Try again, I posted a wrong link at first

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.