2011-03-24 6 views

risposta

11

In realtà è una storia interessante in effetti collaterali.

Visual Studio ha un elenco fisso di assiemi nella finestra di dialogo "Aggiungi riferimento".
Tutto il resto deve essere sfogliato. Gli sviluppatori tendono a cercare questo percorso nella directory di Windows, dove System.Management.Automation.dll (l'assembly che esegue la maggior parte delle vite di PowerShell) Ciò ha reso un riferimento assoluto a questa posizione. Poiché non c'era un'opzione di installazione side-by-side con PowerShell (come con il framework .NET), la scelta migliore era quella di consentire alle persone di continuare a fare riferimento allo stesso assembly, sia per percorso che per StrongName, come facevano prima.

Se questa storia non fosse stata mantenuta in questo modo, tutte le applicazioni scritte su PowerShell V1 avrebbero dovuto essere ri-rilasciate per V2.

+1

Non è questo il GAC? – Simon

+1

Oh BTW includendo la tua firma su ogni risposta è uno spreco di spazio :) – Simon

4

Penso che poiché PowerShell 2.0 è estremamente compatibile con 1.0, non era necessario disporre di due versioni diverse sulla stessa macchina. Quindi hanno inserito 2.0 sopra 1.0 nei sistemi XP e Vista e molto probabilmente hanno deciso di mantenere la stessa directory per Windows 7. Questa è anche la stessa ragione per cui l'estensione è ancora .ps1 (e .psm1, .psd1).

Si potrebbe chiedere lo stesso per Windows 7 x64. Perché le DLL di sistema a 64 bit in una directory chiamata System32 e perché gli stessi nomi di dll a 64 bit terminano con "32", ad es. user32.dll, kernel32.dll, ecc. :-)

+0

Niente a che vedere con "compatibilità estrema", ma con compatibilità a ritroso. – manojlds

7

Penso solo che, all'inizio, il team di Microsoft prevede di distribuire le versioni di PowerShell fianco a fianco, proprio come è stato fatto per le versioni di .NET Framework. Ma con il tempo hanno deciso di supportare solo un PowerShell al momento.

C'è qualcosa di ancora più strano quando si utilizza il parametro -version della riga di comando per scegliere la versione 1.0 la var $PSVersionTable è presente con PSVersion valutato a 2.0. $ PSVersionTable non è presente in PowerShell 1,0

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>powershell -version 1.0 
Windows PowerShell 
Copyright (C) 2009 Microsoft Corporation. Tous droits réservés. 

PS C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC> cd \ 
PS C:\> $PSVersionTable 

Name       Value 
----       ----- 
CLRVersion      2.0.50727.4952 
BuildVersion     6.1.7600.16385 
PSVersion      2.0 
WSManStackVersion    2.0 
PSCompatibleVersions   {1.0, 2.0} 
SerializationVersion   1.1.0.1 
PSRemotingProtocolVersion  2.1 

Se si dispone di uno sguardo su var $host che esiste su entrambe le versioni

PowerShell V2.0 (Vith versione 1.0 o 2.0)

PS > $host 
Name    : ConsoleHost 
Version   : 2.0 
InstanceId  : b6ae2582-c1f4-422a-b057-16458b387f7d 
UI    : System.Management.Automation.Internal.Host.InternalHostUserInterface 
CurrentCulture : fr-FR 
CurrentUICulture : fr-FR 
PrivateData  : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy 
IsRunspacePushed : False 
Runspace   : System.Management.Automation.Runspaces.LocalRunspace 

PowerShell V1.0

PS > $Host 
Name    : ConsoleHost 
Version   : 1.0.0.0 
InstanceId  : b55940f2-b3b2-4f99-b895-98aac4752369 
UI    : System.Management.Automation.Internal.Host.InternalHostUserInterface 
CurrentCulture : fr-FR 
CurrentUICulture : fr-FR 
PrivateData  : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy 

La mia opinione è che PowerShell V2.0 è in grado di eseguire quasi tutti gli script di PowerShell V1.0. Microsoft aggiunge alcuni vars e si possono avere problemi se si dispone di queste vars negli script, ma si tratta di arachidi.

JP

+0

In Windows 8, è ancora in C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe e $ PSVersionTable mostra un PSVersion di 3.0. – benjguin