I have a need to create a Module that can Run in Powershell 7 and use commandlets from Powershell 5.
I want to save this module as an artifact and publish in AzureDevOps Artifacts.
The Module is for auditing cross platform system information. The problem is that some of the cmdlets are Windows platform specific such as Get-WindowsFeature. I also want to use PowerShell Core functions such as Azure Cosmos communication cmdlets.
How do I load functions only on certain platforms?
Do you need to write something in C# to achieve this, or nest a module for a specific platform in my main module?
The comments mention correctly you can wrap up a command with a version check.
That's a great option for a small use command.
I'd recommend as a better module design to just have two modules, one for each platform.
This would allow you to better seperate your work, and not rely on many embedded logic steps that conditionally run actions on different platforms. To me this is just cleaner.
As you get started on modules, I'd highly recommend you use a template to bootstrap your project. I've found that it saves a lot of time, and sets me up for best practices.
My personal favorite is PSModuleDevelopment which you can use like this:
Install-Module PSModuleDevelopment -Scope CurrentUser
Get-Help 'Invoke-PSMDTemplate'
This is very similar to the loading structure some very mature projects like dbatools and PSFramework use. If you use this, you benefit primarily from:
Being able to seperate all your functions into their own files and load them easily
Some nice enhancements to preload configurations in your module
Pester test template included
I stopped trying to write my own module structure and just leveraged a development module like this, and it's been very helpful for me.
Good luck!
Related
Is there an equivalent to Powershell make? The equivalent of make/rake/cake/py-make, even Gulp...etc? I primarily desire a task runner for build automation. I want to be able to select and compose tasks like I can in Gulp.
Ideally, the solution would be native to Powershell. There are very tight security restrictions on software installations for the project. The power of Google has failed me.
nothing built-in, but there are different solutions like psake or invoke-build. maybe something else.
You can also use VScode for that, you can define tasks (basically run scripts or something) and run them on save or on check out, etc
I am about to write a PowerShell Script for Windows administrators, in order to help them in certain tasks related to deployment of a web application.
Is there any reason I should favor or exclude the development of a PowerShell Module (.psm1) instead of doing a PowerShell script (.ps1)?
Arguments to develop a Script
simplicity: I think that using a script is a bit easier and more straightforward for Windows Administrators as it does not require the module to be installed (but I might be wrong as I am not a Windows Admin!).
faster development: developing a module requires more careful programming an exposure to internal methods. It is like designing an API an thus must be more rigorous.
Arguments to develop a Module:
reusability: this is the first thing that comes to mind: if the administrator wants to integrate our script in his own script, it might be easier for him to reuse a module exposing one (or several) cmdlet rather than invoke our script?
...
If you know the common use case of PS scripts vs PS modules, or the technical limitations of each choice, it might help.
To understand what modules can do for you, read this: https://learn.microsoft.com/en-us/powershell/scripting/developer/module/writing-a-windows-powershell-module?view=powershell-7.1
In a nutshell,
Windows PowerShell modules allow you to partition, organize, and abstract your Windows PowerShell code into self-contained, reusable units. With these reusable units, administrators, script developers, and cmdlet developers can easily share their modules directly with others. Script developers can also repackage third-party modules to create custom script-based applications. Modules, similar to modules in other scripting languages such as Perl and Python, enable production-ready scripting solutions that use reusable, redistributable components, with the added benefit of enabling you to repackage and abstract multiple components to create custom solutions.
If your script already has functions and is not just written to perform a single task, you can just rename it to .PSM1 to convert it to module. If you are not using functions, of course, there is no choice but to go for .ps1. In such a case, each .ps1 will be used to perform a single task. I always prefer modules when sharing the scripts I write with others.
I like modules for the ability to "hide" functions/variables and only export the ones that I want.
I am working on a project where we need to repeat certain steps with powershell to deploy stuff. i would like to create a process/install guidance (steps supported with UI) with WIX but after the msi has finished i have an entry in programs and features. I just need it to execute the powershell and the end without registering in windows. i might be using the wrong tooling or whatever, any suggestions are welcome.
Definitely not recommended unless you want to track the deployment of these scripts on different systems by checking the entries in ARP (Add/Remove Programs), and even then it clogs up the Add/Remove view of your computers. Most system administrators hate this approach, it is better to just write to your own registry key and read it back from every machine.
What are the scripts doing? Are you actually installing files.
I am about to write a PowerShell Script for Windows administrators, in order to help them in certain tasks related to deployment of a web application.
Is there any reason I should favor or exclude the development of a PowerShell Module (.psm1) instead of doing a PowerShell script (.ps1)?
Arguments to develop a Script
simplicity: I think that using a script is a bit easier and more straightforward for Windows Administrators as it does not require the module to be installed (but I might be wrong as I am not a Windows Admin!).
faster development: developing a module requires more careful programming an exposure to internal methods. It is like designing an API an thus must be more rigorous.
Arguments to develop a Module:
reusability: this is the first thing that comes to mind: if the administrator wants to integrate our script in his own script, it might be easier for him to reuse a module exposing one (or several) cmdlet rather than invoke our script?
...
If you know the common use case of PS scripts vs PS modules, or the technical limitations of each choice, it might help.
To understand what modules can do for you, read this: https://learn.microsoft.com/en-us/powershell/scripting/developer/module/writing-a-windows-powershell-module?view=powershell-7.1
In a nutshell,
Windows PowerShell modules allow you to partition, organize, and abstract your Windows PowerShell code into self-contained, reusable units. With these reusable units, administrators, script developers, and cmdlet developers can easily share their modules directly with others. Script developers can also repackage third-party modules to create custom script-based applications. Modules, similar to modules in other scripting languages such as Perl and Python, enable production-ready scripting solutions that use reusable, redistributable components, with the added benefit of enabling you to repackage and abstract multiple components to create custom solutions.
If your script already has functions and is not just written to perform a single task, you can just rename it to .PSM1 to convert it to module. If you are not using functions, of course, there is no choice but to go for .ps1. In such a case, each .ps1 will be used to perform a single task. I always prefer modules when sharing the scripts I write with others.
I like modules for the ability to "hide" functions/variables and only export the ones that I want.
I am currently writing a deployment script in MSBUILD, and after downloading several extensions, I have found myself looking at the build file and thinking:
What was the point in doing this in MSBUILD?
This deployment script is completely procedural: stop website, delete folder, copy files, change permissions, start website, etc. There is no fancy dependency stuff which I assume is the natural domain of tools like MSBUILD, NANT and MAKE.
The only reason I can see to use MSBUILD is that it comes as standard, and its easy to put the extensions into your SVN so builds 'just work'.
The problem with it is I have to spend all this time working out how to do 'basic stuff' in MSBUILD (locating extensions, working out syntax) which would be trivial (although more verbose) in Powershell or even command line.
So to sum up:
Are procedural tasks suited to MSBUILD or are you better of using something like Powershell?
Check out PSAKE and see what you think.
http://www.jameskovacs.com/blog/IntroducingPsake.aspx
http://powerscripting.wordpress.com/2009/01/25/episode-56-james-kovacs-talks-about-psake/
http://code.google.com/p/psake/
Experiment! Enjoy! Engage!
Jeffrey Snover [MSFT] Windows Management Partner Architect
MSBuild is not a scripting language and shouldn't be used as such. It's almost unfortunate that MSBuild has such a rich extensibility and is flexible enough to be used for just about anything. Use the tools that are most appropriate to the task, if you find yourself spending too much time creating functionality that is too limited and too low quality compared to what you'd be able to create with other technology, you should switch.
It really depends on your situation. If it were up to me, though, and you were using Visual Studio - I would say yes, stay with MSBuild for the sake of integration.
On the other hand, I would choose MSBUILD, as while the tasks are very procedural, it gives you the flexibility to extend this build process later on to handle more complex tasks.
msbuild comes with .NET. You have to add powershell to servers / users must add it - at least through Windows XP, server 2003. That may or may not be a problem in your environment.
I don't think procedural tasks are suited for writing in MSBUILD, simply because the shorter the msbuild, the better as far as I am concerned. I might use msbuild to call them, but would probably write an extension library to implement them.
I think it depends on how your release and deployment process flows, as to wither it makes sense to use an MSBuild extension or execute power-shell. MSBuild allows the flexiablity to handle all your process steps in one self contained execution flow.
If you need it to occur all at one time then MSBuild gives you control over the 'Events' or targets that can be overridden to meet your requirement.
If the requirement is deploy your artifacts after compiling your code then MSBuild is well suited to do this since you can use the 'AfterBuild' target that gets triggered during an MSBuild standard execution. It can make your process self contained.
Powershell cannot build your code. It would have to call MSBuild from within your script. To me it is a matter of having your build and deployment self-contained and therefore would be organized better.
MSBuild is the core Microsoft build platform and engine.