Let's get stuck right in taking a look at
working with package management and
repositories. We are back at the trusty
PowerShell prompt here, and if we start by
running Get‑Command ‑Module
PackageManagement, we'll see the list of
PowerShell commands that can be used to
discover and manage software packages,
which hooks directly into the
PackageManagement core framework we took a
look at in the previous clip. Out of these
commands, I'd like to run just one, which
is Get‑PackageProvider. And we're returned
with a list of the default providers that
are installed and configured. Now,
thinking back to the image we looked at in
the previous clip, there were a number of
providers that were colored with green,
meaning they were there by default. But,
we're only seeing two of them here. If I
were to run this same command in Windows
PowerShell, I'd see some other providers
like MSI, programs, etc. This is because
we're running PowerShell 7, and I don't
believe it yet supports some of the other
package providers. But that's okay because
the one that we're interested in is
PowerShellGet, and this is what we're
going to focus on for the rest of this
course. I do also want to quickly point
out that with the PowerShell 7
installation comes this NuGet provider.
NuGet is the package manager for .NET, and
PowerShell is heavily built on the .NET
Framework. If you're following along, you
probably have this installed already, but
if you don't, the first time you try and
install a module from the gallery you'll
get asked to install NuGet. So if you get
that prompt, that's okay to approve. Let's
take a look at what commands are in that
PowerShellGet module by running
Get‑Command ‑Module PowerShellGet.
Alrighty, there we go. There are some
commands here that you are going to get
very familiar with when you start working
with PowerShell modules as these are the
commands that you will use to both
discover modules in repositories, and then
install and manage them on your machine.
If I run Get‑PSRepository with no
parameters, PowerShell will return a list
of the registered repositories on my
machine. As I suspected, there's only one
result, which is for the PowerShell
Gallery, which is that default gallery
owned and hosted by Microsoft. Do note
here that it is actually Untrusted by
default, and you'll see in the next clip
when we try to install a module that we
have to accept a prompt to confirm that we
trust that repository and that we want to
use it. I'd like to show you that you can
add additional repositories to have at
your disposal, and these could be private
repositories or other public repositories.
There's an article here on the Microsoft
Docs website that I want to draw your
attention to named Working with Private
PowerShellGet Repositories. If I scroll
down a little, this section titled Local
repository types outlines the two types of
local PowerShell repositories that you can
deploy, the first being a NuGet‑based
server, which has very similar
functionality to the PowerShell Gallery,
and the second being a stock standard File
Share. Each of these have advantages and
disadvantages, as you can see outlined
here. And if you are looking seriously
into having a private repository for your
company or organization, I'd strongly
recommend you come here to check out this
page to see which one is best going to
suit your needs. Let's jump back over the
PowerShell and run through creating a file
share‑based repository. I'm going to
create a new folder on this computer by
running New‑Item in the ‑Path
C:\LocalPSRepo, and then setting the
‑ItemType as a Directory. From there, I
can create a share on that folder by
running New‑SmbShare. For the ‑Name, I'll
just call it LocalPSRepo, and the ‑Path
was C:\LocalPSRepo. We now have a file
share that can be used as the target for a
private PowerShell repository. And we can
register that into our session by running
Register‑PSRepository, ‑Name LocalPSRepo.
Now that name doesn't have to be the same
name as the share, I'm just doing that
because I'm not a creative person.
‑SourceLocation is the share path, so
that's \\localhost\LocalPSRepo. And the
‑ScriptSourceLocation, again, is
\\localhost\LocalPSRepo. I'm also going to
use the InstallationPolicy parameter to
set this as a trusted repository from the
get‑go. And if we execute that, as I said
earlier, no news is usually good news, so
let's run Get‑PSRepository again. And yep,
there we can see that LocalPSRepo is now
listed as a PowerShell repository. What
does this mean? Well, it means we can now
use other commands from the PowerShellGet
module, and they will look not only in the
PowerShell Gallery online, but they will
also work with modules that may be located
in that private repository. Now, there's
obviously none in there at the moment
because I just created it. But imagine if
this was a private repository for a large
company like Globomantics, and they
published all of their privately developed
modules here. I'd be able to use those
same commands from PowerShellGet to find
and install modules from any repo,
including this private one. Before we move
on, the last thing I want to demonstrate
is that you can change the installation
policy of a repository by using
Set‑PSRepository. So, I could set the name
as the PSGallery, and then configure the
installation policy to be trusted. If I
run Get‑PSRepository again, you will
notice that the policy has changed to
Trusted. I'm going to drop that back to
Untrusted because I want to show you the
default behavior when we start finding and
installing modules, which is coming up next.