Imaginons que vous fassiez du développement en mode Sandbox. Dès que vous modifiez votre code, si vous souhaitez tester la modification, il faut redéployer la solution. Certes, via Visual Studio, cette manipulation ne demande qu’un seul clic, mais l’opération de déploiement peut prendre un certains temps, mais surtout désactive / réactive la solution Sandbox, ce qui peut avoir des impacts sur vos listes instanciées par Sandbox par exemple.

Revoyons l’architecture Sandbox : http://msdn.microsoft.com/en-us/library/ie/ff872402.aspx

Comme nous le savons, les solutions Sandbox ne “tournent” pas sur le process standard IIS :

Elles sont exécutées sur un service SharePoint particulier nommé “SPUCWorkerProcess.exe”.

Lorsque SharePoint accède pour la première fois à cette solution Sandbox (stockée dans le site SharePoint, donc dans la BDD), les DLLs de cette solution sont copiées en local, sur le serveur exécutant le service Sandbox.

Plus précisément, elles sont stockées dans un sous-dossier sous ce répertoire :

C:\ProgramData\Microsoft\SharePoint\UCCache

En triant par date, vous verrez rapidement le sous-dossier en question

L’astuce : En développement, quand vous souhaitez redéployer une DLL (juste la DLL), alors il suffit de copier manuellement la DLL générée par Visual Studio dans le dossier ci-dessus. C’est tout.

Attention : Si le service Sandbox redémarre ou si vous redéployez la solution Sandbox, cette DLL sera écrasée par celle contenu dans la solution Sandbox.

Mise en garde : Comme expliqué dans cet article (http://msdn.microsoft.com/en-us/library/ie/gg615461.aspx), Microsoft déconseille cette opération (même pour les développeurs)

D’un point de vue personnel, je l’ai utilisé de nombreuses fois en DEV sans souci.