Store release

[jphellemons]

Will you release the app for the Microsoft/Windows Store? That would make it easier for me to keep up to date and test it.

[Biswa96]

This issue was solved in this #5. This repository is for native x86/x64 excutable.

[jphellemons]

Well issue #5 is more about UWP and I'd like this as it is, but then in the store. With the desktop app bridge. So that I can leverage the auto update feature, that would be 🥇

[jphellemons]

Not the manual packaging https://docs.microsoft.com/en-us/windows/uwp/packaging/create-app-package-with-makeappx-tool I was referring to this https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-run-desktop-app-converter :-)

[NazmusLabs]

This is a great idea because it'd solve #82. It'll remove the need for the dependency and also ensure security by handling auto updating.

I think we should not worry about building installers. We should use chocolatey and Windows Store for automated installation and updating, are perhaps the portableApps platform as well. For users who want more control, they can continue to use the zip platform, and those people would likely be "power users" enough to manually update the applications as needed.

[ZanderBrown]

Problem with publishing to the store (esp if done as MS Corp) is that WinFile will be much more 'discoverable' and people will expect a certain level of support but the project is intended more as a novelty / 'poweruser' utility

:+1: for zip distribution though

[NazmusLabs]

Windows Store already has lots of free and open source software. They reflect support to community forums.

Plus, it's really not something I'd worry about, as it's mostly something advanced people would bother downloading. Windows Store also have other advanced desktop file managers, and by reading the reviews, you can tell that the users are pwoer users.

Besides, Winfile won't be compatible with Windows 10 S Mode without this.

[Biswa96]

Some queries:

1. Will the winfile executable be compiled without VC runtime DLL in the Appx package?
2. The project file (.vcxproj) should be edited (i.e. change SDK version) to Visual Studio 2017 for Appx solution file (.sln).
3. The solution file should be out of src folder.

[NazmusLabs]

@Biswa96 APPX packages work like snap packages. The dependencies will be included with the package and the underlying OS will he left untouched. That's why store app packages are so much superior to regular exe installs. They self contain all registry, DLLs, dependencies, etc. It's also why it's possible to uninstall APPX packages completely without leaving behind cruft. It's why you can install and uninstall 100s of store apps and the system remain pristine.

[NazmusLabs]

@Biswa96 I did answer the question. The DLLs should be in the package.

[Biswa96]

This store version should be in different branch of this repository. What do you think?

[NazmusLabs]

@Biswa96 I don't think so, especially because there should be little to no difference between the store and the normal release. We'd usually need a fork if the actual code is different. In this case, it's just the deployment method that's different.

The exception is if you want to create a separate solution and VS project for the store release. Centennial allows existing VS Solutions to spit out appx packages. I think it'd be better if all the output methods are included in the main solution, from Chocolaty, Store, and any other distribution method. So that way, everytime there's a new release, the solution can just deploy all the types of releases, from zip release to GitHub, Appx, release, and one for chocolatey.

But you or others may have another opinion as to why a separate solution or branch is necessary, and if so, let's hear it!

[NazmusLabs]

You are right. I forgot that this was set to VS2015. Ignore my previous post then.

I am interested to know what others think.

[craigwi]

A Windows store release of the x86 and/or x64 versions, supported by our community makes sense.

Did someone here reserve the app name "Windows File Manager"? I reserved "WinFile".

[ZanderBrown]

@craigwi I don't believe anyone outside Microsoft is allowed to have an app containing 'Windows' in the title

[NazmusLabs]

@ZanderBrown no that is not entirely true. The name Windows in the title is checked on case by case basis. You cannot have a title that implies that your app is an Official component of Windows released by Microsoft. You can have the Windows in the title if it is used in ways that makes it clear that it not a component of Windows.

For example, this is allowed: OpenShot Video Editor for Windows

But this NOT allowed: Windows Video Editor

This is allowed, and is a real world example: Cities Skylines Windows 10 Edition

Anyway, whoever reserved the name Windows File Manager is probably breaking the rule, if it's that entity is not Microsoft. In that case, the Store and legal team needs to release the name on the grounds of trademark.

@craigwi did your reserve it on your personal dev account or a company dev account? It should be a company account that is independent from your personal MS account so that in the future, if you wish to move on to different projects, it would be simple to just hand over the account to whoever is heading this repository.

[craigwi]

I used my personal (non MS) account to try to reserve it. Agree on the point about not using my MS account to enable hand off in the future. I sent a note internally to try to track down who might have that name or the rules for using it.

[craigwi]

Good news: the Microsoft Store team released the name Windows File Manager and I reserved it (on my personal account).

[craigwi]

As you probably know, a Windows Store submission requires a signed binary. The signing key needs to be trusted by Windows for a smooth install experience. A self-signed cert doesn't seem to provide that.

I contacted the OSS folks in Microsoft and they said that if the WinFile project follows our Secure Development Lifecycle (SDL) I can get the binary signed by Microsoft's key. The work to meet the SDL is not trivial and this approach doesn't handle the case if/when, in the future, the project transitions to a non-Microsoft person.

How are other OSS projects that ship through the Windows Store signed? Any other thoughts?

[Biswa96]

How store manage different binary x86 and x64?

[craigwi]

They would be packaged in the same .appxbundle / .appxupload and thus distributed together.

[NazmusLabs]

@craigwi there are lots of open source projects in the Windows Store. Take the Krita graphics editing app, for example.

They, like other OSS, have simply created a company Windows Store account and uploaded the package through that account. Windows Store will do the signing and no complicated process is necessary. VLC Media Player, for instance, is published in the Store using its company account, VideoLAN, and the experimental version of VLC for Windows 8 was published by VideoLAN's research department, VideoLABS.

So, if there is an existing Microsoft Open Source company account where they release apps that are not from the WDG group, we'd be able to use that. Or, perhaps, just create an account for publishing open source Microsoft apps, including this one any potential others in the future. Having a company account dedicated to only releasing open source projects from Microsoft such as this can allow future OSS MS apps get on the store quickly, as the hard work of establishing a system would have been done thanks to this project.

@Biswa96 The Store accepts multiple packages for an existing app and will install the appropriate one based on the client's system specification. And it's not just architecture. The Store will accept different versions, architectures (x86, x64, ARM) and even completely different app packages targeted towards different systems. For instance, if, say, version 6 of an app only supports Windows 10 RS3, you can upload a version 5 of the package that supports Win10RS2 and older, and another, version 4, that supports Windows 8.0. The Store will detect the OS the customer is using and give you the appropriate package. Furthermore, you can even do things like have a Win32 desktop version for PCs and a UWP version for phones and HoloLens, and a C++ Xbox One build for the Xbox. These completely different app packages, even if they have zero code in common, can be submitted to the same store account and the Microsoft Store app will download the appropriate package, as necessary.

For example, XBMC Kodi, an open source media center application, will download the Win32 version if you are on the PC and will download a UWP build if you are on the Xbox One.

[Biswa96]

Now I think there is no need to make a seperate branch. Just make another solution file for Appx package. What do you think? I've make an Appx package. Someone want to test it??

[NazmusLabs]

@biswa96 actually, that's not a bad idea at all. Have a solution file for vs2025 (as it exists currently) and another targeting VS2017 that has the additional configs to deploy an Appx package.

In fact, the timing couldn't be more perfect. Visual studio very recently got an update that allows us to easily build APPX packages for Win32 projects right from the IDE without going through complicated hoops like the desktop app converter, manual package creation, or relying on third party tools like InstallShield. UWP VS projects could deploy Appx packages, and now, so can Win32 ones.

Also, since I only have VS2017 running, I couldn't even open the solution file without being forced to upgrade then solution to VS2017. I assumed I'd be able to just install some older SDKs to be able to open the solution directly in VS2017. But VS told me to either upgrade or install an entire copy of VS2015 with C++ support.

If there is a way to open the solution in VS2017 without needing to covert it, do let me know, thanks!

Because of this, I copy the cloned repository to a sandboxed location before opening VS to build the application for fear of accidentally changing the original solution in one of my cloned repositories.

By having a VS 2017 solution, people with VS2017 can use it to quickly open and build the application and also generate Appx packages while people still on VS2015 can continue using the original solution file.

[Biswa96]

I know both processes.

[NazmusLabs]

@Biswa96 are you referring to the Appx package generation or opening VS2015 soln in vs2017? I remember that you, at least I think it was you, mentioning that you knew how to generate Appx packages for Win32 files. So it makes perfect sense that you would know multiple processes for doing this.

As for me, I never gotten around with building app packages myself, so having it now part of the IDE is a big help for me.

[craigwi]

I'm getting the store version of WinFile ready. I recall someone created a high res icon for WinFile, but I can't seem to find it. Anyone know where that is?

[Biswa96]

I'd suggest to use a SVG file then convert it to multiple PNG files in any photo editing tool. Visual Studio generates blurry images during conversion from high resolution to low resolution.

[thecatkitty]

@craigwi Perhaps are You looking for #33 ?

Or https://en.m.wikipedia.org/wiki/File:WinFile_Icon.svg

[craigwi]

I found what I was looking for in https://github.com/Microsoft/winfile/pull/73 (inside the ico file). Thanks @Techokami.

[craigwi]

Curious. Someone already released a version of this code: https://www.microsoft.com/store/productId/9ND2N28DX22H. Yours for only $10.99. Their market will dry up soon...

[ZanderBrown]

@craigwi I made that SVG!

/me realises this isn't really an appropriate use of a GitHub comment

[craigwi]

An update: when I submitted a build of WinFile to Microsoft for approval using my personal account, the store team (a different part then before) insisted that I use my Microsoft corporate account instead. So I have gone through that process and submitted a build using my work account. Hopefully it will get approved soon. Then I can test it. Then fame and glory! :)

[craigwi]

The first submission was approved! I'm about to submit a second one with the ARM build (which I didn't have in the first submissions), updated icons and an updated version number scheme (yyMM is too constraining for submissions to the store since they require the fourth part of the version to be 0).

Anyway, I would like up to 5 people to help test before I release it to the public. Send your email address to me in email (craigwi@seanet.com) and if you are one of the first five, I will contact you via email to know when to test. I am esp. interested in having you help if you can verify the ARM version.

[craigwi]

Store release is done. Web link is https://www.microsoft.com/store/apps/9P7VBBBC49RB.

Version is 10.1.3 which has the same features as the previously released version 10.0.1901.1.

Do report issues with the store release and create new issues entries, not reuse this one.

[ad43]

After downloading from the store and installing, I was unable to leave a Winfile review on Microsoft’s Store.

I tried in Edge, IE and Chrome, all using my regular Microsoft account. The page says that the product is installed but that I "cannot rate or leave a review as I do not own the product".

Anyway, I'm over the moon with it, well done. Chris