{"id":11549,"date":"2016-03-24T06:00:59","date_gmt":"2016-03-24T13:00:59","guid":{"rendered":"https:\/\/www.sapien.com\/blog\/?p=11549"},"modified":"2016-03-24T16:41:23","modified_gmt":"2016-03-24T23:41:23","slug":"exporting-from-modules-a-reminder","status":"publish","type":"post","link":"https:\/\/dev.sapien.com\/blog\/2016\/03\/24\/exporting-from-modules-a-reminder\/","title":{"rendered":"Exporting from Modules: A Reminder"},"content":{"rendered":"<p>There are so many new things in Windows PowerShell that I often assume that I know the basics. But, while working on a project about modules, I ran into some new guidance from PowerShell developer Jason Shirk and <a href=\"http:\/\/www.itidea.nl\/index.php\/powershell-export-modulemember-vs-export-keys-in-manifest\/\">a great blog post<\/a> that demonstrates that information about variables in <a href=\"https:\/\/technet.microsoft.com\/en-us\/library\/dd878297(v=VS.85).aspx\">a TechNet topic about module manifests<\/a> is wrong.<\/p>\n<p>Here are some important reminders about modules and their manifests:<\/p>\n<ul>\n<li>By default, all functions and aliases are exported, but variables are not exported.\n<p>&#8220;By default, all variables are exported&#8221; in <a href=\"https:\/\/technet.microsoft.com\/en-us\/library\/dd878297(v=VS.85).aspx\">How to Write a Module Manifest<\/a> (MSDN) is wrong. This topic is outdated anyway. It lingers from the time of the original <a href=\"http:\/\/go.microsoft.com\/fwlink\/?LinkID=141555\">New-ModuleManifest<\/a> cmdlet, which prompted you for about 20 of the 49 parameters, even when only Path is mandatory<\/p>\n<\/p>\n<\/li>\n<\/ul>\n<ul>\n<li>The <a href=\"http:\/\/go.microsoft.com\/fwlink\/?LinkID=141555\">Export-ModuleMember<\/a> cmdlet overrides the default export behavior. When you use it, only the commands that you specify are exported.\n<p>Therefore, by itself, this command prevents all functions and aliases, and all other variables in the module, from being exported.<\/p>\n<\/p>\n<pre lang=\"PowerShell\">Export-ModuleMember -Variable myVar<\/pre>\n<\/li>\n<\/ul>\n<ul>\n<li>You can have multiple <strong>Export-ModuleMember<\/strong> commands in a module. All of the statements are processed; none takes precedence. So, the result is the union of the statements.\n<p>Therefore, these statements, in any order&#8230;<\/p>\n<\/p>\n<pre lang=\"PowerShell\">Export-ModuleMember -Variable myProfiles\r\nExport-ModuleMember -Function Get-Profile, Set-Profile\r\nExport-ModuleMember -Function Get-Profile\r\n<\/pre>\n<p>&#8230;are equivalent to:<\/p>\n<pre lang=\"PowerShell\">Export-ModuleMember -Variable myProfiles -Function Get-Profile, Set-Profile<\/pre>\n<p>As a best practice, mostly for visibility, I prefer one <strong>Export-ModuleMember<\/strong> command as the last statement in a module file, but that&#8217;s just a recommendation.<\/li>\n<\/ul>\n<ul>\n<li>The value of the <strong>Variable<\/strong> parameter of <strong>Export-ModuleMember<\/strong> must be a name, not a variable that begins with $.\n<p>This is correct:<\/p>\n<\/p>\n<pre lang=\"PowerShell\">Export-ModuleMember -variable myProfiles\u00a0\u00a0 # Omits $<\/pre>\n<p>This has no effect, but it does not generate any errors.<\/p>\n<pre lang=\"PowerShell\">Export-ModuleMember -variable $myProfiles # Includes $<\/pre>\n<\/li>\n<\/ul>\n<ul>\n<li>The *ToExport keys in a module manifest can only further restrict exports. They cannot add to exports.\n<p>Therefore, if the module includes:<\/p>\n<\/p>\n<pre lang=\"PowerShell\">Export-ModuleMember -Function Get-Widget<\/pre>\n<p>And, the manifest includes:<\/p>\n<pre lang=\"PowerShell\">FunctionsToExport = 'Get-Widget', 'Set-Widget'<\/pre>\n<p>Only Get-Widget is exported.<\/p>\n<p>Be very careful with this one. When the value of any *ToExport key is an empty array, no objects of that type are exported, regardless of the value the Export-ModuleMember.<\/p>\n<pre lang=\"PowerShell\">FunctionsToExport = @()<\/pre>\n<\/li>\n<\/ul>\n<ul>\n<li>Redundant Export-ModuleMember and module manifest values do no harm and have no special effect.\n<\/p>\n<pre lang=\"PowerShell\"># In module \r\nExport-ModuleMember -Function Get-Profile\u00a0\u00a0\u00a0\u00a0 \r\n\r\n# In module manifest\r\nFunctionsToExport = 'Get-Profile'<\/pre>\n<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Important stuff<\/strong><\/p>\n<ul>\n<li>Use explicit names in the value of the *ToExport keys in the module manifest, instead of wildcard characters (*).Jason Shirk (<a href=\"https:\/\/twitter.com\/lzybkr\">@lzybkr<\/a>), the PowerShell team developer who maintains the module discovery code, says:\n<p><em>&#8220;PowerShell does expensive work during command discovery if you use wildcards, skips that if you are explicit&#8230;.[O]n a fresh Win10 system, if all modules do it correctly, can save 15 [seconds].&#8221;<\/em><\/p>\n<p>For example:<\/p>\n<pre lang=\"PowerShell\">FunctionsToExport = 'Get-Profile', 'Set-Profile'<\/pre>\n<p>Instead of:<\/p>\n<pre lang=\"PowerShell\">FunctionsToExport = '*'<\/pre>\n<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>I needed the reminders and Jason&#8217;s performance report will change how I write my module manifests.<\/p>\n<p><em>June Blender is a technology evangelist at SAPIEN Technologies, Inc. and a Windows PowerShell MVP. You can reach her at <\/em><a href=\"mailto:juneb@sapien.com\"><em>juneb@sapien.com<\/em><\/a><em>\u00a0and follow her on Twitter at <\/em><a href=\"https:\/\/twitter.com\/juneb_get_help\"><em>@juneb_get_help<\/em><\/a><em>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>There are so many new things in Windows PowerShell that I often assume that I know the basics. But, while working on a project about modules, I ran into some new guidance from PowerShell developer Jason Shirk and a great blog post that demonstrates that information about variables in a TechNet topic about module manifests [&hellip;]<\/p>\n","protected":false},"author":31,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[703,25],"tags":[1081,934,753,1082,551,1083,28,1072,1080],"class_list":["post-11549","post","type-post","status-publish","format-standard","hentry","category-powershell-studio","category-windows-powershell","tag-export-modulemember","tag-juneb","tag-module","tag-module-manifest","tag-modules","tag-new-modulemanifest","tag-powershell","tag-powershell-3-0","tag-powershell-modules"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11549","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/users\/31"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/comments?post=11549"}],"version-history":[{"count":52,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11549\/revisions"}],"predecessor-version":[{"id":11728,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11549\/revisions\/11728"}],"wp:attachment":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/media?parent=11549"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/categories?post=11549"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/tags?post=11549"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}