PS7 package....More Files?

Ask questions about creating Graphical User Interfaces (GUI) in PowerShell and using WinForms controls.
Forum rules
Do not post any licensing information in this forum.

Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
This topic is 1 year and 9 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked
User avatar
owinsloe
Posts: 161
Last visit: Tue Mar 26, 2024 8:14 pm
Been upvoted: 1 time

PS7 package....More Files?

Post by owinsloe »

Hey team,
Apologies if this has been raised previously (I could not find any postings)
I am currently beginning to play around with packaging my UIs using PS7 and have noticed a couple of things that differ from PS5 packages.

1. When I package my script (cnwserverlogs), it now generates a stack of libs and json files as well as the exe. If I move the exe without the other files, it will not run. We have over 600 servers we manage and moving more than the single file is messy and I would rather avoid having to change to using a MSI when new releases are made. Are those other files static and the same for ALL packaged exe's? ie. If I copy those to our servers inoto a path within $ENV:PATH, will that be sufficient?

2. In the case of THIS utility, I use a progressbar and when I run the script via PSS, it works fine, when run as the EXE, the progressbar does not appears. I am using a TextOverlay and wonder if this is an issue with ps7. Otherwise I'm not doing anything particularly weird?

$progressbaroverlay1.Visible = $true
$progressbaroverlay1.TextOverlay = $null
$progressbaroverlay1.Value = 0

The EXE and all his friends......
cnwserverlogs.exe
Microsoft.ApplicationInsights.dll
Microsoft.PowerShell.CoreCLR.Eventing.dll
Newtonsoft.Json.dll
powershell.config.json
PowerShell.Core.Instrumentation.dll
pwrshplugin.dll
SAPIEN.PoshCoreHostWin.deps.json
SAPIEN.PoshCoreHostWin.dll
SAPIEN.PoshCoreHostWin.runtimeconfig.json
System.Diagnostics.EventLog.Messages.dll
System.Management.Automation.dll
System.Management.dll
System.Security.Cryptography.Pkcs.dll
jvierra
Posts: 15439
Last visit: Tue Nov 21, 2023 6:37 pm
Answers: 30
Has voted: 4 times
Been upvoted: 33 times

Re: PS7 package....More Files?

Post by jvierra »

You should be able to copy all of the DLLs just once. If the versions change then they will have to be recopied. You could just zip everything and unzip it on the target system.

MSI will be required if you require versioning and an MSI will only update changed files.

You will need to install the PowerShell 7 runtime on the target systems as they cannot be easily copied but once the runtime is installed then it will not need to be reinstalled as long as you keep using the same PS7 version for your EXE.

There are other methods for deploying an EXE and since it is a Sapien product that packages the EXE then you should post in the Sapien PSS Support forum for better support for their products.
User avatar
Alexander Riedel
Posts: 8478
Last visit: Tue Mar 26, 2024 8:52 am
Answers: 19
Been upvoted: 37 times

Re: PS7 package....More Files?

Post by Alexander Riedel »

This is how .NET 5 or .NET 6 works. I have no doubt .NET 7 won't be any different.
Microsoft designed it that way, you can ask them for details if you like. I point this out because sometimes there is an assumption that we design this to make it extra complicated.

Depending on the engine selected you not only need the exe, you will also need the dll of the same name and the json(s), if dependencies change, e.g. .NET sub versions (6.0.0 -> 6.0.3)
The PowerShell code, settings and other 'stuff' are stored in the resources of the exe and the dll of the same name. In some cases the .NET bits load things from the dll, sometimes from the exe.
This is the way going forward, applications will be considered a folder with whatever is needed inside it. MacOS has done that for a long time, so did many Unix derivatives.
I cannot promise you that a list of files you need as a minimum will be sufficient for next month's PowerShell version or the next .NET sub version. We simply have no control over that.

Personally I always recommend using an MSI. It provides proper versioning, logged updates, quick check of installed status and the ability to run custom code on install/uninstall to initialize and/or remove settings if required. Plus, it only requires a single file to be placed on a network location for whatever type of application is deployed.
Having the MSI signed is also a safeguard against the applications being tampered with or infected with something.
Also, I have to point out that the MSI files our applications build ALWAYS uninstall the old version and re-install the new one. They always contain the full set of files. It will not 'only' install changed files. The MSI files are not patches that you need to install in the correct order.

From experience, nothing will be harder to diagnose than an application with many interdependent files, where all files are mismatched over the course of time, stemming from different versions of the application.
Just imagine you move from PowerShell 7 with 7.0.11 to 7.1.7 to then 7.2.4 over the year. You would move across three .NET versions (3.1 -> 5 -> 6). If you base your deployment on a subset of files and you are not always 100% sure what changes are made beneath the surface, you can end up with one of those "But it works on my machine" situations across your 600 servers.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
owinsloe
Posts: 161
Last visit: Tue Mar 26, 2024 8:14 pm
Been upvoted: 1 time

Re: PS7 package....More Files?

Post by owinsloe »

Thanks Alexander, you did a champ job explaining things. This is going to completely change the way we distribute and update. We will now have to package to MISI, distribute and install as opposed to a single file copy. But, we can't be left in the past and need to move forward.

Regarding the progressbar issue, I found a previous thread from Britney...
"The ProgressBarOverlay control was again a control added by us to extend the functionality of the standard ProgressBar control. It was updated upon the initially release of PowerShell 7, but appears to have issues with newer versions of V7"

This also explains things, so I have moved back to using the non_Sapien progressbar control with a label for text display.

I see I also need to revisit FileOpen dialogs in some of my other projects due to a similar situation (Sapien custom control)
User avatar
owinsloe
Posts: 161
Last visit: Tue Mar 26, 2024 8:14 pm
Been upvoted: 1 time

Re: PS7 package....More Files?

Post by owinsloe »

@Alexander,
Dumb question time (ok, yet another one)
When PSS packages the script into an exe, why could it not also take all the other dependency libs,jsons etc and unpack at the time of execution. That way we're back to a single exe and makes the whole distribution process a lot simpler?

The reason I'm banging on about this is that we are constantly releasing packaged Sapien PSS scripts, many commandline and many UI's. Often some of these utilities are active on several servers at the time of release and distribution errors occur as we're unable to overwrite inuse files.

We have a common BIN folder on all our servers that contain all our internally released utility products. So now with what the PS7 world is doing to us, as well as handling additional release procedures we will need to release products to their own folders..
c:\bin\utility1\utility1.exe etc
c:\bin\utility2\utility2.exe etc

This seems a little excessive. Is there any other way of progressing this?
User avatar
Alexander Riedel
Posts: 8478
Last visit: Tue Mar 26, 2024 8:52 am
Answers: 19
Been upvoted: 37 times

Re: PS7 package....More Files?

Post by Alexander Riedel »

Old Chinese proverb. There are no dumb questions. Only stupid answers.

"When PSS packages the script into an exe, why could it not also take all the other dependency libs,jsons etc and unpack at the time of execution."
Aside from a host of other reasons I have mention in this forum here and there, ultimately in your scenario it would not work.
Windows loads an executable and its dependencies before it executes any code at the entry point of said executable. Since at that time these dependencies are not yet unpacked, they are considered missing and the application never starts. Assuming it would work, like a self-extracting zip file, imagine you have two applications using different versions of the same files bunched up in one folder. Good luck trying to run both at the same time. More on that later.

Aside from that, applications should *always* and I cannot stress that enough, be installed in a protected folder under C:\Program Files etc.
https://resources.infosecinstitute.com/ ... indows-10/
You can of course define your C:\Bin folder as a protected folder. But that is extra work and you can bet money on it that the next new server being installed will have C:\bin not as a protected folder because nobody read the memo. And nobody will notice. There is no "But this is a protected folder on another machine" message coming up. You can use group policy of course. That is another can of worms I don't want to discuss here :D
So it is much better to place applications in a folder that is a protected folder by default.
Putting commonly used utilities, specially those used with elevation into an unprotected folder is a humongous security issue. Just don't do that.
You should also not rely on the folder where your application resides as writeable. It should not be as a matter of fact, so I hope your utilities store data in the designated per user or per machine appdata folders.

And yes, you should not bunch up multiple applications in one folder. Consider the folder to be the application and not the individual executable.
Say developer Jonny Walker is in charge of application one. Developer Paula Nerbeer is in charge of application two. Both get struck by the good idea fairy and decide to name a json file 'settings.json'.
Because it is an obvious name. They don't like each other and do not speak regularly. Installing app one now overwrites the settings of app two and vice versa. Since only a subset of users
will use BOTH app one and two the issue is very intermittent. Good luck finding that one out. If each app lives in their own folder, this is never an issue.
So look at this as a benefit rather than a hassle. It will save you lots of grief over time.

Now, regarding running processes while updating applications, Windows Installer (MSI) detects that, pops up a warning with an option to close the blocking process before proceeding or to cancel.
You can also add a custom action to kill a process you do not want to exist while installing. So the MSI gives you tools that the simple 'just copy a file' does not have.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
owinsloe
Posts: 161
Last visit: Tue Mar 26, 2024 8:14 pm
Been upvoted: 1 time

Re: PS7 package....More Files?

Post by owinsloe »

Thanks again Alexander, appreciate your effort in responding. Our bin folder is a special protected folder we create when we build our servers. It's only for our tools (100s of them), including C# and misc other scripts.
We remotely run installs so popups are no good for us.

Rather than drawing this out much further, I have benched further PS7 updates and reverted to PS5 but we are still progressing the PS7 runtime install rolloutss which will allow ps7 ps1 scripts to run if we need. Where I can, inside my packaged ps5 UI's I will use ps7 functions inside a PWSH scriptblock (eg.convertfrom-json -ashashtable)

I will revisit this again if I get really bored and I feel like filling up your support forums once again.....:)

Thanks again
This topic is 1 year and 9 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked