That will throw an error: “Cannot retrieve the dynamic parameters for the cmdlet. The provider does not support the use of credentials. Perform the operation again without specifying credentials.”

Impersonation

To solve this problem at work, I’ve written an impersonation module. It basically has two methods: Push-ImpersonationContext and Pop-ImpersonationContext. There is one catch: you need to be running in single-threaded apartment mode for it to work, because the impersonation only affects the current thread (if you’re not running PowerShell.exe -STA, your commands execute on a thread pool, so you never know from one to the next what thread you’ll be on). In any case, you use it like this:

It’s really very simple, and works great for when you need to access resources across multiple domains. Particularly files, for which PowerShell doesn’t support alternate credentials at all. Anyway the module code is on PoshCode, save it to your Documents\WindowsPowerShell\Modules\Impersonation\Impersonation.psm1 and use Import-Module Impersonation to load it. Here you go:

Scripts are still there, but they’re still basically done the way they are now: you just upload a single file.

Modules, however, will be treated specially. You’ll have to have an account to upload, but you’ll be able to just upload a .zip file of your module folder using your login and not fill in any other forms. Our system will take care of parsing the metadata out of the manifest in your module folder.

The problem is that I need a little data that isn’t a part of the standard module manifest format… and I can’t add it because PowerShell won’t load a module with extra fields in the manifest metadata hashtable: https://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=421837 — My request was closed “by design” early in the beta cycle and I wasn’t able to convince them to rethink that.

At a minimum, PoshCode requires a LICENSE field, and a CATEGORY field (think of the categories on CPAN or TechNet Script Center).

So I’m having an informal poll. (you’ll have to “vote” by commenting or tweeting to me, because I want more than just “I choose A”).

Which option do you prefer, or can you think of a better way:

Require the License and Category to be part of the PRIVATEDATA field in the standard manifest

This might require authors to rewrite parts of their modules, because we’d be forcing PrivateData to be a Hashtable, and to contain keys that they don’t need in the module.

Some existing modules use an array in PrivateData, or even a simple string, rather than a Hashtable. However, it’s not a huge difference, and might be the cleanest method: it wouldn’t require you to manage a second file of data, and the additional data will be easily available to users and scripts via the standard Get-Module output.

Add a “doc comment” system for Module manifest files.

The upside of this is that PoshCode wants to create module-level documentation anyway. If we use documentation comments like those used on functions we would be able to just create our own standard for them, and add any extra fields we need. It would be guaranteed not to conflict with anything you’re already doing, and in addition to missing metadata, you could have some module-level documentation beyond just the Description field of the metadata.

The problem with this is that there’s no built-in way to parse that, and doing so isn’t trivial, so you would need to just read it on our website, or read the source of the file, or have our PoshCode cmdlets in order to make any sense of it once you had a module on your system. It doesn’t integrate with PowerShell in any meaningful way.

Embed the extra data right in the manifest hashtable, using a special comment to hide it from Get-Module

@{
author=“Joel Bennett”
description=“My latest crazy module”
<#!PoshCode
License=“Ms-PL”
Category=“WPF”,“GUI”,“Toolkit” #>
CompanyName=“Huddled Masses”
...
}


I like this because it’s fairly trivial for us to strip out the comment and just turn that into a plain-old DATA section. It also lends itself to reminding the PowerShell team that these fields are missing, and maintains the existing simple syntax of the manifest.

The problem here is, again, that the data doesn’t appear using any of the standard PowerShell tools — but getting it out is significantly easier than getting out document comments…

Require a separate “ReadMe.psd1” (or “PoshCode.pds1” or “Metadata.psd1”) metadata file

You could start with a copy of your module manifest, and then add the extra stuff that PoshCode needs. This would be nice because we would be able to add any extra fields we wanted as mandatory members, and we could include the “documentation” stuff I mentioned earlier…

But the downside is that it would be a third file (second manifest) that authors would have to maintain and keep current.

Any thoughts? Suggestions?

I’ve put some further thoughts about CPAN and the data problem on the wiki.

It’s open to any PowerShell user groups or script clubs. If you’re running a PowerShell user group and want simple web-hosting with:

• top-of-the-site billing for your group (with a url like http://powershellgroup.org/rochester-ny )
• group signups
• events, calendars and event signups (including sending out RSVP emails to your group), and email reminders of events
• a semi-private group section for posting notices, wiki pages, etc.

• optional twitter notification for your posts

Just let me know who you are after you sign up on the site, and I can set you up with “group administrator” rights.

Also, if you have your own web hosting for your user group, but would like to be listed on our site, we can handle that too