I would like to have permission to publish your app on the Windows Store #1146
Comments
|
If you tell me how to wrap Git for Windows as UWP app, and how to upload it to the Store, I can try to incorporate that into my regular release process. |
|
@dgsimone15 what benefits are there to the porting process and making it into a UWP app? |
|
@shiftkey, |
|
For example you can see here some of the projects on which we started working: |
|
@dgsimone15 this really doesn't feel like it benefits the Git for Windows project but I'll defer to @dscho on whether it's worth investing time in. |
|
Thanks!!! |
|
Git for Windows will always stay relatively close to upstream Git, meaning that a one-time conversion is not an option. In that light, I think it may be easier to try to wrap Git for Windows as an APPX. If you can help us automate that, I would be very interested! |
|
Fantastic !! we invite you to visit our humble community, GitHub: https: //github.com/UWP-Open-Source-Community and Telegram: https://t.me/joinchat/AAAAAAwQXHEh77kozW9DFQ we have already converted some programs and believe That for voied your software there will be no problem ... when I found that the new version of Windows (Cloud) could turn Centennial Converted Software I immediately thought to you because your software could be really useful for the school. During the conversation there should be no big problems, only a few things should be able to cause a small retouch in the code ... the icons, but this is not difficult, just put the right icons in the right folder and write some lines of code (in our documentation will be possible Download a file that automates even more the process, it takes only a few minutes for that). They may bother log extensions and registry keys. Since the software runs in SandBox and not to dirty and degrade the performance of the operating system, have removed all the logs to the registry, this could be a small problem because it could cause the links to disappear (so need a little modification). So there are updates Automatic, since there is no alternative update system on the store (there may be but should be differentiated from that of Win32 software, which is very useless is uncomfortable since it is one of the main advantages of the store). In any case, The process does not require any great effort, and the result beyond these finesse is excellent. Clearly it's a Bridge, it's the beginning, it will not take native UWP native software, it will not enjoy huge performance benefits, it will not be able to take it to other platforms Windows 10, but the OS recognizes it as UWP and all the features that the OS have in addition are perfectly functional (See Slack, was brought via Centennial, you can answer Carlo, reset etc ...), and the ability to use the latest UWP Windows APIs. In any case you can see some of our Open source software (initial) porting On GitHub, the back of the documentation adds it here even if I always recommend watching Channel 9 or official Microsoft channels where the operation is well explained. Https://github.com/UWP-Open-Source-Community/Documentation/tree/master/DesktopBridge |
|
@dgsimone15, A few spaces and blank lines between the paragraphs of the UWP blub would not come amiss ;-) It was hard to read it all in one breath. Hope it all goes well. |
|
Sorry for my poor englesh😔 |
|
I still do not know how to start converting |
|
This is not a problem!! |
As Git is written (mostly) in plain C, we use the Microsoft Visual C Runtime. No MFC, no ATL, no .NET. Plain Win32 API, for backwards compatibility. Almost certainly not what you wanted to hear, right?
How does a Windows Store application differ from what we have right now (i.e. a stand-alone installer)? Like, specifically, e.g. is it like a .zip file with a certain directory layout a la NuGet, or is it more like an |
|
The windows store appx file is like a zip file that can be installed via the store or easily double click on it. It extract all the programs data to an hidden folder and can be moved between disks from settings. You can delete it without an uninstaller everything get erased without leaving any trace. All the data must be on the main hidden folder. The app will be updated directly via the store without installer and only the edited byte will be downloaded, so you don't have to download the entire new version. The app edit a copy of the registry so it doesn't slow the pc. |
|
No, indeed !! It's perfect ... unfortunately some software (eg those written in Java) can not be converted !! You should not have any problem with converting, as soon as I try to conjure myself (if I can) the software to see if there are any complications (even if they should not be). For the Online version the software has to be written with a frame above 4.1.6, but it is not a problem, because (as I have already said), the Online version is more a test, it is better to use the real software. |
|
this is just my two cents but i don't think a command line application would be good for uwp unless it's possible to create shims or symlinks to files such as git.exe. This is because it would break a lot of my powershell based pre-commit hooks which rely on files like git.exe to exist and be on the path. |
Whatever that Online version is, I cannot use it, because (as I pointed out) Git for Windows is not implemented in C# let alone uses the .NET framework. That leaves me curious as to what the "real" software is. I am still puzzled how I would start to convert, and what it would take to make an Maybe a concrete, tiny example would help me understand what it would entail to package some software and to publish it via the Windows Store. |
|
@dscho the instructions for manually porting a project are here - you create a manifest and run a tool against the files your installer needs, and can then test it locally to see how it performs. That's probably the quickest way to dip your toes into this. The debugging instructions might also be helpful, depending on how you prefer to debug Git for Windows. Lastly, the behind the scenes bit is probably very important to read, as it explains what your app can and cannot do once it's bundled in this way. |
|
@shiftkey thank you for your contribution. developer.microsoft.com/en-us/windows/projects/campaigns/desktop Sorry for my poor english |
|
+1 for having a published app in the Microsoft Store A benefit that I like to gain is that Microsoft Store in Windows 10 does automated app updates without user intervention in the background (I think they happen when the system is idle). I like to depart from having to manually check to see if I am running an out of date version of the binaries, followed by downloading and installing the latest version; and instead always get the benefits of the latest version without any effort or disruptions :) |
Okay, I'll bite. Just how much do you +1 this? Enough to put in a bit of energy and time yourself? Assuming you do, these are the issues that need to be addressed:
|
|
For the record, I would still be interested in helping with this project. I just cannot drive it myself, it will need a volunteer enthusiastic enough to tackle it. |
Hi dscho! I'm pleased that you are interested, I don't know what is your plan for convert Git… in my opinion the best way is to convert Git with GUI or a client with open license. |
I guess I should start to wonder how Python did it instead.
Right. And that way, I can also completely forget about the MSYS2 stuff, such as the Bash or Perl interpreters. Oh wait, but then Git cannot fetch submodules anymore. Or bisect. Oh well, people will survive that, I guess... 😜
Right, and it also distracts us from the original topic of this ticket: how to get Git for Windows into the Windows Store. Don't get me wrong, I appreciate your desire to help, but I fear that we're past the stage where we wonder what we want, we already have a pretty good idea what we want, now we only need volunteers who can do it. |
I guess we'll need to follow the instructions at https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-manual-conversion |
If it makes it easier to push to the store, my two cents would be to just go with one pre-set configuration that is simple. I like how the Python release includes a disclaimer "NOTE: The Microsoft Store release of Python 3.7 is primarily for evaluation purposes, and not all features are guaranteed stable". For me, what they have in the store was good enough to use, since each once in a while I may need to run a python script in Power Shell, and don't want to have to think about keeping the python compiler up to date. I don't know what data you have on feature usage from the community. I can tell you that for my use-case the only reason that I install git in Windows is that Visual Studio Code wants the git executables. I use VS Code as my code editor for all SW development, and I pretty much do all compiling, execution and git operations in Windows 10 WSL/Ubuntu. In the WSL side, |
|
Whereas I’m in Git Bash all the time. 😉
…Sent from my Windows 10 phone
From: Yashar Fakhari
Sent: Monday, January 6, 2020 22:05
To: git-for-windows/git
Cc: Subscribed
Subject: Re: [git-for-windows/git] I would like to have permission to publishyour app on the Windows Store (#1146)
what are the options to configure a Store app? We have quite a few setting that we offer to the user while installing, we cannot just drop that part of the installer.
If it makes it easier to push to the store for the first time, my two cents would be to just go with one pre-set configuration that is simple. I like how the Python release includes a disclaimer "NOTE: The Microsoft Store release of Python 3.7 is primarily for evaluation purposes, and not all features are guaranteed stable". For me, what they have in the store was good enough to use, since each once in a while I may need to run a python script in Power Shell, and don't want to have to think about keeping the python compiler up to date.
I don't know what data you have on feature usage by the community. I can tell you that for my usecase the only reason that I install git in Windows is that Visual Studio Code wants the git executables. VS Code is the UI that I use for all SW development, and I pretty much only use Windows 10 WSL/Ubuntu for compiling execution and git operations. In the WSL side, apt-get takes care of updating git, but in the Windows VS Code side, I have to manually redownload and install the msi to keep the installation up to date. As far as GIT GUI, in my particular case, I don't use it since the command line tools and VS Code UI are sufficient. I have never used Git Bash in Windows either.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Just stumbled upon this, because the update check often doesn't check for updates for me, so I was wondering if git could come to the MS store. Main reason for me would be the automatic updates, whenever a new version releases. |
|
@totkeks feel free to help! 😄 |
|
I just went through the exercise of building an MSIX installer for the Julia programming language and publishing it in the Windows Store. So at the moment I have a pretty good understanding of how to create an installer for that and I'd be interested in taking a stab at doing the same for git. @dscho, I take it that you are still interested in that, right? I could probably do most of the steps myself, but I'm pretty sure I would need some help when it comes to specific questions how git for Windows does certain things, how this can be integrated in the normal build process etc. Before we embark on this, it might make sense to just make sure everyone agrees with some of the implications this would have, as some things would be quite different from the existing setup experience. Here is the list of things that I can come up with right now:
I think those three things are probably the most drastic changes. I'm sure we would discover other things down the road, though... My initial stab would be to start from the portable version, and just try to package that as a MSIX installer. Does that sound reasonable? One thing that would help me is to understand which file and registry locations git normally modifies. Does it ever write into its own install folder? Probably not, right? Is that also true for the portable version? Are there any locations under %APPDATA% where it stores stuff? Finally, I think it would make sense to integrate that into some sort of Github Actions setup right away. Is https://github.com/git-for-windows/git/blob/main/.github/workflows/git-artifacts.yml the right place to integrate that? I looked at that, but don't fully understand it. Is there some stage that outputs an artifact that is essentially the portable installer? If so, I could just add another stage that takes that artifact in and then creates the MSIX installer. For Julia I created a Github Workflow that goes all the way and deploys the MSIX to the Windows Store, so there is essentially no manual step involved at all (see here). The way I set that up is that whenever one pushes a git tag to the repo, it will trigger the jobs that push things to the store, but the jobs that do the push to the store are gated with environments, so that the maintainer can very easily "release" a given build to the store with one click. I also have it setup so that there are different flights in the store (think of this as channels), i.e. one dev channel, a release preview channel and the "real" release. So whenever a MSIX is created, each of these channels is gated by its own environment. Not sure whether that kind of setup would fit into the existing release process here, but if it does, it makes for a smooth experience. And finally, we would have to register all of this with the Windows Store itself. That step can be.... interesting, to put it mildly. It took us many, many weeks to fight our way through the various intricacies of the Microsoft identity/store/partner center situation for Julia... I think @dscho if you are generally interested in this whole project, it might make most sense that you and I connect directly and I can try to let you know how we in the end maneuvered through that piece of the puzzle for Julia. Also, before I start to actual build something, if anyone has some other questions what all of this would imply, or how it would work, please bring them up now! I'd be more than happy to try to sort those out before we actually put time and effort into this :) Oh, and this of course would also help with #3307, because git would have app identity if it was distributed via the store. |
Not great, but not the end of the world.
I don't think that's a big issue. Since that seems to be the way all apps distributed via the windows store behave, that's probably the behaviour users expect.
We only touch appdata for the Windows Terminal fragments and the registry implications should also be mostly fine. Some third party applications might use the registry to discover a Git for Windows installation, but I think there are simple ways to query the system for installed store apps, so that shouldn't be an issue.
If we have to go with defaults anyways, then I guess portable git is a good starting point.
Various registry locations, but AFAIK not in portable git.
That can happen with things like
Yes.
We do create the Windows Terminal profile fragments there in a per-user install and store some files under
Does that mean a select few executables (likely |
|
@davidanthoff thank you for the offer! I am fairly interested in this, even if I must caution that we still have Windows 7 users and therefore cannot exclusively distribute Git for Windows via the Windows Store. A couple answers in addition to @rimrul's: Git itself does not write into the registry, like, ever. The Git for Windows installer does, and some 3rd-party applications use that information to detect the presence. Likewise, we never write into AppData. But we write into the home directory (which is usually the same as About MSIX: we do have (stalled) beginnings of an MSI installer (relying on WIX). Not sure whether that helps anything.
During the configuration steps of the installer, that's exactly what we usually do. Likewise, when we configure Git Bash to run in ConHost instead of MinTTY, we modify the resources of Also, to use Cygwin's pseudo TTY support, we write If there is any use in consolidating these two to also read from I'm just not sure how we allow our users to discover how to configure things. The installer is a nice, central place to do that. With Windows Store applications, that is not the case. (And I am not prepared to spit out information when you run
For the moment (and probably at least until GitHub workflows grow support for re-running just the failed jobs), I won't go forward with it, but yes, my long-term idea was to port the Azure Pipeline we use to build the Git artifacts over to a GitHub workflow, and This wiki page has more information how Git for Windows' release process looks like. |
|
Thanks for all that info! Here are some responses on various topics:
The terminal fragments are no problem, there is a MSIX way of doing that, and we've used that for the Julia installer as well.
I looked through the registry things the installer writes, and there seemed to be three types of things: 1) generic setup info (where is it installed etc), I think we'll probably lose that, 2) font configuration stuff, again not sure how we could do that, but maybe also not the end of the world, given that defaults tend to get better on Windows? 3) file associations, those can be done declaratively in MSIX, so I think that should be easy.
In general, writes into the install folder itself are not allowed with MSIX, i.e. we'll have to think of the entire folder that we deploy as read-only. So that probably requires some thinking... One question is what
That should be no problem.
There is no patching happening, it is just that every binary that is distributed via a MSIX will run with app identity automatically.
Yes, that makes a lot of sense!
The only thing MSI and MSIX share is the first three letters of their names, other than that they are completely different technologies with no overlap at all :)
Yeah, that is probably a pretty central question. I completely agree that we can't spit out random info at start of
Ah, good to know! So I started working on this yesterday (before I saw your message) by integrating it into the GitHub workflow and got it to a point where it does produce a MSIX installer. One benefit for now is that I can actually trigger these workflows relatively easily in my fork, so maybe I'll for now just continue hacking away on that, and then if we feel it all works we try to move it over to the Azure pipelines? My current status is that this build did produce a MSIX installer for all three platforms (x64, x86 and arm64). But it isn't signed yet, and one can't really try it without that. I think I'm going to just sign with a self issued cert for now, just to keep things moving forward, and once I'm at a point where I have an installer that I can try locally on my system and that works we can work on the next steps. If anyone wants to see where I'm working on this, it is git-for-windows/build-extra#366 and https://github.com/davidanthoff/git/blob/b83ac2df699dbc0bd92a08b70853917222c68aaf/.github/workflows/git-artifacts.yml#L519, essentially. |
|
Signing the MSIX turned out to be a bit more complicated. In particular, it seems that there is one file in the portable archive ( I think at this point we have two options: 1) we could try to setup one of the pipelines so that it creates a signed MSIX automatically, or 2) we could go right away to putting the installer into the Windows Store. In general, there is no way to install (even for testing) a MSIX directly that is not signed. One can create a self issues cert (that is what I did), but the whole workflow is cumbersome to no end, in particular if one wants to create say a version and have some other folks try it out. So I think if we were to try to create signed MSIX installers, it would only make sense to set the pipeline up in such a way that the MSIX gets signed with @dscho's certificate. The other option is that we start to push the installer into the Windows Store. In that case we don't have to sign it, so that part is easier, but we do have to fight our way through account creation etc. for the Store. We could publish the MSIX as "unlisted" in the Store, which would mean that only folks with the direct link to the store listing could install it, i.e. that would allow for a almost non-public test phase to just figure things out. I think my vote would be that we try to get the store setup up-and-running right away, but I'd also be happy to help with the other option. I tried to understand the release process, but at the moment the various interactions are still a bit of a mystery to me... So I think I'll probably need some help with integrating what I did so far properly into the existing release process. @dscho I'm almost wondering whether it might be easiest to sort some of these one-time setup things out on a zoom call or something like that? Same for the next steps re the store: you'll have to do most of those, the entire thing is super brittle and so it might make sense if we chat and I just relay how we got around those things for Julia... If that sounds good to you, you can see my email on my Github profile and connecting there would be easiest. Oh, one other thing: is there an SVG version of the logo/icon that we would want to use? If so, I can use VS to create all the different resolution PNG files we'll need for a store submission with it. |
Excellent. I meant to suggest going forward with the GitHub workflow for exactly those reasons.
Yes, this is a problem. I guess
That's probably the best option we have. And there is already precedent with the Git Credential Helper Selector: It is a small program written in C that offers a simple GUI. We could copy/edit this, also make it part of the
Hmm. This file comes from GCM Core: $ pacman -Qo /mingw64/libexec/git-core/WebView2Loader.dll
/mingw64/libexec/git-core/WebView2Loader.dll is owned by mingw-w64-x86_64-git-credential-manager-core 2.0.475.64295-1@mjcheetham any ideas?
I am very much in favor of going the simple route. Do MSIX files get signed with a regular code-signing certificate? Since you mention
This is great! Could you open a PR at main...davidanthoff:main? That way, we can efficiently collaborate on this and have a record.
Or we do both. Question is: do we simply run
That sounds good. I'll shoot you an email.
There is: https://github.com/git-for-windows/build-extra/blob/ca0750cac61e79517dd29ce4a945e92af7871399/git-for-windows.svg. I would, however, want to set up some automated build to render the |
|
We could add a compile time dependency on
Looking at this, png seems to be the only option. |
Or we could use the much more light-weight option to use a node.js step: npm install -g svgexport
MSYS_NO_PATHCONV=1 svgexport git-for-windows.svg g.png 0:0:128:128 2xThis will output a
Thank you for digging this out. |
|
I opened a new issue #3332 to track remaining TODOs. I wanted an issue that I own so that I can keep the first post updated with a running todo list. |
|
@dscho now with the release of Windows 11, you can submit traditional Win32 applications to the Microsoft Store - https://developer.microsoft.com/en-us/microsoft-store/desktop-apps/. Can you submit the current version to the Store while the MSIX installer is being finalized? |
Does that work for Windows 10, too? If not, I find it quite limiting, i.e. not a lot of return for the quite substantial hassle of first paying to get a developer account on the Microsoft Store, just to be able to then spend more time on both figuring out how to publish and maintaining yet another way to run Git for Windows, with its own challenges. |
There's a little 3 minute video at the bottom of the page explaining the process to upload a new application for the first time. From 2:03 to 2:17 there is a Checkbox visible at the bottom of the screen that's labeled "Let Microsoft decide whether to make this application available to any future device families in addition to Windows 10 Desktop". Under the video it links to aka.ms/newstore which has another video at the top of the page that talks about "You can bring win 32 applications, no matter [...] how you package your applications. [...] The new Microsoft store will be available on Windows 11 and Windows 10". I'd interpret both of those videos to mean yes, it works on Windows 10. Do note that there is currently a waiting list to join this "limited public preview", though. There's also the slight problem that the Microsoft store would want to run the installer silently, which means we can't offer those users any customization through the installer. |
|
I read the plan was for the "new" store, which is the default on Windows 11, will come to Windows 10 once it is out of preview. I also read somewhere that the Win32 installs will not have auto-update capability. Sadly, someone at Microsoft has forgotten the security, privacy and reliability benefits of UWP. And, forgot why do-whatever-they-want EXE and MSI installers were not allowed in the Store. The store WAS more than just a list of installable apps. By requiring legacy apps to be APPX packaged or better, MSIX packaged UWP apps, it got us closer to the security and privacy model that Android and iOS have. |
|
Closing as stale. |
Hi, I'm part of the UWP Open Source Community (https://github.com/UWP-Open-Source-Community). Our intent is to take Win32 Open Source applications and convert them into UWP apps through the Windows Bridge (Project Centennial).
We like your app and that's why we decided to convert it.
In case you would like to take charge of this app and publish it yourself on the store (make us very pleased) contact us the first possible please! Otherwise, we may be responsible for publishing your app.
If you do not want to take over the publication on the Store, can you give us permission to do so?
Sorry for my poor English.
Thanks for your help.
The text was updated successfully, but these errors were encountered: