Perguntas mais frequentes sobre o Galeria do PowerShell

Um módulo do PowerShell é um pacote reutilizável que contém algumas funcionalidades do PowerShell. Tudo no PowerShell (funções, variáveis, recursos DSC, etc.) pode ser empacotado em módulos. Normalmente, os módulos são pastas que contêm tipos específicos de ficheiros armazenados num caminho específico. Existem alguns tipos diferentes de módulos do PowerShell.

Um script do PowerShell é uma série de comandos armazenados num ficheiro .ps1 para ativar a reutilização e a partilha. Os fluxos de trabalho do PowerShell também são scripts do PowerShell, que descrevem um conjunto de tarefas e fornecem sequenciação para essas tarefas. Para obter mais informações, visite Introdução com o Fluxo de Trabalho do PowerShell.

Geralmente, os módulos são melhores para partilhar, mas estamos a ativar a partilha de scripts para facilitar a contribuição de fluxos de trabalho e scripts para a comunidade. Para obter mais informações, consulte os seguintes blogues:

• Não Escrever Scripts, Escrever Módulos do PowerShell
• Compreender os Módulos do PowerShell

Tem de registar uma conta no Galeria do PowerShell antes de poder publicar pacotes na Galeria. Isto deve-se ao facto de os pacotes de publicação exigirem um NuGetApiKey, que é fornecido após o registo. Para se registar, utilize a sua conta pessoal, profissional ou escolar para iniciar sessão no Galeria do PowerShell. É necessário um processo de registo único quando inicia sessão pela primeira vez. Posteriormente, o NuGetApiKey está disponível na sua página de perfil.

Depois de se registar na Galeria, utilize os cmdlets Publish-Module ou Publish-Script para publicar o seu pacote na Galeria. Para obter mais detalhes sobre como executar estes cmdlets, aceda ao separador Publicar ou leia a documentação Publish-Module e Publish-Script .

Não precisa de se registar ou iniciar sessão na Galeria para instalar ou guardar pacotes.

A mensagem de erro completa é: "Falha ao processar o pedido". "A chave de API especificada é inválida ou não tem permissão para aceder ao pacote especificado." O servidor remoto devolveu um erro: (403) Proibido."

Este erro pode ocorrer pelos seguintes motivos:

• A chave de API especificada é inválida. Certifique-se de que especificou a chave de API válida da sua conta. Para obter a chave de API, veja a sua página de perfil.
• O nome do pacote especificado não pertence a si. Se tiver confirmado que a chave de API está correta, poderá já existir um pacote com o mesmo nome que está a tentar utilizar. O pacote pode ter sido não listado pelo proprietário, caso em que não será apresentado nos resultados da pesquisa. Para determinar se já existe um pacote com o mesmo nome, abra um browser e navegue para a página de detalhes do pacote: https://www.powershellgallery.com/packages/<packageName>. Por exemplo, navegar diretamente para https://www.powershellgallery.com/packages/pester irá levá-lo para a página de detalhes do módulo Pester, quer esteja ou não na lista. Se já existir um pacote com um nome em conflito e não estiver na lista, pode:
  • Selecione outro nome para o seu pacote.
  • Contacte os proprietários do pacote existente.

Tenha em atenção que a sua conta de galeria não acomoda alterações ao seu alias de e-mail principal. Para obter mais informações, veja Microsoft Email Aliases.

Ao selecionar uma caixa de verificação Categoria, está a indicar "Gostaria de ver todos os pacotes nesta categoria". Apenas os pacotes nas categorias selecionadas serão apresentados. Da mesma forma, ao selecionar todas as caixas de verificação Categoria, está a indicar "Gostaria de ver todos os pacotes em qualquer categoria". Mas alguns pacotes na galeria não pertencem a nenhuma das categorias listadas, pelo que não serão apresentados nos resultados. Para ver todos os pacotes na galeria, desmarque todas as Categorias ou selecione novamente o separador pacotes.

Qualquer tipo de módulo do PowerShell (módulos de script, módulos binários ou módulos de manifesto) pode ser publicado na galeria. Para publicar um módulo, o PowerShellGet precisa de saber algumas coisas sobre o mesmo: a versão, a descrição, o autor e como é licenciado. Estas informações são lidas como parte do processo de publicação do ficheiro de manifesto do módulo (.psd1) ou do valor do parâmetro LicenseUri do cmdlet Publish-Module. Todos os módulos publicados na Galeria têm de ter manifestos de módulo. Qualquer módulo que inclua as seguintes informações no respetivo manifesto pode ser publicado na Galeria:

• Versão
• Descrição
• Autor
• Um URI para os termos de licenciamento do módulo, quer como parte da secção PrivateData do manifesto, quer no parâmetro LicenseUri do cmdlet Publish-Module .

A forma mais fácil de criar um manifesto de módulo é executar o cmdlet New-ModuleManifest . No PowerShell 5.0 ou mais recente, New-ModuleManifest gera um manifesto de módulo corretamente formatado com campos em branco para metadados úteis como ProjectUri, LicenseUri e Etiquetas. Basta preencher os espaços em branco ou utilizar o manifesto gerado como um exemplo de formatação correta.

Para verificar se todos os campos de metadados necessários foram preenchidos corretamente, utilize o cmdlet Test-ModuleManifest .

Para atualizar os campos de ficheiro de manifesto do módulo, utilize o cmdlet Update-ModuleManifest .

Qualquer tipo de script do PowerShell (scripts ou fluxos de trabalho) pode ser publicado na galeria. Para publicar um script, o PowerShellGet precisa de saber algumas coisas sobre o mesmo: a versão, a descrição, o autor e como é licenciado. Estas informações são lidas como parte do processo de publicação da secção PSScriptInfo do ficheiro de script ou do valor do parâmetro LicenseUri do cmdlet Publish-Script. Todos os scripts publicados na Galeria têm de ter informações de metadados. Qualquer script que inclua as seguintes informações na secção PSScriptInfo pode ser publicado na Galeria:

• Versão
• Descrição
• Autor
• Um URI para os termos de licença do script, quer como parte da secção PSScriptInfo do script, quer no parâmetro LicenseUri do cmdlet Publish-Script .

Escreva o que procura na caixa de texto. Por exemplo, se quiser encontrar módulos relacionados com SQL do Azure, basta escrever "azure sql". O nosso motor de busca irá procurar essas palavras-chave em todos os pacotes publicados, incluindo títulos, descrições e metadados. Em seguida, com base numa classificação de qualidade ponderada, apresentará as correspondências mais próximas. Também pode procurar por campo específico com a sintaxe field:"value" na consulta de pesquisa dos seguintes campos:

• Etiquetas
• Funções
• Cmdlets
• DscResources
• PowerShellVersion

Assim, por exemplo, quando procura o PowerShellVersion:"2.0" apenas os resultados compatíveis com o PowerShellVersion 2.0 (com base no respetivo manifesto de módulo/script) serão apresentados.

A forma mais fácil de criar um ficheiro de script devidamente formatado é executar o cmdlet New-ScriptFileInfo . No PowerShell 5.0, New-ScriptFileInfo gera um ficheiro de script formatado corretamente com campos em branco para metadados úteis como ProjectUri, LicenseUri e Tags. Basta preencher os espaços em branco ou utilizar o ficheiro de script gerado como um exemplo de formatação correta.

Para verificar se todos os campos de metadados necessários foram preenchidos corretamente, utilize o cmdlet Test-ScriptFileInfo .

Para atualizar os campos de metadados do script, utilize o cmdlet Update-ScriptFileInfo .

O termo módulo do PowerShell também se refere aos ficheiros que implementam a funcionalidade real. Os ficheiros do módulo de script (.psm1) contêm código do PowerShell. Os ficheiros do módulo binário (.dll) contêm código compilado.

Eis uma forma de pensar: a pasta que encapsula o módulo é a pasta do módulo. A pasta do módulo pode conter um manifesto de módulo (.psd1) que descreve o conteúdo da pasta. Os ficheiros que realmente fazem o trabalho são os ficheiros do módulo de script (.psm1) e os ficheiros do módulo binário (.dll). Os recursos do DSC estão localizados numa subpasta específica e são implementados como ficheiros de módulo de script ou ficheiros de módulo binário.

Todos os módulos na Galeria contêm manifestos de módulo e a maioria destes módulos contém ficheiros de módulo de script ou ficheiros de módulo binário. O termo módulo pode ser confuso devido a estes diferentes significados. Salvo indicação explícita do contrário, todas as utilizações do módulo de palavras nesta página referem-se à pasta do módulo que contém estes ficheiros.

PackageManagement é uma interface comum para trabalhar com qualquer gestor de pacotes. Eventualmente, quer esteja a lidar com módulos do PowerShell, MSIs, gems ruby, pacotes NuGet ou módulos Perl, deverá conseguir utilizar os comandos do PackageManagement (Find-Package e Install-Package) para os localizar e instalar. O PackageManagement faz isto ao ter um fornecedor de pacotes para cada gestor de pacotes que se liga ao PackageManagement. Os fornecedores fazem todo o trabalho real; obtêm conteúdos de repositórios e instalam o conteúdo localmente. Muitas vezes, os fornecedores de pacotes simplesmente envolvem as ferramentas existentes do gestor de pacotes para um determinado tipo de pacote.

O PowerShellGet é o gestor de pacotes para pacotes do PowerShell. Existe um fornecedor de pacotes PSModule que expõe a funcionalidade PowerShellGet através do PackageManagement. Por este motivo, pode executar Install-Module ou Install-Package -Provider PSModule instalar um módulo a partir do Galeria do PowerShell. Determinadas funcionalidades do PowerShellGet, incluindo Update-Module e Publish-Module, não podem ser acedidas através dos comandos PackageManagement.

Em resumo, o PowerShellGet concentra-se apenas em ter uma experiência de gestão de pacotes premium para conteúdos do PowerShell. O PackageManagement está focado em expor todas as experiências de gestão de pacotes através de um conjunto geral de ferramentas. Se achar esta resposta insatisfatória, existe uma resposta longa na parte inferior deste documento, na secção Como é que o PackageManagement está realmente relacionado com o PowerShellGet?

Para obter mais informações, visite a página do projeto PackageManagement.

A Galeria do PowerShell é uma versão modificada da Galeria NuGet. O PowerShellGet utiliza o fornecedor NuGet para trabalhar com repositórios baseados em NuGet, como o Galeria do PowerShell.

Pode utilizar o PowerShellGet em relação a qualquer repositório NuGet válido ou partilha de ficheiros. Basta adicionar o repositório ao executar o cmdlet Register-PSRepository .

Sim.

Nos bastidores, o PowerShellGet tira partido da infraestrutura PackageManagement.

Na camada do cmdlet do PowerShell, Install-Module é, na verdade, um wrapper dinâmico em torno de Install-Package -Provider PSModule.

Na camada do fornecedor de pacotes PackageManagement, o fornecedor de pacotes PSModule chama efetivamente outros fornecedores de pacotes PackageManagement. Por exemplo, quando estiver a trabalhar com galerias baseadas em NuGet (como a Galeria do PowerShell), o fornecedor de pacotes PSModule utiliza o Fornecedor de Pacotes NuGet para trabalhar com o repositório.

Figura 1: Arquitetura do PowerShellGet

Em geral, recomendamos escolher a versão mais recente do módulo PowerShellGet (tenha em atenção que requer o .NET 4.5).

O módulo PowerShellGet requer o PowerShell 3.0 ou mais recente.

Por conseguinte, o PowerShellGet requer um dos seguintes sistemas operativos:

• Windows 10
• Windows 8.1 Pro
• Windows 8.1 Enterprise
• Windows 7 SP1
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2008 R2 SP1

O PowerShellGet também requer .NET Framework 4.5 ou superior. Para obter mais informações, veja Instalar o .NET Framework para programadores.

Não é possível agachar nomes de pacotes. Se achar que um pacote existente utilizou o nome mais adequado ao seu pacote, tente contactar o proprietário do pacote. Se não obteve resposta dentro de algumas semanas, pode contactar o suporte e a equipa de Galeria do PowerShell irá analisá-la.

Consulte Gerir Proprietários de Pacotes no PowerShellGallery.com para obter detalhes.

Encorajamos a comunidade do PowerShell a trabalhar em conjunto para resolver quaisquer litígios que possam surgir entre os proprietários de pacotes e os proprietários de outros pacotes. Criámos um processo de resolução de litígios que lhe pedimos que siga antes de PowerShellGallery.com administradores intercetarem.