2009-04-15 77 views
0

系統管理員正在編寫一些常見的內務管理Power Shell腳本。主要用於AD管理(更新交換細節,移動安全組周圍的人等)C#Powershell Interop

我想從C#中使用這些腳本(我打算將它編寫爲一個庫,由網站使用)。

我見過這個code project article看起來很有趣,也是一個很好的開始。

有沒有人有任何Power Shell互操作經驗?任何人都能想到任何重大的陷阱,然後我先跳入棘峯?

額外的信息:

我很欣賞有特別CI和版本後勤挑戰。

該計劃最初使用目錄服務,通過Web API和CmdLets公開服務。不幸的是,我們在目錄服務方面遇到了困難(例如大集合的截斷結果)。

與此同時,我不應該使用不一致的組合,而是應該使用系統管理員的腳本進行調查。爲什麼重新發明輪子?

我已經寫過我的域模型。我打算實施存儲庫模式,以便我可以抽象出允許將來使用不同實現的AD/Exchange集成。

回答

2

如果腳本依賴於系統或用戶配置文件,則需要首先將配置文件顯式點播到您的運行空間。

更高級別的控制(例如,從一個命令傳輸到另一個命令,訪問調試輸出)需要更高級/低級別/複雜的工作。

除此之外,它都可以工作。

+1

理查德,我不知道你是什麼意思的點源的個人資料。你可以擴展嗎? – 2009-04-17 16:24:19

1

我不認爲這種方法有很多問題需要從編譯的程序運行腳本的常見問題。我覺得最大的問題往往是

  1. 防止人們移動腳本
  2. 確保人們不要在沒有反映在調用程序的腳本中添加隱藏的依賴。

但我認爲你應該考慮爲你的發展另一種模式。爲什麼不將所有的邏輯添加到已編譯的庫中,而不是讓程序引用一個腳本。這可以很容易地鏈接到程序中,並通過CmdLet暴露給PowerShell。我發現這是維護程序腳本之間共享代碼的一種更簡單的方法。

1

我已經花了最近幾個月從C#應用程序運行PowerShell代碼,它工作正常,你可以做一些非常有趣的東西。這就是說,JaredPar提到在應用程序之外的腳本文件中使用PowerShell腳本可能會很痛苦。我將所有PowerShell代碼放在一個庫中,然後將其發送到需要的位置,並且運行良好。