You are here

Upcoming .NET Support in the PortableApps.com Platform - Your Thoughts

6 posts / 0 new
Last post
John T. Haller
John T. Haller's picture
Online
Last seen: 54 min 38 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Upcoming .NET Support in the PortableApps.com Platform - Your Thoughts

I've been working on .NET support in our ecosystem for a little while. It's been a bit complicated settling on a proper way to do things so that it 'just works' for the end user and they don't need to worry about things. For context, here's the state of .NET support in the various versions of Windows we support:

  • Windows XP: No versions included; can manually install 2, 3, 3.5, 4; versions 4.5/4.6 unavailable
  • Windows Vista: Versions 2, 3 included; 3.5 automatically updated to; can manually install 4, 4.5, 4.6
  • Windows 7: Versions 2, 3, 3.5 included; can manually install 4, 4.5, 4.6
  • Windows 8/8.1: Versions 4, 4.5 included; versions 2, 3, 3.5 supported but must enable manually; can manually install 4.6
  • Windows 10: Version 4, 4.5, 4.6 included; versions 2, 3, 3.5 supported but must enable manually

What through things for a loop was the fact that Windows XP included nothing alongside the deprecation of .NET versions 2, 3, and 3.5 in Windows 8/8.1/10. This means there is no version of .NET that will run on every version of Windows, even if you only include Windows Vista or 7 and later.

Two things alter this landscape. First off, Windows XP is beginning its long sunset and apps have begun dropping support for it. We now support apps added to the PortableApps.com directory that only support Vista and up as well as existing apps that have dropped support for XP (FileZilla, for example). Second, you can compile a .NET app on one version and ensure it works on multiple versions. For example, KeePass Pro 2 is set to work with 2, 3.5, and 4 in its config file. So, it'll work out of the box on Vista and up without any changes. And it will work on Windows XP as long as .NET 2, 3.4, or 4 is installed.

That brings us to how to handle support in our ecosystem while balancing the needs of developers, users, and publishers. To that end, we'll be breaking .NET apps into two categories: universal .NET apps, and version-specific .NET apps. Universal apps are apps like KeePass Pro 2 that will work on 2, 3.5, and 4 specifically, meaning they will work on Windows Vista and later by default as well as Windows XP with .NET installed. Version specific apps are apps that are compiled for a specific version of .NET only, like 4.5.

In the platform, users will have 3 options for the .NET apps that will be shown to them in the App Store: none, universal, version-specific. I'm still settling on the appropriate verbiage to include with the selection. Universal will be the default selection.

As for the apps themselves, developers can set them internally to require the .NET framework or not. If they require .NET, they can indicate if they are universal or version-specific. If version-specific, they'll be able to select a specific version from the following: 2, 3, 3.5 client, 3.5 full, 4 client, 4 full, 4.5, 4.6. We won't be supporting 1.0/1.1.

When the user launches a .NET app, the platform will check if the app requires .NET. If universal, it will check to see if 4, 3.5, or 2 are installed, in that order. If version-specific, the platform will check to see if the specific version is installed and alert if the OS doesn't support it (in the case of 4.5/4.6 on Windows XP). If the correct version is installed, the app will be run. If the correct version is not installed, the platform will offer the user the chance to download and install it (or 'enable' it in the case of the lower versions in Windows 8/10). This offer will include a message about the install taking place on the local machine and requiring admin rights. The platform will then download the web-based installer for the specific version of .NET appropriate for their version of Windows. In the case of universal apps on Windows XP, version 4 full will be offered.

I think that paints a complete picture and offers up a good balance of ease of use for the end user as well as control for both the end user and the developer. I'd love any additional thoughts other folks have.

vf2nsr
vf2nsr's picture
Offline
Last seen: 7 years 5 months ago
Developer
Joined: 2010-02-13 17:10
Wellthought out Roadmap

In fact I can even follow it without a GPS

"If you buid it they will come"

“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss

Ken Herbert
Ken Herbert's picture
Online
Last seen: 3 min 44 sec ago
DeveloperModerator
Joined: 2010-05-25 18:19
Sounds like a good plan

That should cover the majority of useful .NET apps we will ever consider, while not exposing users to anything that will error (well, warn) without them opting into it.

xela2200
xela2200's picture
Offline
Last seen: 8 years 4 months ago
Joined: 2015-11-10 08:46
I would highly recommend that

I would highly recommend that you use other name than "Universal Apps." It might lead to confusion, as Microsoft calls Universal apps to applications that can run in different platforms (windows, phone, tablet).

https://msdn.microsoft.com/en-us/library/windows/apps/dn726767.aspx

John T. Haller
John T. Haller's picture
Online
Last seen: 54 min 38 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Not "Universal Apps"

Universal apps is a term used by multiple companies for multiple purposes. As is universal binaries. And multiple derivations. Funnily enough, Microsoft's "universal apps" aren't since they won't run portably and only work with the MS app store. As such, we'll be using something other than "Universal Apps" as it's used so much by so many different companies for so many different purposes it's a completely meaningless term as a proper name. Something like "Universal .NET Apps" vs "Version-Specific .NET Apps".

Sometimes, the impossible can become possible, if you're awesome!

xela2200
xela2200's picture
Offline
Last seen: 8 years 4 months ago
Joined: 2015-11-10 08:46
Yes, I do live in the .Net

Yes, I do live in the .Net world, and I forget there are other technologies.

What if you add some notification icon that shows next to the program name in the menu. If a program does not have all the requirements, a balloon popup on the icon could show the user what requirement is missing. Maybe disable the menu item, so it doesn't fire an application missing requirements.

The application can have its requirements listed on the .ini file with predefined keys -->

Either way when the start exec fires, it is going to have to check the computer environment. It can create a file of components available in the computer, and check them against the individual requirement files of the apps to generate the behavior on the menu items.

Regards,

Log in or register to post comments