Strange text behaviour
Forum rules
DO NOT POST LICENSE NUMBERS, ACTIVATION KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
DO NOT POST LICENSE NUMBERS, ACTIVATION KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
Re: Strange text behaviour
We are currently investigating this behavior. In the meantime, it is generally not good practice to have function names in scripts that match the names of functions in modules as there is no namespaces in PowerShell that separates the two.
Brittney
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.
Re: Strange text behaviour
It would be lovely if my Powershell Studio could just call functions that were in my module and not have a separate 'commonfunctions' script in my project.
If I called functions from my module would I require that the module be present wherever the PS compiled exe is run? Or would it just drag the code in at compile time so I only need the module on the computer where I build my package?
If I called functions from my module would I require that the module be present wherever the PS compiled exe is run? Or would it just drag the code in at compile time so I only need the module on the computer where I build my package?
- Alexander Riedel
- Posts: 8488
- Last visit: Tue Apr 16, 2024 8:42 am
- Been upvoted: 37 times
Re: Strange text behaviour
Powershell Studio does not determine which function is called if there is a name collision. Windows PowerShell does.
The mechanism employed by PowerShell is documented here: https://docs.microsoft.com/en-us/powers ... wershell-7
You can use a module qualified name (See https://www.sapien.com/blog/2015/10/23/ ... let-names/) to specifically point to the exact function in a module.
The mechanism exists to allow for resolving conflicts between modules which use identical cmdlet names. But obviously it also allows for avoiding a name collision with a local function.
To your last question, a PowerShell module is, akin to a dll, intended to share functionality between multiple applications. That includes application that are created by someone else. As such it would not make much sense to "drag the code in" and thereby make it private to the application. It would in essence defeat the very purpose of a module.
If you want to share common functions between your and ONLY your applications, you would dot source a script containing such functions. And yes, our script packager does have the ability to resolve dot sourced files by including its content in lieu of the dot source statement.
The mechanism employed by PowerShell is documented here: https://docs.microsoft.com/en-us/powers ... wershell-7
You can use a module qualified name (See https://www.sapien.com/blog/2015/10/23/ ... let-names/) to specifically point to the exact function in a module.
The mechanism exists to allow for resolving conflicts between modules which use identical cmdlet names. But obviously it also allows for avoiding a name collision with a local function.
To your last question, a PowerShell module is, akin to a dll, intended to share functionality between multiple applications. That includes application that are created by someone else. As such it would not make much sense to "drag the code in" and thereby make it private to the application. It would in essence defeat the very purpose of a module.
If you want to share common functions between your and ONLY your applications, you would dot source a script containing such functions. And yes, our script packager does have the ability to resolve dot sourced files by including its content in lieu of the dot source statement.
Alexander Riedel
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.
- Alexander Riedel
- Posts: 8488
- Last visit: Tue Apr 16, 2024 8:42 am
- Been upvoted: 37 times
Re: Strange text behaviour
I want to add here, that PowerShell will not automatically load your module as it typically would if there is a name collision.
Under normal circumstances, if you call Get-Lembasts, PowerShell will find a module that has that cmdlet, load it and call the cmdlet.
If however you already have a function called 'Get-Lembasts' in your script, PowerShell has no reason to find a module for it.
So your module will not be loaded at all, unless you specifically call 'Import-Module'
Under normal circumstances, if you call Get-Lembasts, PowerShell will find a module that has that cmdlet, load it and call the cmdlet.
If however you already have a function called 'Get-Lembasts' in your script, PowerShell has no reason to find a module for it.
So your module will not be loaded at all, unless you specifically call 'Import-Module'
Alexander Riedel
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.
Re: Strange text behaviour
Thanks - My module is a psm1 file with just powershell text.
Basically I have a bunch of scheduled scripts which use the psm1 module and I have a commonfunctions.ps1 file which is part of all my powershell studio projects. Both the scheduled scripts and PS projects do similar things - hence the duplicate names. For example they both have an 'Open-SQLDatabase' function. The computer I run my P-Studio on also has the module in the standard posh module folder. Its only recently that Ive seen this weird text behaviour. Unless I can use one file to store common functions for both PS Studio and scheduled scripts then Ill just have to make sure there are no duplicate names.
Basically I have a bunch of scheduled scripts which use the psm1 module and I have a commonfunctions.ps1 file which is part of all my powershell studio projects. Both the scheduled scripts and PS projects do similar things - hence the duplicate names. For example they both have an 'Open-SQLDatabase' function. The computer I run my P-Studio on also has the module in the standard posh module folder. Its only recently that Ive seen this weird text behaviour. Unless I can use one file to store common functions for both PS Studio and scheduled scripts then Ill just have to make sure there are no duplicate names.