FinalBuilder - System.Automation - Common Instance

The FinalBuilder script editor and the ability to run inline scripts is excellent! However each action seems to create a new instance of System.Automation (.Net PowerShell Instance).

Generally this is a good idea but sometimes when you may want to persist a powershell session between actions. For example, in our example, we connect to vSphere via Connect-VIServer (PowerCLI) – which takes 10+ seconds, and then have other actions in the FB run script which may want to use the session token from a previous VIServer session. Since each action has a different action has a different PowerShell session instance the connection token from VIServer is invalid as it was closed when the previous PS session was closed.

Is there a way to have a common single automation session for all of FinalBuilder – maybe make this an option if it does not currently exist?

You are correct that each action creates it’s own instances, that’s because each action is a new .net object instance.

We don’t currently have any facility to store .net object references across actions (FinalBuilder is a native application which hosts the clr) … and doing so brings up all sorts of issues with the mulit threaded nature of FinalBuilder.

With .net 5.0 being the future, we are looking at how we do the hosting with that as the hosting api’s have (imho) been dumbed down and we will need to do more of the work on the .net side - so it’s possible we can expose something where the actions can register/store things for other actions to reference.

Right now we are focusing on getting FB9 compiling/running in the latest delphi compiler (it compiles, but there are numerous new problems to solve ) and updating the IDE to work with high dpi monitors (a frequent complaint). So still lots of work to do.

Thanks Vincent for the update! Appreciate it and look forward to Version 9.

Will Version 9 also have a 64-bit version?

64bit is planned, but not sure if it will be with the initial FB9 release or later. Some technical issues to resolve before we get there.

I should also say at this point we are not sure if we will stick with CLR hosting (ie .net framework) or go with .net core hosting for FB9 (which would also imply using powershell core). Still lots of R&D to do to get to that point.