Navcontainerhelper: Powershell 7 Support

[git-no]

SITUATION
NAVContainerHelper can not be installed within Powershell 6 (core) or 7.

REASON
Reason is

#Requires -PSEdition Desktop 

in .psm1, see also #305

REQUEST
navcontainerhelper does work with Powershell 7.

QUESTION
Are there any plans to skip this limitation and be able to run NAVContainerHelper under PS 7?

[freddydk]

Have you tried cloning the project, removing the line and running navcontainerhelper.ps1?
I think there are other reasons why it doesn't run.

[freddydk]

Looking at the documentation for PowerShell 7, it builds on dotnet core.
There are a lot of things in NavContainerHelper, which wouldn't just work.
Moving this to PS 7 is likely a project, which will need to happen some day and be a forked project (like PS 6 and PS 7 will co-exist for some time).
I will close this issue as this will be fixed some day, but not the fix requested here.

[hemisphera]

@freddydk is there anything going on already on this? I have started a fork that aims to run under PS core. Not sure how - or if at all - you want to get involved? Or how you'd like to move on with this?

[freddydk]

Please note, that I recently split navcontainerhelper and bccontainerhelper.
If you manage to make bccontainerhelper work on PS core, I would be happy to see what it would take.

[hemisphera]

@freddydk just a heads-up on where this stands.

• I had to commit and open a PR on PowerShell itself for it to work with containers at all and as such it requires at least PS 7.1.x (in preview as of today).
• Some headaches come from the ACL stuff that is currently done through .NET classes, I replaced that with the corresponding cmdlets.

As of now I am able to spin up a new BC container using PS7 and most cmdlets I use are working fine.

[freddydk]

Impressive

[git-no]

@hemisphera

As of now I am able to spin up a new BC container using PS7 and most cmdlets I use are working fine.

Also Get-NavContainerEventLog?

[hemisphera]

@git-no: Yes and no. I modified it to don't use wevtutil and as such I don't get a .evtx file back anymore. I return the raw event data directly in-session. The port is available here, if you want to try: https://github.com/hemisphera/navcontainerhelper.git on branch ps-core.

[FSharpCSharp]

From my point of view it would be very desirable if this PowerShell library would finally be available in .NET Core or .NET 5. Since .NET 5 is on the home stretch anyway, it would be great to be able to work with it.

@freddydk What are the arguments against changing the development to .NET Core or .NET 5? The changes were not as extensive as you can see in the branch of @hemisphera Therefore it would be great from my point of view if a pull request could be created for this and a package for .NET Core or .NET 5 could be provided.

[hemisphera]

Hold it, it's not that simple. There's a REAL LOT more to it than what I've have done. As I've stated above I've only concentrated on getting New-BcContainer to work and see how it holds up. And it does. But there are a few issues to deal with here:

• It's a moving target. There are tons of changes being pushed in each day and as long as @freddydk does not plan support for PS Core, I am not willing to dig through hundreds of commits to check if things still work on PS Core. One thing is creating compatibility. Another is maintaining it.
• There are a huge amount of helper and utility functions in this module that I simply do not (and will never) use. Others may. I do not. I don't know what they have in store? How much .NET-Interop is there? Do I really need a Compile-NAVAppInContainer and all the complication it brings? I'd say we don't. But that's the way I work, others do it differently. I'd rather prune this module to it's bare essentials before attempting a "definitive" port to PSCore. And maybe port those "utilities" as a second module or later ... I don't know.
• Also: tests will not work as of now. The whole ClientContext-stuff needs some love and should be converted to real .NET code IMHO.

There is another key thing to consider - one that personally holds me back on multiple fronts: the binary .NET assemblies used for managing apps (Publish-NAVApp, Install-NAVApp and friends) are all written in .NET Framework 4.8. They will never work under .NET 5, unless they're ported. So even if we would have a PSCore-ContainerHelper, we would still need to switch to PS5 to install and manage apps. MS' response to this on Yammer is not very promising: "We're working on it. Carefully. No ETA."

[FSharpCSharp]

Don't worry, I think I have already understood you correctly! I am also fully aware of your arguments. I personally feel it's just a bit of a pity that there are all these really great new open technologies like .NET 5 and PowerShell Core, but you can't use them to their fullest extent. It is a pity. But as you have already written it is a long way! Just wanted to emphasize with my statement in this issue that I think the topics are really important and I would love it if there would be an easy way to use the new technologies.

But thanks for your effort @hemisphera ! I find people like you incredibly important in a growing community. Thanks for all your efforts! And of course thanks to @freddydk for creating this extensive library, which makes the daily work much easier!

[freddydk]

Thanks for bringing this discussion up. I will share my $0.02 for why things are as they a
Beside the fact that PowerShell 7 is the future etc etc, what is the main motivator for doing this right now?

Today, the service tier also has a dependency on .net 4.8, including all powershell cmdlets.
The AL compiler actually comes in a .net core version + .net fwk version and the Web Client is also using .net core - but we have a few things to do in the platform before we can move to .net core and .net fwk.

With this, I haven't prioritizing moving the containerhelper - I have a lot of other things that have been absolutely necessary and still have a number of things.
All build agents and computers does have 4.8 installed and is fully capable of running with that.

At some point in time, I will likely create BcContainerHelper-core (or like), but some observations:

• I will not have time to maintain two repositories, when I switch to -core - the normal one will be left for Sustained Engineers (like NavContainerHelper - only serious bug fixes. - but this is bigger than a name change)
• that library will have no support for C/AL stuff (codepages, ansi, non-unicode things is a mess) - use BcContainerHelper or NavContainerHelper for that.
• test execution should go through the development endpoint and not using the client service (clientcontext etc. will go away and stay in bcContainerHelper)
• platform, commands, generic image should all be dotnet core and bcContainerHelper should be used for the "old" versions.
• probably more...

[hemisphera]

To be completely honest: there is no true benefit of moving to PS Core. I mean: PS Core is great and all, but there's nothing that PS5 can not do (more or less). So if we're only talking benefits here, I agree with you, @freddydk .

The thing is: all the stuff is going to be obsolete in a months time. I don't want to use obsolete stuff. Maybe I am just too progressive when I really should be more conservative? I don't know. I'd rather be prepared than left behind.

Anyway: @freddydk you were speaking about testability and the developer endpoint. You have my attention. Anything to share? Anything I could help you with? This is a very important topic for me.