none
Guidance for name and installation location for binary powershell module

    Question

  • Hi, 

    So what type of experience do powershell users expect when installing powershell cmdlets?  From previous experience we've decided that our the users of our product would prefer a .msi installer, but now that we are writing the installer, we need direction on how and where to install the cmdlets.

    1) Should the powershell cmdlets be installed as a PSSnapin or Module (or both).  We've heard that PSSnapins are sufficiently deprecated that we should install as a module only.  Is this true?

    2) If we install as a module, what is the best practice for install location when installing for all users?  Should we install in the system folder (windows\system32\windowspowershell\V1.0\modules\mymodule) , or should we install in our application folder (in program files) and modify the system-wide PSModulePath environment variable 

    3) If we install as a module, what is the best practice for module naming?  Is there a module naming convention that is helpful or expected by powershell users? For example: if my powershell cmdlets are all prefixed with "MyCompany", then should my module be named "MyCompany"?  

    Thanks in advance for your feedback.

     

    Wednesday, November 10, 2010 4:52 PM

Answers

  • great question.

    1) I'd go with module

    2) nothing wrong with using your own path(ie program files) and then ask the user if they want you (the installer) to modify their profile or the machine profile (or not at all and show the load module command needed) and do that... the modules don't have to be in the default folders. if you do take this approach I would say make damn sure that you show the load command all over the place because that will be the source of a lot of helpdesk calls otherwise. and maybe, depending on what the cmdlets do, highly recommend the machine profile be updated, or ____, update the profile so that if they don't want it to load the cmdlets do a write host that tells you they werent loaded and that the msg is coming from the machine profile located at <path>... a nag, but a useful and easily modified nag..

    3) I havent seen a convention but if its for a company I would suggest using a more descriptive name that is perhaps a combo.. EMCStorage, QuestAD, etc

    at any rate, this is what I'd like to see :)

    Wednesday, November 10, 2010 5:13 PM

All replies

  • great question.

    1) I'd go with module

    2) nothing wrong with using your own path(ie program files) and then ask the user if they want you (the installer) to modify their profile or the machine profile (or not at all and show the load module command needed) and do that... the modules don't have to be in the default folders. if you do take this approach I would say make damn sure that you show the load command all over the place because that will be the source of a lot of helpdesk calls otherwise. and maybe, depending on what the cmdlets do, highly recommend the machine profile be updated, or ____, update the profile so that if they don't want it to load the cmdlets do a write host that tells you they werent loaded and that the msg is coming from the machine profile located at <path>... a nag, but a useful and easily modified nag..

    3) I havent seen a convention but if its for a company I would suggest using a more descriptive name that is perhaps a combo.. EMCStorage, QuestAD, etc

    at any rate, this is what I'd like to see :)

    Wednesday, November 10, 2010 5:13 PM
  • Hi,

    Regarding naming conversion, it seems PowerShell V1 and V2 have different behaviors, for your reference:

    Final naming convention
    http://martinzugec.blogspot.com/2009/03/final-naming-convention.html
    Please Note: The third-party product discussed here is manufactured by a company that is independent of Microsoft. We make no warranty, implied or otherwise, regarding this product's performance or reliability.

    Command Line Standard
    http://technet.microsoft.com/en-us/library/ee156811.aspx

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, November 16, 2010 9:10 AM