MSI Installer upadate?

[Patrick Connor]

1 minute ago, Patrick Connor said:

In that case I will find your ticket myself and escalate it.

Nope I cannot see anything that uses your forum email address in the Affinity Store or the Contacts database, sorry.

4 minutes ago, stuck said:

What makes you think they will help if I try again?

Unless you have made progress or have another way of paying, nothing I guess. This is not my area of expertise

[stuck]

21 minutes ago, Patrick Connor said:

Nope I cannot see anything that uses your forum email address in the Affinity Store or the Contacts database, sorry.

@Patrick Connor

That's because the email address of my Affinity Store account is different to the one for my forum account.  I have sent you a private message (subject 'failed transaction') giving you my Affinity Store email address.

[thegary]

@Patrick Connor

THANK YOU to everyone at SERIF for making the MSI Installer and Listening to the users.

It goes along way. Its very much appreciated.

2.0.3 of Designer MSI was pretty good. Just installed all three apps of 2.0.4 and look forward to continue on with the software.

Thanks

Gary

[rvst]

@Patrick Connordo we need to uninstall the test MSI v2.0.3 variant before installing the v2.0.4 MSI or will it install over the test version cleanly?

[Patrick Connor]

13 minutes ago, rvst said:

Do we need to uninstall the test MSI v2.0.3 variant before installing the v2.0.4 MSI or will it install over the test version cleanly?

Run the 2.0.4 installer and the 2.0.3 will install cleanly over, so 2.0.4 will install to the same folder, without asking (it will update)

[913]

What is MSIX AND MSI uninstaller , what's its use and it's Advantage .

Also describe workarounds

Edited January 27, 2023 by 913

[walt.farrell]

20 minutes ago, 913 said:

What is MSIX AND MSI uninstaller

Uninstaller? Or did you mean installer?

[lphilpot]

34 minutes ago, 913 said:

What is MSIX AND MSI uninstaller , what's its use and it's Advantage .

Also describe workarounds

Others can correct me if / where I'm wrong...

MSI (unsandboxed) is one of the standard Windows installers as you've used in the past. They generally (but are not required to) put their files under C:\Program Files (for 64 bit apps) or C:\Program Files (x86) (for 32-bit apps). "MSI" refers to Microsoft Installer and the file is actually a database that the installer itself uses to install the app in question. If the file extension is EXE, that's just a standard executable file which wraps up the MSI and is sometimes called a bootstrapper as it assists with install options and compatibility. Both MSI and EXE use the Microsoft Installer services - One triggers it from the "document" side, the other from the "executable" side. This has been the standard means for installing Windows programs for years.

MSIX (sandboxed) is the installer for an application that's packaged as a sandboxed application. "MSIX" refers to Microsoft Installer Extended" (I think). These programs install under C:\Program Files\WindowsApps and have much more stringent security applied to them by default.

In both MSI and MSIX cases the underlying application files that are installed are the same, it's just a difference in how they're "delivered" to your computer, where they're installed and other implications of the difference of install / operation methods.

Pros / Cons (I'm sure there are more and there will be debate on whether they're Pros or Cons)

• MSI Pros - It's the de facto standard for installers, is well-known, well-understood and reasonably safe assumptions can be made about the installation (from a technical viewpoint). Third-party interactions are much easier due to those assumptions generally being correct. This last one is primarily what has driven the appearance of the Affinity 2 MSIs.
   
• MSI Cons - Application security is up to the application itself for the most part, there's no default (i.e., OS-level) update mechanism so the app/user has to check for updates. Only one MSI can run at any one time, and may require multiple reboots. Installing one MSI sometimes breaks another, though not if they are well written.
   
• MSIX Pros - They're automatically updated with much smaller patches, they're in a more secure (i.e., harder to access) location, they're all consistently installed (which may be a pro or con). Patches can be installed in parallel.
   
• MSIX Cons - Third party (app) interop is often more difficult due to file inaccessibility because of the MS store security model. It's sometimes difficult to even access (i.e., view) the installed program's file structure due to the security of higher-level "parent" directories (sandboxing). You're subject to Microsoft's or the app vendor's whims when it comes to updates (pro or con depending on your viewpoint and / or needs).

There may be more -- I've probably forgotten something obvious.

Executive Summary -- By packaging the Affinity apps as MSIX (store) apps, third party app interaction was broken in many cases. Serif decided to offer the standard MSI installers as an option for those who wished to use them since they tend to be more interop-compatible with other applications. Same app either way - It's just how it's installed.

[lphilpot]

I've uninstalled the MSIX version and installed the MSI version of Photo on my Windows 11 laptop. I made a copy of my .affinity folder tree just to be safe but it wasn't necessary. All seems to be fine so far.

Thanks, Serif!

[Patrick Connor]

@lphilpot

I have crossed out the MS Store bits, as the technology was developed for the store but delivery does not use the store at all

You may choose to undo my edits, or remove the crossed out bits if you agree (use the edit under the 3 dots top right)

[lphilpot]

1 minute ago, Patrick Connor said:

I have crossed out the MS Store bits, as the technology was developed for the store but delivery does not use the store at all

You way with to undo my edits or remove the changes if you agree (use the edit under the 3 dots top right)

No need to undo any of your edits. I was going on what I knew, now I know better. Feel free...

Thanks.

[913]

28 minutes ago, walt.farrell said:

Uninstaller? Or did you mean installer

I mean installer

[913]

@Patrick Connor Is there any other updates about 2.0.4 

[walt.farrell]

23 minutes ago, 913 said:

Is there any other updates about 2.0.4 

Are you asking about release notes? If so, they're in the News & Information forum, where they always are. And you can find them from this topic, or just look at the recent topics in that forum.

 

[Patrick Connor]

40 minutes ago, 913 said:

@Patrick Connor Is there any other updates about 2.0.4 

The 2.0.4 release notes answer this I think. What would you like to know ?

[pjglad]

I want to install MSI. Do I need to Deactivate MSIX then Uninstall prior to installing MSI? In other words, should I deactivate? Thanks.

[henryg]

18 hours ago, lphilpot said:

Serif decided to offer the standard MSI installers as an option for those who wished to use them since they tend to be more interop-compatible with other applications

Only due to the howls of protest and anguish from users. But at least they did it.

[walt.farrell]

1 hour ago, pjglad said:

I want to install MSI. Do I need to Deactivate MSIX then Uninstall prior to installing MSI? In other words, should I deactivate? Thanks.

You do not need to uninstall, but you probably should uninstall first to avoid confusion. There is no need to deactivate. Just a simple uninstall from the Start menu or from Settings will take care of it.

[Granddaddy]

On 1/27/2023 at 12:33 PM, lphilpot said:

Serif decided to offer the standard MSI installers as an option for those who wished to use them since they tend to be more interop-compatible with other applications. Same app either way - It's just how it's installed.

lphilpot provided a concise, orderly summary of some differences between MSI and MSIX versions of Affinity 2 software.

I do have a few comments stimulated less by my own meager knowledge of the technical considerations and more by the various comments in these forums from end-users. Such comments have been pouring in continuously during the nearly three months since Affinity 2 for Windows was released as a Windows App (MSIX) rather than as a Windows Program (MSI/EXE).

1.) Windows Apps installed via MSIX seem to be inherently insecure in the judgement of businesses, medical facilities, financial institutions, and others who have reported in these forums that MSIX applications are blocked by their organizations for security reasons. Thus, a possibly significant fraction of Affinity users were prevented from ever installing Affinity 2 (MSIX).

2.) If MSI differed from MSIX mostly in packaging for installation, then why did it take Affinity nearly three months to provide the MSI packaging? It seems the issues are far more complex than mere packaging for distribution. This seems confirmed by Moderators asking for more patience as the developers designed and coded an MSI version of Affinity 2 that would be compatible with the existing MSIX installation.

3.) That the application/user must check for updates for traditional Windows MSI programs seems a major advantage of traditional Windows program installations, not a con at all. I for one, and all the businesses that block MSIX Windows Apps, really do not want software updating itself without advising, and obtaining consent from, the user. I've seen this producer-controlled updating change iPadOS apps without my knowledge or consent (just as Kindle books can say one thing on one day and the opposite tomorrow). End-users, or local system administrators in organizations, should be in control of their software, not controlled by their software.

4.) There is no inherent reason that MSI applications cannot be updated with frequent, small patches. It's been occurring for decades. 

5.) I have been pleased to see that the Windows environment is robust enough to handle the multiple versions of Affinity software residing simultaneously on my computer during the past few days. I'm also pleased that the Affinity developers were able to provide solutions to the problems originating with the MSIX installations.

What continues to bother me most about the Big Debacle is that Affinity user support staff were totally unprepared for the negative reaction to the MSIX installers. The problems encountered by end-users, many of whom could not even install the software at all, should have been anticipated. Support staff should have been trained and prepared to give reasonable explanations and provide solutions. Instead, workarounds were rushed out amongst great turmoil. After three months of disruption and anger, Affinity's reputation is sullied. Those committed in one way or another to the future of Affinity software are frustrated. It was all so unnecessary.

[walt.farrell]

7 minutes ago, Granddaddy said:

1.) Windows Apps installed via MSIX seem to be inherently insecure in the judgement of businesses, medical facilities, financial institutions, and others who have reported in these forums that MSIX applications are blocked by their organizations for security reasons. Thus, a possibly significant fraction of Affinity users were prevented from ever installing Affinity 2 (MSIX).

The security issue for those organizations is likely to be (my guess) that users do not need special administrator authority to install the applications. If a company wants control over the software that is running on their machines, they want software installation to be centralized, and only done by users with administrator authority.

9 minutes ago, Granddaddy said:

2.) If MSI differed from MSIX mostly in packaging for installation, then why did it take Affinity nearly three months to provide the MSI packaging? It seems the issues are far more complex than mere packaging for distribution. This seems confirmed by Moderators asking for more patience as the developers designed and coded an MSI version of Affinity 2 that would be compatible with the existing MSIX installation.

The V2 applications are designed to closely interoperate and communicate. For example, they share Brushes, Assets, Styles, etc. This was not the case with the V1 applications, which were each entirely self-contained. Much of that communication and interoperation was, I think, developed with the idea that the applications were packaged using MSIX and sandboxed. Breaking free of that architecture, while still allowing the interoperation/communication, was probably the main difficulty.

11 minutes ago, Granddaddy said:

3.) That the application/user must check for updates for traditional Windows MSI programs seems a major advantage of traditional Windows program installations, not a con at all. I for one, and all the businesses that block MSIX Windows Apps, really do not want software updating itself without advising, and obtaining consent from, the user.

The MSIX apps do not update without advising the user and getting their consent. The Windows Store apps do update that way (if not prevented by the user's options), but that is a related but different technology; not MSIX.

 

[lphilpot]

20 minutes ago, walt.farrell said:

The security issue for those organizations is likely to be (my guess) that users do not need special administrator authority to install the applications. If a company wants control over the software that is running on their machines, they want software installation to be centralized, and only done by users with administrator authority.

That's definitely part of it, but not all. I spent my IT time (24 years) on a mix of a medium large-ish corporate network and on various much smaller SMB networks. On all of them, having users install stuff was an issue, but (for Microsoft networks at least) between GPO / AD and tools like LTaudit, Varonis, Tripwire and other security / monitoring / auditing packages it's generally not too difficult to block and/or remove unauthorized software.

Unexpected and unauthorized updates are another strong reason. It takes only one non-conforming update to (at a minimum) degrade a software environment, and having apps update themselves is a sure-fire way to do it. Our focus was on preventing every bit of that we could.

Corporate environments often run years (decades?) behind on versions not because the users want it, but rather due to often horrendously complex inter-dependencies. I've seen large software environments that simultaneously included bits over time from Netware / eDIrectory, Solaris, AIX, Linux, Windows Server / AD and even an IBM mainframe, plus Windows workstations of all types. Did I also mention various tablets and SCADA devices? 🙂 And that was even before Cloud became A Thing (whatever that "thing" is). Can you say, "SAP"? My condolences if you can...

Can't say I miss any of that, now that I'm retired. 😁

[Granddaddy]

35 minutes ago, lphilpot said:

Can't say I miss any of that, now that I'm retired. 😁

Aahhh!

But when we were young, did we not love the wonderful complexity of it all?

[walt.farrell]

46 minutes ago, lphilpot said:

Unexpected and unauthorized updates are another strong reason. It takes only one non-conforming update to (at a minimum) degrade a software environment, and having apps update themselves is a sure-fire way to do it. Our focus was on preventing every bit of that we could.

Corporate environments often run years (decades?) behind on versions not because the users want it, but rather due to often horrendously complex inter-dependencies. I've seen large software environments that simultaneously included bits over time from Netware / eDIrectory, Solaris, AIX, Linux, Windows Server / AD and even an IBM mainframe, plus Windows workstations of all types. Did I also mention various tablets and SCADA devices? 🙂 And that was even before Cloud became A Thing (whatever that "thing" is). Can you say, "SAP"? My condolences if you can...

All true, I'm sure.

But I would not bundle any of that under the term "security", as @Granddaddy did in the summary I responded to.

[lphilpot]

2 hours ago, Granddaddy said:

But when we were young, did we not love the wonderful complexity of it all?

When I was young I didn't work in IT! LOL

[lphilpot]

1 hour ago, walt.farrell said:

But I would not bundle any of that under the term "security", as @Granddaddy did in the summary I responded to.

Maybe not. Then again, security is the process of securing an environment, and all of that (plus more) plays into security in that context. But you're right when it's just in the Affinity context.