Packaging scripts for PowerShell 7 and .NET Core - feedback

Anything you want to tell us? Praise? Criticism? Post it here. Please keep it professional and constructive.
Forum rules
Do not post any licensing information in this forum.
This topic is 3 years and 1 week 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
Alexander Riedel
Posts: 8478
Last visit: Tue Mar 26, 2024 8:52 am
Answers: 19
Been upvoted: 37 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by Alexander Riedel »

[Unlocked per user request]
Please note that the topic will lock again automatically if there is no activity.
If that happens, feel free to simply create a new topic.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
ALIENQuake
Posts: 112
Last visit: Mon Jan 29, 2024 7:35 am
Has voted: 4 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by ALIENQuake »

After reading this thread again I notice that there was an emphasis on the "business cases" but I would like to start with clarification about some previous statements.

The feature of 'linking all referenced assemblies into one executable' exists for NET Framework like Fody>Costura. It was adopted widely by the community and it was an awesome addition to my project. I had NET 4.0 Application where I use MVVM framework + Microsoft.Bcl.Async library and all those extra DLL's were merged into one executable so my app could be simply downloaded and launched. And it had 100%% working auto-update because of it being a single file.

For NET Core, being able to produce a self-contained app + being able to produce a single-file app is already implemented and receives major investment over every next major version of the framework. For certain techs, like Golang and Rust, those two features are out-of-the-box. And people love it, that's why we see investment on the NET/JAVA side.

Sure, the idea collides with what you believe is true: that the shared Framework updates will fix security issues while all apps that consume this 'shared Framework ' will become more secure. In theory, yes but it's a fairy tale too good to be true. The reality (for sysadmin like me) is that every security update has a good chance to break one of the existing apps. It happens every time. That's why companies demanded that they can ship something the will work forever. All 'security implications of this can be handled either via deploying an app to the secure location or via recompiling the app with the latest framework version and redeploy. Or deploying script/app into DMZ system. Or some other measures. The point is, it's should be script/application author choice. I simply want to have a choice: Framework Dependant or Self-Contained. Even PowerShell itself offers it.

So here are some of the business cases:

- if there is a single-file application, the auto-update became trivial
- a self-contained PowerShell Script/GUI App greatly reduces the complexity of the deployment, no need to check and install missing software
- a self-contained PowerShell Script/GUI App greatly reduces the complexity of the auto-update of the application itself
- a self-contained PowerShell Script/GUI App offers a possibility to be launch as 'portable mode' where no changes are done to the system
- a self-contained PowerShell Script can be 'published' as Linux/macOS executable and be instantly ready to ship
(AFAIR, there some code changes needed for PowerShell 7+ itself to have a "single-file" feature working out-of-the-box but the competitive product already offers such feature!)


Please reconsider giving those who want the ability to create Self-Contained PowerShell Scripts/GUI Apps.
User avatar
Alexander Riedel
Posts: 8478
Last visit: Tue Mar 26, 2024 8:52 am
Answers: 19
Been upvoted: 37 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by Alexander Riedel »

There is an emphasis on business cases, because the vast majority of our customers uses our products in a business environment. So we separate business case reasons from the "but I just would love that" reasons.
That does not invalidate the latter, but I am sure you understand why we distinguish those when evaluating which features to implement and which not or at least not yet.
My beliefs are not relevant in this particular matter. My concerns are with development efforts and costs involved, support incidents resulting from any changes, UI restructuring to indicate which choice implies what and, to be honest, avoid implementing features for the benefit of a single person. We truly appreciate every single person's feedback and take it as what it is, but I am certain you understand that the list of feature requests always exceeds to capacity of the development team. That seems to be a universal law :D
That is why I ask for business reasons. This also gives others a chance to chime in and post their own views and reasons.
Another point to ask for business reasons is to find out what you want to accomplish and why. There maybe other ways to do that you may not be aware of.
In simplest terms, if a user asks for tree control somewhere, we ask what they want to accomplish and why. Because a grouped list control might work much better in that place with the user unaware of this even being an option.

I will give you my view on your list, which does not mean we are not looking at this with fresh eyes, but to point out options for everyone else reading this.

"- if there is a single-file application, the auto-update became trivial"
Copying a single file is no less nor more complicated than copying a folder with multiple files. That is assuming you are talking about deployment without installer.

"- a self-contained PowerShell Script/GUI App greatly reduces the complexity of the deployment, no need to check and install missing software"
That implies that running an MSI once to install software and its pre-requisites is complex. Is it? How so?

"- a self-contained PowerShell Script/GUI App offers a possibility to be launch as 'portable mode' where no changes are done to the system"
I can see the draw. It does not require a single exe file though. It would work the same way if your application would be in a folder. Which is how most, if not all, .NET core applications are distributed, including PowerShell itself. The point of PowerShell is mostly to make changes to a system. What's the difference?

"- a self-contained PowerShell Script can be 'published' as Linux/macOS executable and be instantly ready to ship"
Every MacOS application I know is a folder filed with files. I asked our Mac devs and they said 'no such thing as no dependencies' but I have no personal experience in MacOS matters.
For kicks and giggles I tried to rebuild the basic .NET Core command line packaging engine for MacOS as a single file. It failed. It generates an exception, no-go. Even without the 'single file' option Visual Studio does not resolve the PowerShell dependencies. It does include System.Windows.Forms.dll, which does not even run on MacOS.
So at the moment I am going with Microsoft does provide a proper vehicle to produce the kind of .NET Core applications you ask for. I am certain we could find a way to circumvent all that, but at what price?
Are you willing to pay extra for more publishing options in the packager? Is everyone else cool with that too?

- "(AFAIR, there some code changes needed for PowerShell 7+ itself to have a "single-file" feature working out-of-the-box but the competitive product already offers such feature!)"
Doesn't "code changes needed" set off alarms here? Would you really want to trade a dependency on a common runtime for a dependency on a custom outside vendor PowerShell version with unspecified changes?

-" In theory, yes but it's a fairy tale too good to be true."
I do not know what your experience is with system updates is. I am not even sure I even want to know :D I understand your misgivings about Microsoft updates and the havoc they can create. I think we all had to deal with that at some point. But if you think that applications will be repackaged and redeployed when security issues arise, you may be in for a big surprise. There is an assumption here that you will always know if there is such a vulnerability. I do not know you, so I am going to assume that YOU would always be on top of that and repackage and re-deploy the instance there is a shadow of a doubt of a vulnerability. While you are on vacation, paternity leave, sabbatical or something else :D From my experience, that is where the fairy tale is. ;-)
We each week receive requests to retrieve source code from packaged executables created with 2012 versions of our software. So 9 years old applications that have never been updated and where the code got lost a long time ago. I am quite certain that these applications did not get repackaged and re-deployed for whatever reason.

-"That's why companies demanded that they can ship something the will work forever."
There's a fairy tale in here, isn't there? I still have some version of a PrimalScript precursor compiled for 8 bit DOS character mode somewhere. All windowed, colored, mouse enabled, very pretty.
It won't run anywhere. "Forever" in our industry is a very fuzzy term.

- The point is, it's should be script/application author choice.
You always have a choice. You can always learn C and make a portable command line app without any dependencies. Everything you can do in PowerShell you can do in C. It's only a question of effort.
PowerShell 7 is not framework dependent. Which is why they get away with some of the choices they make to become incompatible with previous versions. You have to break eggs to make an omelet, I get it,
but not all choices are good choices. Do we need to enable bad choices and questionable practices? No, we don't. We do the best we can to balance reasonable requests with security implications.
We are not infallible, of course, but we try to consider potentially hazardous situations. It is your choice to consider that or not of course.

We have had single exe deployment in the past for VBScript/JScript. The exe simply unpacked itself to create all files need when started. A single file unpacking itself into multiple executable scripts and files will of course nowadays set of every malware shield and alarms and is no longer feasible. We removed that feature ages ago as these types of applications ceased to function on a modern OS.
Why would we go back to re-introduce what is basically considered a malware feature these days?

As a final counterpoint, I ask you if you do think that single executable file, containing an entire framework, a complete (and modified) powershell engine, asking (potentially) to run elevated with absolutely zero need to be properly installed looks like a good idea? There may be zero day vulnerability in the framework you just packaged that gets fixed tomorrow. Your single executable application will forever carry that vulnerability. Are you willing to pay that price? Should we enable our users to put themselves into that position? What do I tell you when you come back and inform us that our 'single executable package engine' enabled a major hack on your network by allowing you to create a permanent vulnerability?

Now, lets get back to reasons.
I will delve into the other language comments you made. There is already a single executable option for a PowerShell 7 command line application. It is C++ with minimal dependencies, but it uses a temporary file. Obviously that requires PowerShell 7 to be actually installed. There are other ways to create a single executable file but the question as to what the actual benefit of it is remains.
There are a large number of technologies and languages available to provide any number of solutions. 'linking all referenced assemblies into one executable' is not solving any particular problem by itself.
It is always in a context. That context is what I am asking for.

The list you provided seems to aim at reducing complexity. Updating is mentioned twice. Is that where the problem is?
I am asking you again what the underlying business reason is. The list you posted is more or less a solution to what you perceive to be a problem, without describing the actual problem.

Why don't we start over and you describe what problems you face with say, running an MSI to update an application.
What environment are you deploying applications in that cannot be updated?
A 'portable mode' application raises the image of walking machine to machine with flash drive. Is that something you are doing?
Are you trying to hide details from your users, customers? Are you more concerned about protecting intellectual property or ease of use?
What type of user is deploying or using your applications? Deploying to other, maybe somewhat less knowledgeable admins, within your organization is distinctly different than deploying to a large number of retail managers updating their POS systems.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
ALIENQuake
Posts: 112
Last visit: Mon Jan 29, 2024 7:35 am
Has voted: 4 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by ALIENQuake »

For now, let's make things easy and forget for the moment about single-file apps, shall we? Let's focus on the self-contained app which has out-of-the-box support from NET and PowerShell.

"That implies that running an MSI once to install software and its pre-requisites is complex. Is it? How so?"
I need to create an installer, add NET Core installation then PowerShell engine installation. Then I need to keep those components up-to-date.
So now I have an additional 'pipeline' of tasks every time there is an update. Having a self-contained app means that there are only two steps: build and deploy.

But the main argument is that I DON'T want to have an installer at all. All major tech-stack allows me to do it, including NET Core. I see no reason for a fully-fledged PS GUI to be different.

"I can see the draw. It does not require a single exe file though. It would work the same way if your application would be in a folder.
Which is how most, if not all, .NET core applications are distributed, including PowerShell itself. The point of PowerShell is mostly to make changes to a system. What's the difference?"

Yes, I don't need a single-file for that. Self-contained will be enough, as I have written. The point of running PS is not always to change the system. PS has great 'AD/system/configuration check' ability and that is one of the goals I aim for. You also need to account for company policy: getting approval to install something and change the system vs launching "scan tool" is a hell of the difference.

"So at the moment I am going with Microsoft does provide a proper vehicle to produce the kind of .NET Core applications you ask for. I am certain we could find a way to circumvent all that, but at what price?
Are you willing to pay extra for more publishing options in the packager? Is everyone else cool with that too?"
The self-contained scripts/apps are fully working. You have previously stated that other people requested a similar feature. If you want to be sure, launch a survey and ask. If there is no man-power, setup 'feature bounty' for self-contained and single-file features. I will donate what I can.

"Doesn't "code changes needed" set off alarms here? Would you really want to trade a dependency on a common runtime for a dependency on a custom outside vendor PowerShell version with unspecified changes?"
I already have full trust when it comes to compiling scripts into executables and installing your custom version of the PowerShell instance. Why I would have any doubts about this matter?

"As a final counterpoint, I ask you if you do think that single executable file, containing an entire framework, a complete (and modified) powershell engine, asking (potentially) to run elevated with absolutely zero need to be properly installed looks like a good idea? There may be zero day vulnerability in the framework you just packaged that gets fixed tomorrow. Your single executable application will forever carry that vulnerability. Are you willing to pay that price? Should we enable our users to put themselves into that position? What do I tell you when you come back and inform us that our 'single executable package engine' enabled a major hack on your network by allowing you to create a permanent vulnerability?"

This is the thing that strikes me. You are describing how the majority of applications are made and deployed today and claim that it's somehow different for PS. Just replace 'PowerShell engine,' with Go, Rust, NET Core, Node+Electron self-contained executables.

When such a vulnerability pop out, I still have to deploy the updated PowerShell engine. It's no different than compiling app using a fixed version of the engine. The difference is that updating the global engine has a chance to break other scripts/apps and deploying a self-contained app does not. I simply don't want that this decision is taken for me.

"A 'portable mode' application raises the image of walking machine to machine with flash drive. Is that something you are doing?"
No. It's a common way to have an application that can be moved from one drive to another and have all configurations intact. Also, it survives OS reinstallation without additional steps.

"Are you trying to hide details from your users, customers? Are you more concerned about protecting intellectual property or ease of use?"
No. Deploying a self-contained or single-file app has nothing to do with those.

"What type of user is deploying or using your applications?"
Normal users and in most cases, less knowledgeable admins.
User avatar
Alexander Riedel
Posts: 8478
Last visit: Tue Mar 26, 2024 8:52 am
Answers: 19
Been upvoted: 37 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by Alexander Riedel »

Thank you for your input.
Alexander Riedel
SAPIEN Technologies, Inc.
This topic is 3 years and 1 week 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