Script Browser per Windows PowerShell ISE è un'applicazione sviluppata da Microsoft Customer Services & Support (CSS), con l'assistenza del team di PowerShell e il garage per salvare professionisti IT dal doloroso processo di ricerca e il riutilizzo script. Partiamo dai 9.000 esempi di script + su TechNet Script Center. Script Browser permette agli utenti di cercare direttamente, imparare, e scarica gli script TechNet dall'interno di PowerShell ISE - il vostro ambiente di scripting.A partire da questo mese, Scrittura Browser per PowerShell ISE sarà disponibile per il download. Se sei un scripter PowerShell o in procinto di esserlo, Script Browser è un add-in altamente raccomandato per voi.
Quasi 10.000 script su TechNet sono disponibili a portata di mano. È possibile cercare, scaricare e imparare script da questo repository campione in continua crescita.
Abbiamo abilitato la ricerca offline per i campioni di script scaricabile in modo da poter cercare e campioni di vista di script, anche quando non si ha accesso a Internet.
Avrete la possibilità di provare un'altra nuova funzionalità in bundle con Script Browser - ' Script Analyzer '. Ingegnere Microsoft CSS è riuscito a usare l'albero di sintassi PowerShell astratta (AST) per controllare il vostro script corrente contro alcune regole pre-definite. In questa prima versione, ha costruito 7 pilota PowerShell best practice regole di controllo.Facendo doppio clic su un risultato, verrà evidenziato il codice di script che non rispettano la regola best practice.Speriamo di ottenere il vostro feedback su questa funzione sperimentale.
E 'molto essenziale che un app soddisfi le esigenze degli utenti. Pertanto, il feedback è di primaria importanza. Per Script Browser, MVP Microsoft sono una delle fonti principali dove otteniamo un feedback costruttivo. Quando il Browser script è stato demoed al MVP Summit 2013 Global in novembre e nel 2014 il Giappone MVP Open Day, la comunità MVP proposto miglioramenti penetranti. Ad esempio, MVP ha suggerito che mostra un'anteprima di script prima che gli utenti possono decidere di scaricare il pacchetto di script completo. MVP voleva anche essere in grado di cercare esempi di script offline. Questi erano ottimi consigli, e la squadra subito aggiunte le caratteristiche per il rilascio. Abbiamo raccolto un pool di grandi idee (ad esempio, MVP ha anche suggerito che le migliori regole pratiche di controllo in funzione Script Analyzer devono essere estensibile). Siamo impegnati a migliorare costantemente l'applicazione in base al vostro feedback.
Abbiamo una tabella di marcia ambiziosa per Script Browser. Ad esempio, abbiamo in programma di aggiungere altri repository di script per l'ambito di ricerca. Stiamo studiando l'integrazione con Bing Ricerca Codice. Stiamo anche cercando di migliorare l'estensibilità delle norme Script Analyzer. Alcune caratteristiche, come la condivisione di script di esempio e la ricerca all'interno di un'azienda, sono ancora nella loro infanzia.
Il Browser Script è stato rilasciato a metà aprile e
ha ricevuto migliaia di download da quando è stato rilasciato una settimana fa. Sulla base delle vostre risposte, oggi abbiamo comunicato l'aggiornamento 1.1 per rispondere alle caratteristiche altamente necessarie. La squadra si è impegnata a rendere il Browser Script e Script Analyzer utile. Il tuo feedback è molto importante per noi.
Scarica Script Browser & Script Analyzer 1.1
(se avete già installato la versione 1.0, si otterrà una notifica di aggiornamento quando si avvia Windows PowerShell ISE.)
(se avete già installato la versione 1.0, si otterrà una notifica di aggiornamento quando si avvia Windows PowerShell ISE.)
1. Opzioni per Attiva / Disattiva Regole Analyzer Script
È possibile scegliere di attivare o disattivare le regole nella finestra Impostazioni di Script Analyzer.
È inoltre possibile suggerire una nuova regola Script Analyzer o votare per i suggerimenti altrui. Il nostro teammonitora forum attentamente. Sulla base delle vostre proposte e voti, vi forniremo le corrispondenti regole Script Analyzer negli aggiornamenti futuri. Stiamo anche esaminando la possibilità per voi di scrivere le proprie regole Script Analyzer e collega nello Script Analyzer.
2. Raffinati Regole Analyzer script con descrizione dettagliata
Grazie al vostro feedback, abbiamo affinato le regole Script Analyzer che sono stati rilasciati nella versione 1.0. Abbiamo anche risolto tutti i problemi di regole che Lei segnalati. Ogni regola viene fornito con una descrizione dettagliata, buoni / cattivi esempi e documenti giustificativi. Ecco le 5 regole raffinate liberati in questo aggiornamento. Non vediamo l'ora di imparare il tuo feedback.
Uso Invoke-Expression deve essere attentamente considerata
Invoke-Expression è un comando potente; è utile in determinate circostanze, ma può aprire la porta di codice dannoso viene iniettato. Questo comando deve essere usato con giudizio.
http://blogs.msdn.com/b/powershell/archive/2006/11/23/protecting-against-malicious-code-injection.aspx
Cmdlet utilizzo alias dovrebbe essere evitato
PowerShell è un linguaggio di scripting meravigliosamente efficiente, che consente a un amministratore di realizzare un sacco di lavoro con poco ingresso o sforzo. Tuttavia, si consiglia di utilizzare nomi completi cmdlet invece di alias 'durante la scrittura di script che potenzialmente bisogno di essere mantenuto nel tempo, sia per l'autore originale o in un altro scripter Powershell. Alias using 'potrebbe causare problemi legati ai seguenti aspetti:
Leggibilità, comprensibilità e disponibilità. Prendere il comando Powershell seguente per un esempio:
Ls |? {$ _.psiscontainer} |% {"{0}` t {1} "-f $ _.name, $ _.lastaccesstime}
La sintassi di cui sopra non è molto chiaro al novizio PowerShell scripter, il che rende difficile leggere e capire.
Lo stesso comando con i nomi di cmdlet è più facile da leggere e capire.
Get-ChildItem | Where-Object {$ _.psiscontainer} | ForEach-Object {"{0}` t {1} "-f $ _.name, $ _.lastaccesstime
Infine, possiamo garantire che un alias esisterà in tutti gli ambienti.
Per ulteriori informazioni, consultare il blog collegato Scripting Guy su questo argomento.
http://blogs.technet.com/b/heyscriptingguy/archive/2012/04/21/when-you-should-use-powershell-aliases.aspx
Blocchi catch vuoti devono essere evitati
Blocchi catch vuote sono considerate decisioni di progettazione poveri, perché se si verifica un errore nel blocco try, l'errore viene inghiottito semplicemente e non ha agito su. Anche se questo non è di per sé portare a risultati indesiderati, le possibilità sono ancora là fuori. Pertanto, blocchi catch vuoti dovrebbero essere evitati, se possibile.
Prendere il seguente codice per un esempio:
Prova a
{
$ SomeStuff = Get-SomeNonExistentStuff
}
catture
{
}
Se eseguiamo il codice in PowerShell, nessun messaggio di errore visibili saranno presentati metterci in guardia sul fatto che la chiamata a Get-SomeNonExistentStuff fallisce.
Una possibile soluzione:
Prova a
{
$ SomeStuff = Get-SomeNonExistentStuff
}
catture
{
"Something Happened chiamare Get-SomeNonExistentStuff"
}
Per ulteriori approfondimenti:
http://blogs.technet.com/b/heyscriptingguy/archive/2010/03/11/hey-scripting-guy-march-11-2010.aspx
Argomenti posizionali devono essere evitati
Leggibilità e la chiarezza dovrebbe essere l'obiettivo di ogni script ci aspettiamo di mantenere nel tempo.Quando si chiama un comando che accetta parametri, ove possibile considerare l'utilizzo di parametri denominati in contrasto con i parametri posizionali.
Prendere il comando seguente, chiamando un cmdlet Azure PowerShell con 3 parametri posizionali, per un esempio:
Set-AzureAclConfig "10.0.0.0 / 8" 100 "MySiteConfig"-addrule-ACL $ AclObject-Action permesso
Se il lettore di questo comando non ha familiarità con il cmdlet set-AzureAclConfig, loro non possono sapere quali sono i primi tre parametri sono.
Lo stesso comando chiamata utilizzando i parametri Named è più facile da capire:
Set-AzureAclConfig-RemoteSubnet "10.0.0.0 / 8"-Order 100-Descrizione "MySiteConfig"-addrule-ACL $ AclObject-Action permesso
Letture addizionali:
http://blogs.technet.com/b/heyscriptingguy/archive/2012/04/22/the-problem-with-powershell-positional-parameters.aspx
I nomi delle funzioni avanzate dovrebbero seguire convenzione di denominazione verbo-nome standard di
Come introdotto in PowerShell 2.0, la possibilità di creare funzioni che imitano i comportamenti cmdlet è ora disponibile per scripters. Ora che abbiamo come scripters la capacità di scrivere funzioni che si comportano come cmdlet, dobbiamo seguire la costanza di PowerShell e denominare le nostre funzioni avanzate utilizzando la nomenclatura verbo-nome.
Eseguire il cmdlet qui sotto per ottenere la lista completa dei PowerShell approvato verbi.
Get-Verb
http://technet.microsoft.com/en-us/magazine/hh360993.aspx
3. Correzioni di Interesse
- Risolto un problema locale "stringa di input non era in un formato corretto .." quando Script Browser lancia sul localizzazioni che trattano doppia / float come '# # , # # # # '. Siamo molto grati a MVP Niklas Akerlund per fornire una soluzione prima di rilasciare il fix.
- Corretti i problemi (tra cui l'errore 1001, e questo bug report ) quando alcuni utenti installare il browser Script.
- Corretti i problemi nelle regole Script Analyzer
Noi sinceramente consigliamo di dare Script Browser provarlo ( clicca qui per scaricarlo ). Se ti piace quello che vedete in Script browser, consiglio ai tuoi amici e colleghi. Se avete problemi o avere qualche suggerimento per noi, contattaci all'indirizzo onescript@microsoft.com . Le vostre opinioni e commenti preziosi sono più che benvenuti.
John Marlin
senior Support Escalation tecnico
del supporto Microsoft Global Business
senior Support Escalation tecnico
del supporto Microsoft Global Business
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.