看了一些 MOSS 2010 的新開發特色後，迫不及待的想試一下 OData 的實作。輸入 http://moss/_vti_bin/listdata.svc 後，原本預期出現的 atom xml 並未出現，取而待之的是會錯誤訊息。
無法從組件 'System.Data.Services, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' 載入型別 'System.Data.Services.Providers.IDataServiceUpdateProvider'。
怎麼會這樣呢？
參考這一篇 blog，下載 ADO.NET Data Services Update 並安裝，重新開機之後就ok了。
MOSS 2010 的介面(V4)固然好用，但使用者不習慣，不買單，也莫可奈何。
如果選了「更新使用者介面」並按確定了，Site Administrator 也就沒有 UI 可以換回 MOSS 2007 (V3) 的版本了 。
幸好，還可以寫程式。不過，寫 Code 還要 compile，太麻煩了。
MOSS 新版的 2010 有 PowerShell 可以使用。
$site = Get-SPSite("http://mosserver")
$web = $site.OpenWeb("path1/path2/path3")
$web.UIVersion = 3
$web.Update()
$web.Dispose()
$site.Dispose()
在 Team Foundation Server 2010 發佈後，迫不及待地想要試試新的功能。
在 MOSS 2007 上安裝 TFS 2010 的 Extension for SharePoint Products 後，有些 WebPart 的按鍵上，原本可執行下載檔案的功能，競會出現 403 的錯誤。
同事還以為被攻擊了。心想，哪來這麼多攻擊呢？查一下 wss\80 下的 web.config已被修改過了。與上次的內容相比，多了一些 TFS 在使用的設定。例如 在 httpModules 就多了這個 module
<add name="TSWASPModule" type="Microsoft.TeamFoundation.SharePoint.WebAccess.TSWASPModule, Microsoft.TeamFoundation.SharePoint.WebAccess, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />心想是不是這些設定搞的鬼。試著註釋掉這些設定，仍然不見效果。
特殊的是，管理員仍然可以下載檔案，而一般的使用者不行？細想一下，是不是檔案的安全性出了問題呢？查了一下，果然是。
安裝 Extension for SharePoint Products 後，該安裝程式試著將 c:\inetpub\wwwroot\wss 下的目錄還原到原本的設定，我之前所作的設定就不見了。因此下載失敗。
將 domain\everyone 加回到 wss 的目錄下並授與讀取和執行、列出資料夾內容、讀取的權限後，WebPart 的下載檔案就又回原如初了。
一個沒注意，一堆新版本就冒出來。
Enterprise Library 5.0 , EL 5.0 on MSDN
Office 2010 及 Moss 2010 則必須到 MSDN subscriptions 下載
這下子，連上次的 Visual Studio 2010，可以讓我忙整年了。
有同事一次將4000 多個檔案放到MOSS 的文件庫後，卻沒有簽入。此時，再請他簽入時，卻只能一個一個檔案簽入了。
救命啊！果然不是人做的。此時只有使用系統帳號，取得所的已取出文件的所有權，然後再以系統帳號再簽入。
可是，還是不行。因為一次要處理的文件太多了，全選並取得所有權時，伺服器會出現 Sql Server Parameters 最多只能有 2100 個的限制。
只好寫程式了。以下就是我寫的程式。
private static void TakeOwnershipOverAllCheckoutFiles(string sitePath, string refWeb, string listName)
{
using (SPSite site = new SPSite(sitePath))
{
SPWeb web = site.OpenWeb(refWeb);
SPList list = web.Lists[listName];
SPDocumentLibrary library = (SPDocumentLibrary)list;
IList<SPCheckedOutFile> files = library.CheckedOutFiles;
foreach (SPCheckedOutFile file in files)
file.TakeOverCheckOut();
}
}
這樣一來，就避免了Web UI 的限制。
天啊！不知道為什麼，取出一個文件後，要存回時竟然發生this document was checked out to your local drafts folder but the local copy could not be checked in to the site。
如下圖。
這是怎麼回事？在同一目錄的檔案都正常，唯有這個檔案才這樣，難道是我編輯太久了嗎？
目前我毫無辦法。只能
就是避開這個檔案。
在MOSS 2007 上，有個預設的核准流程。
客製化時，需要取得文件庫的「核准」結果。
但取得後，卻是字串的 17 ??
上網查了一下，該值可能如下。
// In Progress – 2
//Complete – 5
//Canceled – 15
//Approved – 16
//Rejected - 17
public static string GetApprovalDesc(string approval) { switch (approval) { case "2": return "InProgress"; case "5": return "Complete"; case "15": return "Cancled"; case "16": return "Approved"; case "17": return "Rejected"; default: return approval.ToString(); } }
這個結果，並非我最想要的。因為「核准」流程的對象，可以自己。
這一點實再不能接受。
下一次，需要找一個送審者與審核者的對照。
最近在寫 WebPart，有點麻煩。
使用拖拉元件的方式寫習慣了，對於類似元件的實作很不熟悉。
SharePoint 的 life cycle，與其他不大相同。
比較一下 Sharepoint WebPart Lifecycle Events 與 ASP.Net Page Lifecycle in Text mode, 可以發現 SharePoint，Asp.Net 的 CreateChildControls 時間不同。
Asp.Net的 CreateChildControls 比 OnLoad 晚。
SharePoint WebPart 在 !Page.IsPostback 時， OnLoad 比 CreateChildControls 早。
SharePoint WebPart 在 Page.IsPostback 時， CreateChildControls 比 OnLoad 早。
為了這個不同，我又花了兩個小時在 debug.