{"id":1406,"date":"2012-04-23T14:30:32","date_gmt":"2012-04-23T12:30:32","guid":{"rendered":"http:\/\/www.itidea.nl\/?p=1406"},"modified":"2015-09-08T20:36:17","modified_gmt":"2015-09-08T18:36:17","slug":"powershell-export-functions-variables-and-aliases-with-wildcards","status":"publish","type":"post","link":"https:\/\/www.itidea.nl\/index.php\/powershell-export-functions-variables-and-aliases-with-wildcards\/","title":{"rendered":"PowerShell Export functions, variables and aliases with wildcards"},"content":{"rendered":"

In my previous post ‘PowerShell Export-ModuleMember vs Export keys in manifest<\/a>‘ I wrote about ways to export various items from a module.<\/p>\n

Trevor Sullivan read my post and suggested in his comment to analyze the use of wildcards to export functions, variables or aliases using the manifest file.<\/p>\n

After trying this I got enthusiastic about it, read further…<\/p>\n

As well in the manifest file as with the use of Export-ModuleMember in the module wildcards can be used.<\/p>\n

This can be (very) helpful when naming the function in the module according to a certain structure.
\nIn C# accessibility levels are used to restrict or limit access to certain methods. There is no such thing in PowerShell, but this can be achieved by (not) exporting the functions from a module. In C# reserved accessibility levels as public and private are used. We can use this ‘technique’ in PowerShell by naming the functions in a module according to a standard: use for example -public or _public at the end of a functionname or variable in a module and use the same string literal as wildcard to export functions.<\/p>\n

Practically this means defining Export-ModuleMember in the module like:
\nExport-ModuleMember -Function “*”
\nExport-ModuleMember -Variable “*”
\nExport-ModuleMember -Alias “*”
\nto export all functions, variables and aliases.
\nThen restrict the exported items in the module manifest like:
\nFunctionsToExport = ‘*-Public’
\nVariablesToExport = ‘*_Public’
\nAliasesToExport = ‘*-Public’<\/p>\n

Module (psm1)<\/h3>\n
\r\n$msgText_Public = 'Hello world!'\r\n$anotherVariable = 'more here'\r\n\r\nfunction Say-HelloWorld() { Write-Host $msgText }\r\nfunction Calc-Numbers-Public([int] $a,[int] $b) { $a + $b }\r\nfunction I-Am-Public() { Write-Host "Public" }\r\n\r\nSet-Alias Add Calc-Numbers\r\nSet-Alias Hello-Public Say-HelloWorld\r\n\r\nExport-ModuleMember -Function "*" #Say-HelloWorld, Calc-Numbers\r\nExport-ModuleMember -Variable "*" #msgText, anotherVariable\r\nExport-ModuleMember -Alias "*"\u00a0 #Hello, Add\r\n<\/pre>\n
Manifest (psd1)<\/h3>\n
\r\n# Functions to export from this module\r\nFunctionsToExport = '*-Public'\r\n\r\n# Variables to export from this module\r\nVariablesToExport = '*_Public'\r\n\r\n# Aliases to export from this module\r\nAliasesToExport = '*-Public'\r\n<\/pre>\n
And the result:<\/p>\n
\"\"<\/a><\/p>\n
Summary<\/h3>\n
In my previous post I wrote in the summary:
\n‘The export keys in the manifest can be seen as an export override of the Export-ModuleMember used in a module… When trying to control the exports of variables and aliases it all comes clear: export them in the module at all times!’<\/p>\n
After analyzing the wildcard options to export I still agree on the above statements, but I would like to nuance it a bit: export all items in the module and restrict the exported items in the module manifest by using wildcards in the module manifest and using a naming convention when defining functions, variables and aliases.<\/p>\n
When approaching exporting the items from a module as described above you can not forget to export a function, variable or alias, you just have to follow this naming convention.<\/p>\n","protected":false},"excerpt":{"rendered":"
In my previous post ‘PowerShell Export-ModuleMember vs Export keys in manifest‘ I wrote about ways to export various items from a module. Trevor Sullivan read my post and suggested in his comment to analyze the use of wildcards to export … Read More »<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,8],"tags":[43],"class_list":["post-1406","post","type-post","status-publish","format-standard","hentry","category-powershell","category-sharepoint-2010","tag-powershell"],"_links":{"self":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/1406","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/comments?post=1406"}],"version-history":[{"count":7,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/1406\/revisions"}],"predecessor-version":[{"id":1621,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/1406\/revisions\/1621"}],"wp:attachment":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/media?parent=1406"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/categories?post=1406"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/tags?post=1406"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}