Часто бывает удобно выделить общий для нескольких проектов код в отдельную сборку и подключать её к проектам. Собственно, так же, как и чей-то чужой код в виде готовой сборки (с codeplex.com и подобных ресурсов).
При этом сразу же встаёт во весь рост проблема размещения такого общего кода. Очевидное, простое и поэтому неправильное решение, быстро приходящее в голову – поместить общие сборки в пакет каждого использующего их проекта – отметается после удаления одного из таких пакетов. Общие сборки тоже удаляются и остальные решения перестают работать. 
Попытки использовать имеющиеся под рукой установщики (Установщик Visual Studio 2010, Wix Toolset 3.5, InstallShield LE, установщик 7-zip и т.п.) оказались плачевными – либо пользоваться неудобно, либо не имеет нужной функциональности, либо не умеет обновлять ранее установленные сборки. Мрак какой-то… 
Лучшим вариантом оказался собранный вручную wsp-пакет в сопровождении двух cmd-файлов для установки и обновления.
Описание пакета в файле makecab.ddf:
.OPTION EXPLICIT ; Generate errors on variable typos
.Set CabinetNameTemplate=SP.Shared.Assemblies.wsp ; The name of the WSP file
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP
.Set Cabinet=on
.Set Compress=on
.Set DiskDirectory1=.
.Set CabinetFileCountThreshold=0
.Set FolderFileCountThreshold=0
.Set FolderSizeThreshold=0
.Set MaxCabinetSize=0
.Set MaxDiskFileCount=0
.Set MaxDiskSize=0
SharedAssembly.dll
SharedAssembly2.dll
...
manifest.xml
Файл manifest.xml:
<?xml version="1.0" encoding="utf-8"?>
<Solution xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
SolutionId="guid..."
xmlns="http://schemas.microsoft.com/sharepoint/">
<Assemblies>
<Assembly Location="SharedAssembly.dll" DeploymentTarget="GlobalAssemblyCache"/>
<Assembly Location="SharedAssembly2.dll" DeploymentTarget="GlobalAssemblyCache"/>
</Assemblies>
</Solution>
Собирается пакет командой makecab /v1 /f makecab.ddf, устанавливается файлом _install.cmd :
@set prompt=$g
@set spver=14
@set wsp=SP.Shared.Assemblies.wsp
@set admpgm="%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\%spver%\BIN\STSADM.EXE"
@time /t
%admpgm% -o addsolution -filename %wsp%
%admpgm% -o deploysolution -name %wsp% -allowCasPolicies -allowGacDeployment -immediate -force
@pause
%admpgm% -o execadmsvcjobs
Для обновления используем файл _upgrade.cmd :
@set prompt=$g
@set spver=14
@set wsp=SP.Shared.Assemblies.wsp
@time /t
@set admpgm="%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\%spver%\BIN\STSADM.EXE"
%admpgm% -o upgradesolution -name %wsp% -filename %wsp% -immediate -allowCasPolicies -allowGacDeployment
pause
%admpgm% -o execadmsvcjobs
Конечно, в соответствии с новомодными тенденциями можно применить PowerShell, но некоторым так привычней 
Technorati Tags:
Sharepoint
) – при консолидации списков набирается много, а запрос данных дорог и прямо напрашивается на параллельное исполнение…
Нельзя не поприветствовать! 
. Пока к такому не готов, а файлов/объектов намечается довольно много...
. Собственно, разработчик этого метода, похоже, не подозревал о способностях поля работать с “посторонними” списками, поэтому и не использовал параметр LookupWebId 
, а по-простому обращался к списку со “своего” узла. Нормальненько так… 
