這一篇的內容，是關於Solution的使用建議的，如果大家一些實用的建議，歡迎留言討論。

　　一. 版本控制

　　Solution是有版本號的，率性的人可能在新建一個solution的時候，直接賦值1.0，就不再管了。但是這裏還是簡單說下MS風格的版本號，一般是用.分隔的四個數字：主版本號.子版本號.編譯版本號.修正版本號。後面兩個版本號可選或者互換位置，前面兩個必須。建議叠代周期，要做好Solution版本號的設計和管理。這方面的好處不多贅述了，畢竟不管是不是開發，都能想得明白。

　　二. 分門別類

　　分類其實是為了更好對Solution進行管理。我們知道CRM有不少類型的Components，而在Solution裏，如果你把所有的Components都放到一個Solution裏，你會發現越到後期，你的Solution就越難維護。那麽是不是我把components從數量上簡單地拆分開就可以了呢？比如我把很多的workflow，plugin，Entity拆分到多個Solution裏。並非如此，這裏說的分門別類，一般可以從這幾個方面考慮：

　　1. component本身的類型

　　2. component涉及的業務：包括業務邏輯，業務部門

　　3. component的依賴關系

　　4. component的數量

　　5. component與項目叠代的關聯

　　現在MS的產品，走的是模塊化的設計理念，那麽這個模塊化，我們應用到Solution裏，也是一樣適用的。比如你要考慮，哪些Solution可以規劃成一個“模塊”，如果部署之後，將來客戶不要了，可以在不影響當前業務的前提下直接刪除（看現在的AppSource裏的Solution產品，都是可以在不影響環境結構的前提下，實現Solution的導入和刪除的）；哪些Solution是屬於xx部門的，即使以後Solution有更新，也可以在不會影響其他部門業務的前提下實現更新；哪些Solution對其它的Solution有依賴，而被依賴的Solution是不是設計的比較Common等等。

　　三. 下載日誌

　　一般情況下，Solution導入成功或者失敗，最後都會有download log選項。借用這個日誌，我們可以準確高效地定位出錯的Component以及可能的原因。

　　1. 導入失敗

　　不要用記事本打開下載的log文件，那樣你會看到密密麻麻的信息，很不直觀。使用Excel打開log，你會發現所有的component信息，狀態信息，comments信息都已經有條理的列好了，很方便地就可以找到失敗的component，以及失敗的描述信息，來幫助我們解決問題。有一點需要註意的是，因為CRM的導入操作就是往數據庫裏修改數據，那麽就會碰到一個讓人很無奈的情況：即使你的Solution問題再多，CRM也只會導入一次才暴露一個問題，而不是像有統計列表那樣，一次把所有的問題都暴露出來。

　　2. 導入成功　　

　　可能許多人看到CRM顯示Solution導入成功，就直接關閉窗口，覺得log可有可無了。在這裏，還是建議大家，即使導入成功了，也把log保存下來。有兩方面的原因：一方面是即使導入成功了，還可能會有很多的warning信息，有些warning信息甚至會影響後續的操作。比如，你更新一個workflow的Solution，導入雖然成功了，但是你發現為什麽workflow activate失敗了呢？如果你查看導入log的warning信息，就可能找到一條提示信息“workflow涉及到user在當前環境沒有......”。另一方面的原因，是如果以後有一個環境問題是因為當初的這個Solution，還可以當做一個處理問題的依據。

　　3. 導入ing

　　之所有說導入Solution一般都會下載log的選項，是因為還存在非一般的情況。如果硬件資源不足，或者Solution本身太復雜，可能會出現的情況，是進度條卡在最後的85%左右，然後就再沒有反應了。這種情況，可以通過檢查Solution的版本號，來確認Solution是否導入成功，當然，這個時候，就不會有下載log的操作了。

Dynamics 365-關於Solution的那些事(三)