Eu tenho um script powershell que depende do ISE (não funciona direito no console normal) devido ao uso de formulários.
Quando o script é executado, às vezes pode levar até 10 minutos para que o script seja concluído. No entanto, isso não é realmente um problema... Mas se o Powershell ISE estiver aberto e a conexão RDP for perdida (por exemplo, outro usuário se conectar à sessão), o PowerShell ISE não responderá e o script não funcionará mais. Eu tive o mesmo no meu computador local com instâncias diferentes. Por exemplo, se eu bloquear meu pc, isso também acontece.
Estranhamente, ainda posso clicar com o botão direito do mouse na entrada da barra de tarefas do powershell ISE e obter o pop-up. Eu posso fechar daqui bem, mesmo que o [x] não funcione mais. Se eu fechar dessa forma e o script tiver alterações nele, o Powershell ISE me perguntará se quero salvar minhas alterações e o fará, mas qualquer outra forma de interação parece impossível.
Alguém sabe o que posso fazer para corrigir o problema? Existe alguma maneira de atualizar o PowerShell ISE?
O servidor é o Windows Server 2016, meu pc é o Windows 10 Pro x64 v2004
Quanto a isso...
O PowerShell.exe não pode exibir formulários nativamente, por design. Para poder exibir o formulário, precisamos adicionar uma linha de código no topo do nosso script para dar suporte à renderização do formulário WinForm/WPF.
O ISE usa powershell_ise.exe, não powershell.exe ou pwsh.exe (PowerShell Core).
Seu código UX/UI nunca deve depender de um editor de código para ser executado.
Isso está bem documentado nos arquivos de ajuda do PowerShell, em toda a web. O ISE carrega automaticamente módulos/namespaces UX/UI, o host do console não.
No entanto, não prejudica / impacta em nada carregar todos os itens acima e garante a flexibilidade que cada um traz. Veja os documentos de cada um deles.
Quanto a isso...
... este não é um problema de UX/UI, é nosso código de back-end e levaria muito tempo, se você tivesse um UX/UI ou não.
Quanto a isso...
... se o seu código de back-end parar/travar, então sua UX/UI não tem ideia do que está acontecendo e espera que seu código de back-end diga a ele para fazer algo. UX/UI não é um monitor de código e não tem ideia do que seu código de back-end está fazendo. UX/UI é apenas uma exibição de resultados. Se não obtiver uma ação/evento para responder, ele será bloqueado, por design. Além disso, por padrão, o logon do RDS/RDP em um servidor não é mais do que duas conexões por vez, o que inclui o console. Portanto, a menos que você compre e implante uma licença RDS completa por licença de conexão necessária, você ficará preso ao que vê.
O ISE (ou outro editor de código) é um editor/designer para seus scripts, não a execução de seu script. Embora você possa testar seu código lá, isso é para fins de depuração, não para produção.
Você escreve o código no ISE/VSCode, etc., mas seu ambiente de execução/execução de destino é o host do console. Nenhum usuário deve ter que abrir um editor de código para executar seu código.
Quanto a isso...
...
A MS afirmou que, embora não haja mais trabalho no PowerShell v5x e no ISE; O WinPS e o ISE serão o que são hoje e estarão em versões completas do OS/.Net no futuro próximo. Assim, aqueles que preferem PSv5 e ISE podem continuar usando.
Assim, todo esforço no PowerShell Core multiplataforma (atualmente conhecido como PowerShell v7 para Windows/OSX/Linux).
Não há ISE para PowerShell Core. O editor do núcleo do PowerShell é o Visual Studio Code e, para usar o PowerShell com o VSCode, você precisa instalar a extensão do PowerShell.
bem, você pode realmente usar o ISE com Powershell Core, via PowerShell RunSpaces, se desejar. Veja como:
No entanto, com o VSCode, você pode ter vários shells abertos no mesmo editor ao mesmo tempo, o que tem suas vantagens.
YouTube
Ainda assim, nenhuma das opções acima evita a necessidade do namespace da GUI ou de outras referências em seus scripts. Você sempre deve usá-los em qualquer editor de código que esteja usando por padrão quando estiver usando coisas de UX/UI.
Por fim, para scripts de longa duração, você deve realmente analisar o uso de trabalhos em segundo plano do PowerShell.