<p>Plano PowerShell 6.0</p>

Posso escrever módulos binários direcionados ao Windows PowerShell e PowerShell Core

Isso já funciona - visando o .NET Standard 1.6. A parte difícil é carregar assemblies específicos do sistema operacional - precisamos do /lib/{OS}/*.dll carregamento automático de RequiredAssemblies ?

Cliente WinRM com Kerberos e autenticação de certificado de cliente, de Linux e Mac OS X é algo que considero essencial. Estamos procurando a capacidade de implantar código PowerShell remoto em sistemas Windows a partir de sistemas não Windows, por meio de contêineres Docker.

O NTLM cobriria esse cenário de maneira segura? Não tenho certeza sobre os prós / contras de NTLM versus Kerberos, mas de qualquer forma, acho que a autenticação de certificado de cliente seria um tópico separado.

LMK

Felicidades,
Trevor Sullivan

Eu concordo totalmente com o que @ pcgeek86 está dizendo,
Há um módulo YAML da comunidade, mas seria possível integrar cmdlets YAML da mesma forma que ConvertTo / ConvertFrom- * já existe para CSV / XML / JSON?

@ pcgeek86 @fabiendibot bom ouvir. Eu, então, coloco a pergunta: você está bem para juntar suas máquinas com Linux (ou Mac) ao AD? Ou você espera lidar manualmente com os certificados?

Melhor ainda, qual é o bloqueador para você usando PSRP sobre SSH de Mac / Linux para Windows? Você tem algum tipo de solução cert que seja mais simples do que pares de chaves públicas / privadas?

Já temos um sistema de publicação de certificados separado em vigor, então isso está resolvido.

Terei que ver como o PowerShell Remoting sobre SSH funciona antes de comentar mais sobre esse cenário. A partir deste ponto, não estou ciente de qualquer implementação funcional dele. A solução precisaria funcionar em sistemas operacionais Windows de nível inferior.

Eu também adicionaria alguma ênfase na construção de módulos binários em torno do .NET Standard. Fico feliz em ver que isso foi adicionado lá. Talvez devêssemos adicionar algo sobre como carregar assemblies .NET no PowerShell e chamá-los? Sei que muita coisa mudou no .NET Core, com relação a AppDomains, reflexão e assim por diante ... Acho que essa área merece atenção.

eu concordo com @Jaykul e @ pcgeek86
um Gac PowerShell ou pasta de biblioteca seria bom ...
isso nos ajudará a gerenciar assemblies que nossos módulos correspondentes estão usando / instalando ...
acho que node / python também tem esse conceito ...

@joeyaiello Nós configuramos

O .NET Framework 4.6.1 funciona no Windows 7?

sim
https://www.microsoft.com/en-us/download/details.aspx?id=49981&e6b34bbe-475b-1abd-2c51-b5034bcdd6d2=True

Sistemas operacionais suportados:
• Windows 7 SP1 (x86 e x64)
• Windows 8 (x86 e x64)
• Windows 8.1 (x86 e x64)
• Windows 10
• Windows Server 2008 R2 SP1 (x64)
• Windows Server 2012 (x64)
• Windows Server 2012 R2 (x64)

O que há sobre os recursos de classe?
A implementação da interface ainda está faltando.

Este foi o roteiro no final de 2014:

O PowerShell precisa ser SOLID em 6.0 ( https://en.wikipedia.org/wiki/SOLID_ (object-oriented_design))

A área de linguagem precisa de mais atenção, especialmente estas questões:
https://github.com/PowerShell/PowerShell/issues/2223
https://github.com/PowerShell/PowerShell/issues/2642
https://github.com/PowerShell/PowerShell/issues/2225
https://github.com/PowerShell/PowerShell/issues/2217

Obrigado !

Talvez seja útil traçar este roteiro usando o (s) Projeto (s) GitHub.

Ter interfaces seria legal!

@iSazonov , consideramos usar projetos GitHub, mas decidimos (por enquanto) que seria mais fácil acompanhar o progresso como caixas de seleção em um problema

Neste momento, nosso pensamento é investir na experiência do desenvolvedor (melhorias de classe, bem como coisas como ligações para outras linguagens, cmdlets de autoria em outras linguagens, etc ...) postar 6.0 em vez de continuar a adicionar recursos no 6.0.

Bem, agora a experiência do desenvolvedor não é tão boa! ISE é uma piada sem ISESteroids, e VS CODE é cheio de bugs. Isso está nos deixando com o PowerShell Studio como a única opção, mas o intellisense quase não existe.
Então, talvez a coisa certa a fazer seja investir no desenvolvimento de um bom IDE, com suporte aos recursos do PS 5-6.

@ g8tguy, nosso plano é investir no VS Code especificamente por meio do PowerShellEditorServices , pois é um código aberto e multiplataforma. Se houver problemas ou recursos específicos que o impeçam de usar o VS Code, abra os problemas nesse repositório.

@ g8tguy se o VS Code estiver "

https://github.com/PowerShell/vscode-powershell

A última vez que tentei VS Code foi há meio ano.
E o language server estava constantemente travando quando você
abas abertas de 5 a 10 com classes PS 5 e enums referenciando umas às outras, então IntelliSense parou de funcionar e IDE estava se comportando de maneira estranha. Eu queria portar PowerShellEditorServices para IDEA , mas parecia muito trabalhoso para uma pessoa, então fiquei com PS Studio . Mas como estou vendo o changelog PowerShellEditorServices agora, certamente parece que muitos dos bugs foram resolvidos e VS Cod e se tornaram mais maduros e estáveis, então vou tentar novamente. E obrigado pessoal pelo produto, vocês estão fazendo um ótimo trabalho, defendendo o PowerShell! 👍: 1st_place_medal:

@ g8tguy sim, muita coisa mudou desde então. Se você ainda tiver problemas ao desenvolver scripts com classes no VS Code, ficarei feliz em tentar corrigi-los. Certamente é possível fazer o Editor Services funcionar no IDEA, se você tentar novamente, ficarei feliz em lhe dar algumas dicas.

Posso confirmar - as versões mais recentes do PS Code são boas! Aconteceu nos últimos meses. Muito obrigado aos desenvolvedores do PS Code!

Que tal suporte para caminhos longos / nomes de arquivo? Como o .NET Core agora os oferece suporte, sei que há esperança de que isso chegue ao PowerShell eventualmente - https://github.com/dotnet/corefx/issues/645. Tenho certeza de que haverá muita alegria no mundo empresarial se / quando isso acontecer.

@itpaul PowerShell Core já oferece suporte a caminhos longos por padrão :)

@ SteveL-MSFT Sweet! Obrigado por compartilhar. Alguma ideia de quando isso poderia chegar ao PS não Core?

@itpaul PowerShell v5.1 no Win10 já oferece suporte, mas não é o padrão (uma vez que o sistema operacional não oferece suporte por padrão, se o Win10 alterar essa configuração, ele funcionará automaticamente). Você pode ativá-lo seguindo este: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

@ SteveL-MSFT Fantástico! Obrigado novamente por sua ajuda. Vou começar a pesquisar isso. Após sua primeira resposta, descobri que você pode executar o PowerShell Core portavelmente, o que também é fantástico! Parece que poderei evitar a implementação do Alpha FS em nosso ambiente agora.

@itpaul uma das decisões que queríamos ir com CoreCLR além do suporte multiplataforma é que ele inerentemente suporta lado a lado, então você pode "instalar" (que é realmente um xcopy) do PSCore6.0 e ele vai rodar felizmente ao lado do Windows PowerShell v5.x sem afetar scripts / aplicativos existentes que dependem da v5.x

@ SteveL-MSFT Porcos realmente podem voar no mundo Nadella da Microsoft. O Natal definitivamente chegou mais cedo este ano.

1. Parece que temos problemas com o conhost referido em algumas edições. Esta não é apenas uma barra de progresso.
2. Para a barra de progresso, o desempenho # 2822 é aberto.
3. Seria bom ter uma análise de código para desempenho (segurança, qualidade, formatação).
4. Poderíamos obter um ótimo feedback do Windows 10 Preview se integrado a este programa. (Na WSL também)
5. O plano não menciona WSL (Windows Subsystem for Linux). Esta pode ser uma ótima plataforma para teste e promoção do Powershell Core. Agora temos problemas com WSL.

Ótimo trabalho! Você está planejando oferecer suporte ao Docker também (estamos planejando enviar módulos do PowerShell Core)? Você também poderia fazer o upload das notas ou da gravação da 2ª RFC, como fez na primeira?

@HemantMahawar está a gravação pronta para ser carregada da última chamada da comunidade?

@iSazonov : Você poderia me vincular a alguns desses problemas do conhost? Os dois que tenho acima, # 2138 e # 1625, parecem-me problemas de progresso. (Em minha mente, mesmo se eles forem causados ​​pelos hosts de console subjacentes, temos tão pouco controle sobre os hosts subjacentes nas plataformas que a funcionalidade de progresso é o que precisa ser refatorado ou mesmo limitado). Além disso, adicionou # 2822. 👍

Eu concordo com você na análise de código. Talvez @JamesWTruher ou @ SteveL-MSFT possam criar um problema para eu adicionar aqui?

Eu ouvi você sobre o suporte WSL, mas acho que estamos priorizando distros Linux e macOS agora devido à falta de cenários atraentes para usar o PowerShell do WSL. Além disso, acho que eles eventualmente (isto é apenas de conhecimento público com nenhum conhecimento interno de cronogramas ou como a funcionalidade pode funcionar) planejam interoperar com processos do Windows, caso em que você não precisaria executar o "PowerShell no Linux" de dentro WSL, mas apenas "PowerShell Core 6.0 no Windows".

Se você discordar da minha declaração sobre "cenários atraentes", por favor, me avise. Eu adoro ser provado que estou errado nesse tipo de coisa :)

@ ChristophB125 : você poderia explicar melhor o que entende por "suporte ao Docker"? Atualmente, temos Docker listado como uma plataforma e publicamos uma tonelada de imagens no Docker Hub (incluindo nightlies , embora pareça que esquecemos de publicar alpha.15, estou acompanhando).

Se você quer dizer, temos um módulo do PowerShell para gerenciar o Docker, a equipe do Hyper-V já fez exatamente isso . Ele já é compatível com Windows PowerShell 5.x, bem como PowerShell Core 6.0 no Windows, Nano, macOS e Linux.

Por curiosidade, quem somos "nós"? Adoraria falar mais sobre como você está usando o PowerShell 6.0 :)

Além disso, tenho más notícias. Parece que as caixas de seleção NÃO são marcadas automaticamente quando os problemas são fechados (pelo menos não no nível L3). Fechei o # 2245 e ele não foi verificado por si mesmo (e aquele em que a linha inteira é apenas o número do problema ...) 👎

@joeyaiello enviar solicitação de recurso para GitHub 😸

@ ChristophB125 A gravação da segunda chamada da comunidade está agora disponível no PowerShell e Canal da equipe DSC / cc: @ SteveL-MSFT & @joeyaiello

@joeyaiello

Você poderia me vincular a alguns desses problemas conhost?

Oh, é difícil de fazer, mas parece que reuni os principais juntos (acredito que há outros comentários úteis que perdemos.)

Se você discordar da minha declaração sobre "cenários atraentes", por favor, me avise. Eu adoro ser provado que estou errado nesse tipo de coisa :)

Eu concordo, mas ainda existem "cenários atraentes".
A Microsoft anuncia o WSL como um recurso de desenvolvedor "eliminado":

O WSL foi projetado e construído pela equipe do Kernel do Windows e entregue em parceria com a Canonical, para ajudar os desenvolvedores do Windows 10 a usar o rico ecossistema de desenvolvedores Linux e ferramentas junto com as excelentes ferramentas que já estão usando no Windows, sem ter que inicializar em outro sistema operacional ou VM. Este é definitivamente um recurso do Windows 10 “por desenvolvedores para desenvolvedores”, projetado especificamente para remover um pouco de atrito do fluxo de trabalho diário dos desenvolvedores.

Como usuário do Windows, tentei usar o Powershell Core sob WSL e falhei 😕
Eu quero:

1. Desenvolver e testar scripts do PowerShell
2. Desenvolver e testar módulos binários do PowerShell
3. Construir Powershell Core a partir de fontes
4. Desenvolver e depurar recursos do Powershell Core

Eu acredito que isso está totalmente de acordo com o anúncio WSL da Microsoft.
Seria ótimo pedir à equipe do Kernel para nos ajudar a fazê-lo funcionar.

@joeyaiello Obrigado pela resposta. Sim, as imagens da docker do PowerShell são o que eu estava procurando. Isso seria ótimo porque o PowerShell pode ser enviado como parte da implantação (tememos que nossos clientes fiquem preocupados com o IP da Microsoft em suas máquinas Linux, portanto, o docker pode nos ajudar a esconder isso pelo menos no momento da instalação). A propósito, 'nós' está apenas se referindo vagamente à equipe da minha empresa para a qual trabalho, que não posso divulgar aqui. Embora sejamos um parceiro Microsoft Gold, as informações da equipe de desenvolvimento diretamente são muito valiosas para nós. Como o GitHub não permite mais mensagens privadas, enviei a você uma solicitação do LinkedIn se quiser saber um pouco mais sobre como usamos o PowerShell.

@HemantMahawar Obrigado pelo esforço. Estou ansioso para participar da próxima chamada!

@iSazonov - o problema de WSL que mais afeta você provavelmente é https://github.com/dotnet/corefx/issues/12452 - portanto, não requer uma correção no Windows - qualquer um poderia resolver isso (embora pareça como se não fosse uma solução simples ou já tivesse sido consertado.)

E depois de ler uma atualização do problema, talvez uma correção esteja vindo do WSL. Veremos.

@lzybkr Obrigado! Build 15025 ainda tem o bug. Aguardando a próxima construção.

@joeyaiello # 2882 mover para dotnet-resgen (compilar "file.En-Us.resx") e csproj.

@iSazonov : Você está dizendo que esses são dois itens separados, certo? O primeiro é um requisito para localização (algo que precisamos discutir com @ PowerShell / powershell-Committee, não tenho certeza de como faremos isso hoje), e o último é um requisito para mudar para .NET Core 2.0 (um requisito para suporte ao .NET Standard 2.0).

@joeyaiello , temos uma solução customizada para res-gen hoje, mas devemos mudar para a forma suportada por dotnet. csproj está mudando para msbuild, embora tenhamos conversado sobre isso, não vejo um problema para isso.

@joeyaiello Steve disse mais claramente do que eu. Já temos o problema para resgen dotnet e devemos abrir um problema para csproj. E devemos incluir os problemas no Plano em "dotnet 2.0"

Adicionada a bondade csproj / MSBuild, ainda devemos falar sobre resgen e se ele é necessário para 6.0.

Isso pode ser mais Hyper-V do que PowerShell (ou partes iguais de Hyper-V e PowerShell), mas pensei em mencioná-lo para ter certeza: Acho que é muito importante ter o PowerShell Direct funcionando para VMs Linux, bem como VMs Windows .

@ SteveL-MSFT Obrigado por focar na experiência do desenvolvedor como uma prioridade sobre a adição de novos recursos. Eu concordo totalmente com sua direção. Comece criando uma base sólida e adicione recursos pós-6.0. / cc @joeyaiello

AppImage # 2024 em Packaging, Installation, and Deployment

@joeyaiello # 2138 e # 1625 corrigidos - coloquei marcas no Plano.

Acho que a autenticação NTLM sobre SSH deve ser incluída na versão do mesmo modo que para WinRM

@joeyaiello # 3140 fixed - coloquei a marca no Plan.

@mnaiman ... na verdade, não tenho certeza se essa solicitação faz sentido do ponto de vista da criptografia. Eu o desafio a tentar o que está tentando fazer e relatar se não funcionar. Oferecemos suporte para autenticação por senha para contas de domínio e não-domínio em remoting baseado em SSH (com e sem PSRP). Não tenho certeza se ele passa por qualquer tipo de camada NTLM (já que não tenho certeza se o SSH suporta NTLM), mas não acho que deva importar de uma perspectiva funcional.

EDITAR: Talvez @manojampalam possa comentar aqui.

@mnaiman @joeyaiello atualmente, não suportamos SSO, já que o próprio SSH por padrão prefere autenticação interativa com teclado que funciona bem com NTLM e Kerberos contra Win32-OpenSSH. Portanto, isso é diferente do WinRM remoting, mas é consistente com SSH.

@joeyaiello @ SteveL-MSFT O provedor de SSH SSH é "gssapi-with-mic" (NTLM e Kerberos).

Ele permite logon único no Windows sem digitar a senha ou salvar a chave privada em algum lugar.
Alguma parte do gssapi já está aqui https://github.com/SimonWilkinson/gss-openssh/
Aqui implementação para cliente https://github.com/Lax/net-ssh-kerberos
Servidores gratuitos / comerciais que suportam gssapi PowershellServer & Bitwise SSH.

Aqui já está o pedido em https://github.com/PowerShell/Win32-OpenSSH/issues/96

Estou executando o PowerShell em uma máquina MAC.

$psversiontable
Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   3.0.0.0
GitCommitId                    v6.0.0-alpha.13
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Mas o comando send-mailmessage não está funcionando para mim. Estou recebendo mensagens abaixo.

send-mailmessage
send-mailmessage : The term 'send-mailmessage' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path
was included, verify that the path is correct and try again.
At line:1 char:1
+ send-mailmessage
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (send-mailmessage:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Estou tendo um problema com o PS 5.0 ao executar invoke-webrequest ... basicamente, se a resposta vier com aspas no valor utf-8, ela falhará. Isso será corrigido na versão GA (https://stackoverflow.com/questions/36275618/why-is-invoke-webrequest-and-invoke-restmethod-failing-and-succeeding-at-the-sam)

@pradeepprakhar Agora 'send-mailmessage' foi portado.

@jsburckhardt Abra um novo problema com a descrição completa do seu problema ou dúvida.

@joeyaiello # 929 e # 2227 foram corrigidos.

Fiz algumas atualizações na lista acima sobre o que está fechado / concluído e o que foi cortado do 6.0.0 e provavelmente irá parar no 6.1.0

Existem planos para adicionar suporte a comentários (ou pelo menos ignorá-los) na lista de ConvertFrom-Json ?

@erichiller , abra um novo problema, podemos considerar para 6.1.0

Apenas inclua o suporte Kerberos, por favor (e WinRM talvez também), então veremos isso novamente.

@VGerris se por WinRM você quer dizer WSMan, esse suporte já está incluído. Há suporte Kerberos experimental para WSMan em não Windows, embora seja muito complexo atualmente para fazê-lo funcionar.

Não, quero dizer Kerberos e WinRM exatamente como escrevi. Por favor, concentre-se em obter suporte para que não precise depender de scripts de terceiros. O que basicamente queremos é uma maneira de monitorar com eficiência uma máquina Windows por meio de uma solução sem agente e ser capaz de executar comandos remotos de maneira segura. Está claro no tópico que esta é uma característica principal na classificação de interesses, certo? Obrigado.

@VGerris Não entendo o que você quer dizer com WinRM , pois isso é compatível com Windows (e já funciona com PSCore6) e WinRM é um recurso exclusivo do Windows (Gerenciamento Remoto do Windows). WSMan é o protocolo que o WinRM implementa.

O seguinte diagrama de arquitetura a partir daqui pode ajudar a compreender WinRm-WSMan:

Eu entendo um pouco melhor por que esse diagrama é desenhado da maneira que estava quando eu olhei para ele no blog , mas é um pouco enganoso. Uma maneira básica de pensar sobre isso é que WSMan é o protocolo / padrão (abreviação de WS-Management) e WinRM é a implementação desse protocolo como um serviço no Windows.

@VGerris como @ SteveL-MSFT disse, o que você está falando pode funcionar tecnicamente, mas é extremamente difícil de configurar e requer que sua máquina Linux seja associada ao domínio AD (o que também é difícil de fazer). Por essas razões, atualmente não apoiamos formalmente esse cenário.

No entanto, a comunicação remota baseada em WSMan não é sem agente. Você ainda precisa executar o serviço WinRM em sua máquina Windows: isso é um agente. Na próxima versão do Windows 10 e do Windows Server, o próprio OpenSSH estará disponível como um recurso sob demanda com suporte, portanto, você terá suporte de caixa de entrada de primeira parte para comunicação remota baseada em SSH como ponto a ponto remoto baseada em WSMan.

Também estou encerrando este problema porque ele não tem mais utilidade. Devemos continuar acompanhando esse trabalho nas edições que foram criadas. Se você é apaixonado por algo aqui que não tem problema, abra um para que possamos rastreá-lo lá.

Eu também planejo consertar Projetos em algum momento, eu sei que isso está em um estado meio quebrado agora. Desculpe por isso, pessoal ....