0

I have an application that I've devevloped in C# that I need to deploy to many machines (internal enterprise).

Historically, what we have done is package the C# project with a separate installer project (enabled through installing the Visual Studio Installer Project Extension) which builds us an .msi file that we move to all the required PCs and manually install the app. But it's starting to get tedious to do this as our update cycle becomes more frequent and more PCs enter the pool.

I've been investigating deployment through .MSIX, as it outlines a simple means to host the packages on a common fileshare and provide automatic, differential updates to all users whenever they open the application. I've made a test project to test this means. It works great, it's amazing, I love it.

But when trying to do this with our production app, there is a problem. I've come to find out that if an app is installed via .msix, whenever the app is started (outside of the Program Files//WindowsApps hidden directory, at least), it is "containerized" and the working directory of the app is forcibly the Windows//System32 directory (as in, there is no way to configure this). This working directory change causes our app to crash as it is expecting the working directory to be the root directory of the install.

Apparently this is a widely known thing and people have compensated for this with the Package Support Framework. The way I understand it, you unpack your .msix, inject your "fixup" .dlls as well as the PSF itself, then package it up again. When you install with your updated package, everything works!

Great, but now the whole deployment pipeline is completely messed up, right? Once the package has been unpacked and packed with the fixups, I am not sure how to put this back into the fileshare without having to resign the package for each and every computer that installs it. Plus, I believe this breaks the auto updating feature.

What I am asking is this: Does anyone know simple process of building and packing an application with a Windows Application Packaging Project with the fixup dlls to a fileshare with automatic updates enabled?

Daniel White
  • 13
  • 3

1 Answers1

1

The package support framework (PSF) is intended as a workaround for IT pros who don't have access to the source code. It was not designed to be used by developers who can actually fix the app from their source code directly.

In your case, you can specify the working directory from the code, as others have done.

If you don't have access to the source code then you can use a third-party application like Advanced Installer which has automatic PSF integration (and build pipeline tools). Within Advanced Installer you can set the working directory from its GUI, without being required to write any code. (Search for working directory in the linked articles and you will find info on how you can use Advanced Installer or the MS tool to set it)

Disclaimer: I work on the team building Advanced Installer.

MSIX Application - working directory configuration

Bogdan Mitrache
  • 10,536
  • 19
  • 34
  • 1
    I got it to work by setting working directory in my application. I feel silly now. Thanks for your help. – Daniel White Jul 21 '23 at 17:58
  • Solid answer. The System32 thing always catches developers off gaurd when they write windows services. The what MSIX containerizes and does things like this is one of the reasons why developers don't like MSIX. – Christopher Painter Jul 24 '23 at 16:00