運用環境に展開中のカスタム Web パーツがいくつかあります。このプロセス中に、さまざまな部分で微調整が必要ないくつかのマイナーなことを見つけました。新しいコードを展開するには、新しいソリューション パッケージを作成し、機能を非アクティブ化してから削除し、ソリューションを撤回してから削除し、新しいパッケージで逆の順序ですべてをやり直します。言うまでもなく、これには時間がかかります。Web パーツをアップグレードするには、Web パーツを完全に削除する必要がありますか? それとも、Web パーツ/機能/ソリューションを適切にアップグレードできますか?
4 に答える
これは、ソリューションで何が正確に変化しているかによって異なります。特にソリューションをアップグレードするためのstsadm操作がありますが、それが処理するものに関してはいくつかの制限があります。特に、古い機能の削除と新しい機能の追加です。ただし、すべての新機能がWebパーツDLLに存在する場合、ソリューションアップグレードを実行すると、それ以上何もする必要なしに変更が展開されます。
Web パーツにマイナーな変更を加えている場合、アセンブリのバージョンが同じであれば、DLL を置き換えることができます。
もちろん、何がマイナーな変更であり、何も壊れないかについては、ここである程度の裁量を使用してください。
FileVersion と AssemblyVersion を正しく使用する方法については、このトピックを参照してください。
基本的に、マイナー アップデートでは AssemblyVersion を同じに保ちますが、FileVersion はコンパイルごとに変更されます。
これは、Microsoft が Microsoft.SharePoint.dll などで行う方法とまったく同じです。AssemblyVersion は 12.0 に固定されています。FileVersion はホットフィックス/サービス パックごとに変更されます。
ああ-あなたの答えの「生産部分」を読んだところです。このショートカットは、QA/生産よりも開発/テストに適している可能性があります
これを使って
stsadm -o upgradesolution -name "WSPName.wsp" -filename "c:/WSPName.wsp" -immediate -allowgacdeployment -allowcaspolicies
次に、sharepoint ジョブを実行します
stsadm -o execadmsvcjobs
一方、SharePoint PowerShell コマンドを使用して dll を更新できます。
Set-location "C:\Users\Documents\WSP"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Users\Documents\WSP\wspcustom.dll")
Windows SharePoint Services 3.0、v1.3 - Mar 2009 CTP 用の Visual Studio 2008 拡張機能を使用しました。それは私たちにいくつかの問題をもたらしましたが、慣れて正しい順序で物事を行うことを確認すると、うまくいきます.
このツールは、react / delete / deploy / activate .... ジョブを自動化します。
私たちがやろうとしているもう 1 つのことは、Web パーツの機能をできるだけ少なくすることです。移動できるものは別のdllに移動し、新しいバージョンのdllに対処するだけでアップグレードできることがよくあります。