<p>Paket PowerShell 6.0</p>

Saya dapat menulis modul biner yang menargetkan Windows PowerShell dan PowerShell Core

Ini sudah berfungsi - menargetkan .NET Standard 1.6. Bagian yang sulit adalah memuat rakitan khusus OS - apakah kita memerlukan /lib/{OS}/*.dll pemuatan otomatis RequiredAssemblies ?

Klien WinRM dengan Kerberos dan otentikasi sertifikat klien, dari Linux dan Mac OS X adalah sesuatu yang saya anggap penting. Kami mencari kemampuan untuk menerapkan kode PowerShell jarak jauh ke sistem Windows dari sistem non-Windows, melalui kontainer Docker.

Apakah NTLM akan mencakup skenario ini dengan cara yang aman? Saya tidak jelas tentang pro / kontra NTLM vs Kerberos, tetapi bagaimanapun juga, saya pikir otentikasi sertifikat klien akan menjadi topik terpisah.

LMK

Bersulang,
Trevor Sullivan

Saya sangat setuju dengan apa yang dikatakan @ pcgeek86 , menargetkan WinRM dari Linux adalah skenario yang sama sekali tidak ramah dan NTLM tidak mungkin dilakukan dengan banyak pelanggan.
Ada modul komunitas YAML tetapi mungkinkah untuk mengintegrasikan cmdlet YAML dengan cara yang sama seperti ConvertTo / ConvertFrom- * sudah ada untuk CSV / XML / JSON?

@ pcgeek86 @fabiendibot enak didengar. Saya kemudian mengajukan pertanyaan: apakah Anda baik-baik saja bergabung dengan kotak Linux (atau Mac) Anda? Atau apakah Anda berharap untuk menangani sertifikat secara manual?

Lebih baik lagi, apa pemblokir untuk Anda menggunakan PSRP melalui SSH dari Mac / Linux ke Windows? Apakah Anda memiliki semacam solusi sertifikat yang lebih sederhana daripada pasangan kunci publik / pribadi?

Kami sudah memiliki sistem penerbitan sertifikat terpisah, jadi itu sudah diurus.

Saya harus melihat bagaimana PowerShell Remoting over SSH bekerja sebelum saya dapat berkomentar lebih lanjut tentang skenario itu. Sampai saat ini, saya tidak mengetahui adanya implementasi fungsional darinya. Solusinya perlu bekerja pada sistem operasi Windows tingkat bawah.

Saya juga akan menambahkan beberapa penekanan di sekitar membangun modul biner di sekitar .NET Standard. Saya senang melihat ini ditambahkan di sana. Mungkin kita harus menambahkan sesuatu untuk memuat rakitan .NET ke PowerShell, dan memanggilnya? Saya tahu banyak yang telah berubah di .NET Core, sehubungan dengan AppDomains, refleksi, dan sebagainya ... Saya pikir area ini perlu perhatian.

saya setuju dengan @Jaykul dan @ pcgeek86
semacam PowerShell gac atau folder perpustakaan akan bagus ...
ini akan membantu kami mengelola rakitan yang modul terkait kami gunakan / pasang ...
saya pikir node / python juga memiliki konsep ini ...

@joeyaiello Kami mengkonfigurasi kerberos dengan kotak Linux kami untuk beberapa skenario (kebanyakan koneksi SQL Server). Bagi saya Win32-SSH belum siap produksi jadi saya belum melihatnya untuk saat ini.

Apakah .NET Framework 4.6.1 berfungsi di Windows 7?

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

1/10 / 2010Sistem Operasi:
• Windows 7 SP1 (x86 dan x64)
• Windows 8 (x86 dan x64)
• Windows 8.1 (x86 dan x64)
•Windows 10
• Windows Server 2008 R2 SP1 (x64)
• Windows Server 2012 (x64)
• Windows Server 2012 R2 (x64)

Bagaimana dengan Fitur Kelas?
Implementasi antarmuka masih hilang.

Berikut roadmap akhir 2014:

PowerShell harus PADAT di 6.0 ( https://en.wikipedia.org/wiki/shared_ (object-oriented_design))

Bidang bahasa perlu lebih diperhatikan, terutama masalah ini:
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

Terima kasih !

Mungkin akan berguna untuk menyusun peta jalan ini dengan menggunakan Proyek GitHub.

Memiliki antarmuka akan sangat keren!

@iSazonov kami mempertimbangkan untuk menggunakan Proyek GitHub, tetapi memutuskan (untuk saat ini) akan lebih mudah melacak kemajuan sebagai kotak centang dalam suatu masalah

Saat ini, pemikiran kami adalah berinvestasi dalam pengalaman pengembang (peningkatan kelas serta hal-hal seperti binding ke bahasa lain, pembuatan cmdlet dalam bahasa lain, dll ...) posting 6.0 daripada terus menambahkan fitur ke 6.0.

Nah, saat ini pengalaman pengembang tidak begitu bagus! ISE adalah lelucon tanpa ISESteroids, dan VS CODE adalah buggy yang hebat. Ini membuat kita hanya memiliki PowerShell Studio sebagai satu-satunya pilihan, tetapi intellisense hampir tidak ada.
Jadi, mungkin hal yang benar untuk dilakukan adalah berinvestasi dalam mengembangkan IDE yang bagus, dengan dukungan fitur PS 5-6.

@ g8tguy rencana kami adalah berinvestasi dalam VS Code secara khusus melalui PowerShellEditorServices karena ini open source dan lintas platform. Jika ada masalah atau kemampuan khusus yang mencegah Anda menggunakan VS Code, buka masalah di repo itu.

@ g8tguy jika VS Code adalah "buggy as hell", masalah file jadi saya bisa memperbaikinya :)

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

Terakhir kali saya mencoba VS Code , seperti setengah tahun yang lalu.
Dan language server terus-menerus jatuh saat Anda
buka 5-10 tab dengan kustom PS 5 kelas dan enum yang mereferensikan satu sama lain, jadi IntelliSense berhenti bekerja, dan IDE bertingkah aneh. Saya ingin mem-porting, PowerShellEditorServices Ke IDEA , tetapi tampaknya terlalu banyak pekerjaan untuk satu orang, jadi saya terjebak dengan PS Studio . Tapi karena saya melihat PowerShellEditorServices changelog sekarang, tentu tampaknya banyak tentang bug diselesaikan, dan VS Cod e menjadi lebih matang dan stabil, jadi saya akan memberikan suntikan lain. Dan Terima kasih teman-teman untuk produknya, Anda melakukan pekerjaan dengan baik, mendukung PowerShell! 👍: 1st_place_medal:

@ g8tguy ya, banyak yang berubah sejak itu. Jika Anda masih mengalami masalah dalam mengembangkan skrip dengan kelas di VS Code, saya akan dengan senang hati mencoba dan memperbaikinya. Membuat Layanan Editor berfungsi di IDEA pasti dapat dicapai, jika Anda pernah mencoba lagi, saya akan dengan senang hati memberi Anda beberapa petunjuk.

Saya dapat mengonfirmasi - versi Kode PS terbaru bagus! Itu terjadi dalam beberapa bulan terakhir. Terima kasih banyak kepada pengembang Kode PS!

Bagaimana dengan dukungan untuk jalur / nama file yang panjang? Karena .NET Core sekarang mendukung mereka, saya tahu ada harapan ini datang ke PowerShell pada akhirnya - https://github.com/dotnet/corefx/issues/645. Saya yakin akan ada banyak kegembiraan di dunia usaha jika / saat ini terjadi.

@itpaul PowerShell Core sudah mendukung jalur panjang secara default :)

@ SteveL-MS Manis! Terima kasih telah berbagi. Adakah ide tentang kapan ini bisa masuk ke non-Core PS?

@itpaul PowerShell v5.1 di Win10 sudah mendukungnya, tetapi bukan default (karena OS tidak mendukungnya secara default, jika Win10 mengubah pengaturan itu, itu hanya akan bekerja secara otomatis). Anda dapat mengaktifkannya dengan mengikuti ini: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

@ SteveL-MSFT Fantastis! Sekali lagi terima kasih atas bantuan Anda. Saya akan mulai memeriksanya. Setelah balasan pertama Anda, saya menemukan bahwa Anda dapat menjalankan PowerShell Core secara portabel, yang juga luar biasa! Tampaknya saya dapat menghindari penerapan Alpha FS ke dalam lingkungan kita sekarang.

@itpaul salah satu keputusan yang kami ingin gunakan dengan CoreCLR selain dukungan lintas platform adalah bahwa ia secara inheren mendukung berdampingan, sehingga Anda dapat "menginstal" (yang sebenarnya merupakan salinan) dari PSCore6.0 dan itu akan berjalan dengan senang hati di samping Windows PowerShell v5.x tanpa memengaruhi skrip / aplikasi yang ada yang bergantung pada v5.x

@ SteveL-MSFT Babi benar-benar dapat terbang di dunia Microsoft Nadella. Natal pasti datang lebih awal tahun ini.

1. Sepertinya kami memiliki masalah dengan conhost yang dirujuk dalam beberapa masalah. Ini bukan hanya bilah kemajuan.
2. Untuk bilah kemajuan, kinerja # 2822 dibuka.
3. Akan lebih baik untuk memiliki analisis kode untuk kinerja (keamanan, kualitas, pemformatan).
4. Kami bisa mendapatkan umpan balik yang bagus dari Pratinjau Windows 10 jika terintegrasi dalam program ini. (Di WSL juga)
5. Rencana tersebut tidak menyebutkan WSL (Windows Subsystem for Linux). Ini bisa menjadi platform yang bagus untuk pengujian dan promosi Powershell Core. Sekarang kami memiliki masalah dengan WSL.

Kerja bagus! Apakah Anda berencana untuk mendukung Docker juga (kami berencana untuk mengirimkan modul PowerShell Core)? Bisakah Anda juga mengunggah catatan atau rekaman RFC ke-2 seperti yang Anda lakukan untuk yang pertama?

@HemantMahawar apa rekaman sudah siap diupload dari Community Call terakhir?

@iSazonov : Bisakah Anda menghubungkan saya ke beberapa masalah conhost itu? Dua yang saya miliki di atas, # 2138 dan # 1625 tampak seperti masalah kemajuan bagi saya. (Dalam pikiran saya, bahkan jika itu disebabkan oleh host konsol yang mendasari, kami memiliki sedikit kendali atas host yang mendasarinya di seluruh platform sehingga fungsionalitas kemajuan adalah apa yang perlu difaktor ulang atau bahkan dibatasi). Juga, menambahkan # 2822. 👍

Saya setuju dengan Anda tentang analisis kode. Mungkin @JamesWTruher atau @ SteveL-MSFT dapat membuat Masalah untuk saya tambahkan di sini?

Saya mendengar Anda tentang dukungan WSL, tetapi saya pikir kami memprioritaskan distro Linux dan macOS sekarang karena kurangnya skenario yang menarik untuk menggunakan PowerShell dari WSL. Selain itu, saya pikir mereka pada akhirnya (ini hanya dari pengetahuan publik tanpa pengetahuan internal tentang garis waktu atau bagaimana fungsionalitas dapat bekerja) berencana untuk beroperasi dengan proses Windows, dalam hal ini Anda tidak perlu menjalankan "PowerShell di Linux" dari dalam WSL tetapi hanya "PowerShell Core 6.0 di Windows".

Jika Anda tidak setuju dengan pernyataan saya tentang "skenario yang menarik", beri tahu saya. Saya senang terbukti salah dalam hal-hal semacam ini :)

@ ChristophB125 : dapatkah Anda menjelaskan lebih lanjut tentang apa yang Anda maksud dengan "mendukung Docker"? Saat ini kami memiliki Docker yang terdaftar sebagai platform, dan kami menerbitkan banyak gambar ke Docker Hub (termasuk nightlies , meskipun sepertinya kami lupa menerbitkan alpha.15, saya menindaklanjutinya).

Jika maksud Anda, apakah kami memiliki modul PowerShell untuk mengelola Docker, tim Hyper-V telah melakukannya . Ini sudah mendukung Windows PowerShell 5.x serta PowerShell Core 6.0 pada Windows, Nano, macOS, dan Linux.

Karena penasaran, siapakah "kita" itu? Ingin sekali berbicara lebih banyak tentang cara Anda menggunakan PowerShell 6.0 :)

Juga, saya mendapat kabar buruk. Sepertinya kotak centang TIDAK secara otomatis dicentang ketika masalah ditutup (setidaknya tidak di tingkat L3). Saya menutup # 2245 dan tidak diperiksa dengan sendirinya (dan di situlah seluruh baris hanya nomor masalah ....) 👎

@joeyaello mengirimkan permintaan fitur ke GHub 😸

@ ChristophB125 Rekaman panggilan komunitas ke-2 sekarang tersedia di Saluran Tim PowerShell & DSC / cc: @ SteveL-MSFT & @joeyaiello

@joeya

Bisakah Anda menghubungkan saya ke beberapa masalah conhost itu?

Oh, itu sulit dilakukan tetapi tampaknya saya telah mengumpulkan utama bersama (saya yakin ada komentar bermanfaat lainnya yang kami lewatkan.)

Jika Anda tidak setuju dengan pernyataan saya tentang "skenario yang menarik", beri tahu saya. Saya senang terbukti salah dalam hal-hal semacam ini :)

Saya setuju tapi masih ada "skenario yang menarik".
Microsoft mengumumkan WSL sebagai fitur pengembang "kill":

WSL dirancang dan dibangun oleh Tim Kernel Windows dan disampaikan dalam kemitraan dengan Canonical, untuk membantu pengembang Windows 10 menggunakan ekosistem dan alat pengembang Linux yang kaya bersama alat hebat yang sudah mereka gunakan di Windows, tanpa harus boot ke sistem operasi lain atau VM. Ini jelas merupakan fitur Windows 10 "oleh pengembang, untuk pengembang", yang dirancang khusus untuk menghilangkan sedikit gesekan dari alur kerja harian pengembang.

Sebagai pengguna Windows, saya mencoba menggunakan Powershell Core di bawah WSL dan gagal 😕
Saya ingin:

1. Kembangkan dan uji skrip PowerShell
2. Kembangkan dan uji modul PowerShell biner
3. Bangun Powershell Core dari sumber
4. Kembangkan dan debug fitur Powershell Core

Saya yakin bahwa ini sepenuhnya sejalan dengan pengumuman Microsoft WSL.
Sangat menyenangkan meminta tim Kernel untuk membantu kami membuatnya berfungsi.

@joeyaiello Terima kasih atas jawabannya. Ya, gambar buruh pelabuhan PowerShell adalah apa yang saya cari. Ini akan sangat bagus karena kemudian PowerShell dapat dikirimkan sebagai bagian dari penerapan (kami takut klien kami khawatir tentang IP Microsoft yang ada di mesin Linux mereka oleh karena itu pekerja galangan dapat membantu kami menyembunyikannya setidaknya pada waktu pemasangan). Ngomong-ngomong, 'kami' hanya mengacu secara longgar pada tim di perusahaan tempat saya bekerja, yang tidak dapat saya ungkapkan di sini. Meskipun kami adalah mitra Microsoft Gold, informasi dari tim pengembang secara langsung sangat berharga bagi kami. Karena GitHub tidak lagi mengizinkan perpesanan pribadi, saya mengirimi Anda permintaan LinkedIn jika Anda ingin mengetahui lebih banyak tentang bagaimana kami menggunakan PowerShell.

@Hemantahawar Terima kasih atas usahanya. Saya menantikan untuk bergabung dengan panggilan berikutnya!

@iSazonov - masalah WSL yang paling mempengaruhi Anda mungkin https://github.com/dotnet/corefx/issues/12452 - jadi tidak memerlukan perbaikan di Windows - siapa pun dapat melompat untuk memperbaikinya (meskipun kedengarannya seperti itu mungkin bukan perbaikan sederhana atau sudah diperbaiki.)

Dan setelah membaca pembaruan untuk masalah ini, mungkin perbaikan datang dari WSL. Kita lihat saja nanti.

@lzybkr Terima kasih! Build 15025 masih memiliki bug. Menunggu build berikutnya.

@joeyaiello # 2882 pindah ke dotnet-resgen (support compile "file.En-Us.resx") dan csproj.

@iSazonov : Anda mengatakan itu adalah dua item yang terpisah, bukan? Yang pertama adalah persyaratan untuk pelokalan (sesuatu yang perlu kita diskusikan dengan @ PowerShell / powershell-committee, saya tidak yakin bagaimana kita menyelesaikannya hari ini), dan yang terakhir adalah persyaratan untuk pindah ke .NET Core 2.0 (persyaratan untuk mendukung .NET Standard 2.0).

@joeyaiello kami memiliki solusi khusus untuk res-gen hari ini, tetapi kami harus pindah ke cara yang didukung dotnet. csproj pindah ke msbuild, meskipun kita telah membicarakannya, saya tidak melihat ada masalah untuk itu.

@joeyaiello Steve mengatakan lebih jelas dari saya. Kami sudah memiliki masalah untuk resgen dotnet dan kami harus membuka masalah untuk csproj. Dan kita harus memasukkan masalah dalam Rencana di bawah "dotnet 2.0"

Menambahkan kebaikan csproj / MSBuild, kita masih harus berbicara tentang resgen dan apakah itu diperlukan untuk 6.0.

Ini mungkin lebih Hyper-V daripada PowerShell (atau bagian yang sama Hyper-V dan PowerShell), tetapi saya pikir saya akan menyebutkannya untuk memastikan: Saya pikir sangat penting untuk memiliki PowerShell Direct yang berfungsi untuk VM Linux serta VM Windows .

@ SteveL-MSFT Terima kasih telah memfokuskan pada pengalaman pengembang sebagai prioritas di atas penambahan fitur baru. Saya sangat setuju dengan arahan Anda. Mulailah dengan membuat fondasi yang kokoh, dan tambahkan fitur pasca-6.0. / cc @joeyaiello

AppImage # 2024 di Packaging, Installation, and Deployment

@joeyaiello # 2138 dan # 1625 diperbaiki - Saya memberi tanda di Rencana.

Saya pikir autentikasi NTLM melalui SSH harus disertakan dalam rilis yang sama seperti untuk WinRM

@joeyaiello # 3140 diperbaiki - Saya memberi tanda di Plan.

@mnaiman Saya ... sebenarnya tidak yakin apakah permintaan itu masuk akal dari sudut pandang crypto. Saya menantang Anda untuk mencoba apa yang Anda coba lakukan dan melaporkan kembali jika tidak berhasil. Kami mendukung autentikasi sandi untuk akun domain dan non-domain di jarak jauh berbasis SSH (dengan dan tanpa PSRP). Saya tidak yakin bahwa itu melewati semua jenis lapisan NTLM (karena saya tidak yakin SSH mendukung NTLM), tetapi menurut saya itu tidak masalah dari perspektif fungsional.

EDIT: Mungkin @manojampalam bisa berkomentar di sini.

@mnaiman @joeyaiello saat ini, kami tidak mendukung SSO karena SSH itu sendiri secara default lebih memilih

@joeyaiello @ SteveL-MSFT Penyedia SSH SSH adalah "gssapi-with-mic" (NTLM & Kerberos).

Ini memungkinkan masuk tunggal di windows tanpa mengetik kata sandi atau menyimpan kunci pribadi di suatu tempat.
Beberapa bagian dari gssapi sudah ada di sini https://github.com/SimonWilkinson/gss-openssh/
Berikut implementasi untuk klien https://github.com/Lax/net-ssh-kerberos
Server Gratis / Komersial yang mendukung gssapi PowershellServer & Bitwise SSH.

Ini sudah permintaan di https://github.com/PowerShell/Win32-OpenSSH/issues/96

Saya menjalankan PowerShell di mesin 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

Tetapi perintah send-mailmessage tidak berfungsi untuk saya. Saya mendapatkan pesan di bawah ini.

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

Saya mengalami masalah dengan PS 5.0 saat menjalankan invoke-webrequest ... pada dasarnya jika respons datang dengan tanda kutip dalam nilai utf-8 maka akan gagal. Apakah ini akan diperbaiki dalam versi GA (https://stackoverflow.com/questions/36275618/why-is-invoke-webrequest-and-invoke-restmethod-failing-and-succeeding-at-the-sam)

@pradeepprakhar Sekarang 'send-mailmessage' porting.

@jsburckhardt Silahkan buka Issue baru dengan deskripsi lengkap masalah atau pertanyaan Anda.

@joeyaiello # 929 dan # 2227 telah diperbaiki.

Melakukan beberapa pembaruan pada daftar di atas tentang apa yang ditutup / selesai dan apa yang dipotong dari 6.0.0 dan kemungkinan akan mendarat di 6.1.0 sebagai gantinya

Apakah ada rencana untuk menambahkan dukungan komentar (atau setidaknya mengabaikannya) dalam daftar untuk ConvertFrom-Json ?

@erichiller tolong buka terbitan baru, kami dapat mempertimbangkan untuk 6.1.0

Harap sertakan dukungan Kerberos (dan mungkin juga WinRM), lalu kita lihat ini lagi.

@VGerris jika yang Anda maksud WinRM adalah WSMan, dukungan itu sudah disertakan. Ada dukungan Kerberos eksperimental untuk WSMan di non-Windows, meskipun saat ini terlalu rumit untuk membuatnya berfungsi.

Tidak, maksud saya Kerberos dan WinRM seperti yang saya tulis. Harap fokus untuk mendapatkan dukungan itu, jadi orang tidak harus bergantung pada skrip pihak ketiga. Apa yang pada dasarnya kami inginkan adalah cara untuk memonitor mesin Windows secara efisien melalui solusi tanpa agen dan untuk dapat menjalankan perintah jarak jauh dengan cara yang aman. Jelas dari utas ini adalah fitur utama di peringkat minat, bukan? Terima kasih.

@VGerris Saya tidak mengerti apa yang Anda maksud dengan WinRM maka karena itu didukung pada Windows (dan sudah bekerja dengan PSCore6) dan WinRM adalah fitur khusus Windows (Windows Remote Management). WSMan adalah protokol yang diimplementasikan oleh WinRM.

Diagram arsitektur berikut dari sini mungkin membantu untuk memahami WinRm-WSMan:

Saya mengerti sedikit lebih baik mengapa diagram ini digambar seperti saat saya melihat blognya , tapi ini sedikit menyesatkan. Cara dasar untuk memikirkannya adalah bahwa WSMan adalah protokol / standar (kependekan dari WS-Management) dan WinRM adalah implementasi dari protokol itu sebagai layanan di Windows.

@VGerris seperti yang secara teknis

Namun, jarak jauh berbasis WSMan bukannya tanpa agen. Anda masih harus menjalankan layanan WinRM di mesin Windows Anda: itu adalah agen. Pada rilis Windows 10 dan Windows Server berikutnya, OpenSSH sendiri akan tersedia sebagai fitur yang didukung sesuai permintaan, jadi Anda akan memiliki dukungan kotak masuk pihak pertama untuk jarak jauh berbasis SSH sebagai peer to remote berbasis WSMan.

Saya juga menutup masalah ini karena kegunaannya sudah habis. Kami harus terus melacak pekerjaan ini di masalah yang telah dibuat. Jika Anda tertarik dengan sesuatu di sini yang tidak memiliki masalah, buka satu sehingga kami dapat melacaknya di sana.

Saya juga berencana memperbaiki Proyek di beberapa titik, saya tahu itu dalam keadaan rusak sekarang. Maaf tentang itu, teman-teman ....