Est-ce que le mode PowerShell STA éliminer problème de fuite de mémoire SharePoint?

Question

Un peu d'histoire:

• SharePoint + PowerShell est (généralement) un parfait Associez par Zach Rosenfield [MSFT]
• SharePoint + PowerShell fuite par moi Contournements
• SO: Pouvez-vous expliquer STA et MTA
?

En bref, l'orientation standard SharePoint est que les objets COM comme soutenu SPSite et SPWeb ne doivent pas être utilisés par différents threads. Ceci est en conflit avec l'utilisation de PowerShell du mode MTA par défaut, vérifié dans le poste de fuite mentionné ci-dessus Contournements. Une solution proposée était d'essayer le drapeau de -STA PowerShell 2.0, qui semble comme il devrait résoudre le problème; Cependant, dans les commentaires sur son poste Zach suggère le mode STA ne suffit pas.

Cela pousse au bord de ma connaissance COM, donc je suis en espérant que quelqu'un peut me aider à comprendre ...

1. Mode STA devrait être suffisant pour maintenir l'accès aux objets limité à un seul fil excaver PowerShell?
2. Si non, pourquoi?

Answer 1

En fin de compte, le mode -STA devrait être suffisant à condition que vous utilisez Powershell 2.0. La raison est que en mode STA, le défaut runspace réutilise un seul thread pour toutes les commandes interactives (et scripts aussi). Il est possible que la version de Zach que Powershell regardait en février que le comportement différent RC / RTM en cours de PowerShell 2.0. Il a peut-être utilisé UseNewThread au lieu de la valeur par défaut actuelle, ReuseThread:

PS> [System.Management.Automation.Runspaces.Runspace]::DefaultRunspace

Events                : System.Management.Automation.PSLocalEventManager
ThreadOptions         : ReuseThread
RunspaceConfiguration : System.Management.Automation.Runspaces.RunspaceConfigForSingleShell
InitialSessionState   :
Version               : 2.0
RunspaceStateInfo     : Opened
RunspaceAvailability  : Busy
ConnectionInfo        :
ApartmentState        : STA
InstanceId            : 8d3bfae1-8b64-433d-9ab9-ce640b15f84f
SessionStateProxy     : System.Management.Automation.Runspaces.SessionStateProxy
Debugger              : System.Management.Automation.Debugger

Donc en bref, vous êtes ok ici. La technique avancée dont il parlait était très probablement comment tourner une nouvelle instance d'exécution à l'aide ReuseThread qui est maintenant redondante puisque c'est l'option de fil par défaut pour -STA. Vous pouvez toutefois utiliser cette technique pour fonctionner sur un seul thread en mode MTA; -)

-Oisin

MVP Microsoft PowerShell