Do not export Private\*.ps1 functions

[vercellone]

Private*.ps1 functions are being exported, but should not be. Reference PR #36

[dsolodow]

I see two ways to accomplish this: 1) modify the .psm1 file only to export Public functions (http://ramblingcookiemonster.github.io/Building-A-PowerShell-Module/) 2) list the public functions in 'FunctionsToExport' in the module manifest.

Option 1 has the advantage of being a one and done, whereas 2 would require a manifest update when the cmdlet list changes. Option 2 has the advantage of fixing auto-load; currently if you try say a Get-F5Session without first importing the module it fails; 2 would fix this.

[vercellone]

Great stuff from @RamblingCookieMonster as usual.

I like the one and done benefit of option 1, but option 2 is probably the better long term choice.

[dsolodow]

@joel74, which is your preference? I'm inclined to option 2 as well, but figured would ask as you're the core dev. Once we know, I'll make the mods and a PR.

[joel74]

@dsolodow, my one concern with Option 2 is that it's a manual process. What happens if a function gets missed? How would we know without doing a visual compare? RamblingCookieMonster mentions exporting $Public.Basename to dynamically get the list of public functions while the module is in active development, and it feels like that's where this module currently is. I could live with either option, though.

[RamblingCookieMonster]

You could theoretically have a build process (e.g. maybe hosted on AppVeyor) that reads your public functions and updates the psd1? You would get the benefits of having the functions hard coded in the psd1, without having to manually update it.

Cheers!

[vercellone]

Perfect. Best of both worlds. I already have a draft appveyor.yml file to run PSScriptAnalyzer and publish the module based on http://ramblingcookiemonster.github.io/Building-A-PowerShell-Module/. I'll incorporate this feature.

[vercellone]

@joel74 I can do a proof of concept on my fork, but ultimately you'd have to register and configure appveyor for this repository. Do you foresee any problems with that?

[joel74]

I haven't used appveyor before, but I don't think it will be a problem to set it up.

[vercellone]

Look over appveyor.yml and the build results and let me know what you think. If you don't want to publish to powershellgallery, then I'll want to tweak the zip artifact contents so they don't include the .git\ folder nor the appveyor.yml file itself.

If you are willing to publish to PowerShell Gallery (and, i hope that you are), then I'd rather pursue that and forego the zip artifact altogether.

[joel74]

I've published to the gallery, not every commit but fairly regularly, so that's fine. I'd like it to be published automatically. Does appveyor need to hook up with the existing module in the gallery? I'll check out the appveyor stuff soon.

[vercellone]

Publishing is as simple as:

Publish-Module -Name 'F5-LTM Module' -NuGetApiKey '[Your API Key]'

1. [View your PowerShell Gallery profile]() to get your API Key.
2. Encrypt it, so you can safely include the encrypted value in the appveyor.yml file.

Tip: I highly recommend AppVeyor's Validate YAML configuration form.

[joel74]

Cool. So you're saying that if we publish to PSGallery, you'll remove the .7zip portion? I see where it's calling msiexec - what's the role of nuget.exe?

Does appveyor handle versioning? I know that PSGallery requires a version bump every time one publishes. The encrypted API key value is: secure: NvJlPynne4N7tJ/8DM2LFAKoZu5v9e35PvbAJNOCiXbXJRHrJ+OetTQsO/bYjNo5

[vercellone]

• Yes, either an appeyor artifact (zip file is just one option) or publish to PSGallery, not both.
• The msiexec install of PackageManagement_x64.msi should not be necessary when os: WMF 5 is specified. But, I haven't verified that yet.
• Refer to the Get Started with the PowerShell Gallery to learn more about Nuget's role. Again, this might not be necessary for os: WMF 5, but I haven't verified.
• AppVeyor includes build numbering, and I've included setting the version in the psd1 in the same command used to set the FunctionsToExport. You can download the zip artifact to verify the result.
• I'm fairly certain the secure string is AppVeyor user specific. But, I'll add it for the purpose of a simpler pull request.

[vercellone]

• PackageManagement_x64.msi is NOT necessary
• Get-PackageProvider -Name NuGet -Force IS necessary
• I moved the module contents into a folder named 'F5-LTM Module'. That should simplify Publish-Module, but you may need to experiment with the naming to get the desired result in the gallery.

[joel74]

I'd like to move the module back into a folder named 'F5-LTM' as that will sync up with the published module in the PowerShell gallery. Any reason not to? It looks like I can't use the -name param when publishing to PSGallery from a github repo - it just takes the name from the path and uses that.

[vercellone]

Sounds good.

[vercellone]

dbb5410 of PR #43 fixes #40

The delimiter was wrong, so no Functions at all were exported. Fixing the delimiters should work. After import of the latest module from PSGallery, the following command should not include the private functions:

Get-Command | ? Source -eq 'f5-ltm' 

[vercellone]

This issue can be closed based on version 1.3.14.

[joel74]

Confirmed