VS 2010 RTM and SP 2010 RTM – Deployment Conflict Resolution will break modules!
What a way to lose 4 hours of your life.
I was in a glorious mood this morning having upgraded my main development environment to RTM (both SharePoint 2010 and Visual Studio 2010 (Premium)).
The main code base we’d been working on (a brand new SP2010 web site, due to go live next month) compiled, the packaged could be created and I manually deployed the WSP and all was good … that is until I tried the “Deploy” button in Visual Studio…
Error Occurred in deployment step ‘Add Solution’: Value cannot be null. Parameter name: s
FAIL
So what on earth could be causing this error? Well, I stumbled across a registry edit that enabled diagnostics logging for SharePoint projects in VS 2010 (thanks to Glyn Clough for letting me know about it).
Enable Diagnostics Logging for SharePoint Projects in Visual Studio 2010
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\SharePointTools] “EnableDiagnostics”=dword:00000001
This gave me a stack trace in the Output window for the build alongside the error message, as follows:
(I have highlighted the error message, as well as the line throwing it .. the StringReader constructor complaining that it’s been passed a null value!)
—— Build started: Project: MySharePointProject, Configuration: Debug Any CPU ——
MySharePointProject -> C:\Projects\MySharePointProject\bin\Debug\MySharePointProject.dllSuccessfully created package at: C:\Projects\MySharePointProject\bin\Debug\MySharePointProject.wsp—— Deploy started: Project: MySharePointProject, Configuration: Debug Any CPU ——
Active Deployment Configuration: Default
Run Pre-Deployment Command:
Skipping deployment step because a pre-deployment command is not specified.
Recycle IIS Application Pool:
Skipping application pool recycle because no matching package on the server was found.
Retract Solution:
Skipping package retraction because no matching package on the server was found.
Add Solution:
Error occurred in deployment step ‘Add Solution’: Value cannot be null.
Parameter name: sException Message: Value cannot be null.
Parameter name: s
Exception Type Name: System.ArgumentNullExceptionException Stack Trace: at System.IO.StringReader..ctor(String s)
at System.Xml.Linq.XDocument.Parse(String text, LoadOptions options)
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.XmlDocument.GetXDocument()
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.XmlDocument.get_Document()
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.ModuleElementManifest.GetModuleElements(Boolean ignoreSetupPathModules)
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.ModuleElementManifest.GetFileElements(Boolean ignoreSetupPathModules)
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.ModuleCollisionFinder.b__2(ISharePointProjectItemFile elementManifest)
at System.Linq.Enumerable.d__31`3.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.SingleAspectCollisionFinder`1.FindConflicts()
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.DeploymentConflictFinder.FindAndAddConflictsTo(IDeploymentConflictCollection targetConflictCollection, Boolean promptBeforeResolve)
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.Module.DetectConflicts(DeploymentStepStartedEventArgs e, Boolean promptBeforeResolve)
at Microsoft.VisualStudio.SharePoint.ProjectExtensions.VSPackage.Module.DeploymentStepStarted(Object sender, DeploymentStepStartedEventArgs e)
at Microsoft.VisualStudio.SharePoint.SharePointProjectItemTypeEvents.RaiseDeploymentEvent[T](EventHandler`1 eventHandler, T e, ISharePointProjectItem projectItem, ISharePointProjectItemDeploymentContext context)
at Microsoft.VisualStudio.SharePoint.SharePointProjectItemTypeEvents.OnDeploymentStepStarted(ISharePointProjectItem projectItem, IDeploymentStepInfo stepInfo, ISharePointProjectItemDeploymentContext context, IDeploymentConflictCollection conflicts)
at Microsoft.VisualStudio.SharePoint.SharePointProjectItemType.OnDeploymentStepStarted(ISharePointProjectItem projectItem, IDeploymentStepInfo stepInfo, ISharePointProjectItemDeploymentContext context, IDeploymentConflictCollection conflicts)
at Microsoft.VisualStudio.SharePoint.Deployment.DeploymentUtils.NotifyStepStarted(IDeploymentStepInfo stepInfo, IDeploymentContext context)
at Microsoft.VisualStudio.SharePoint.Deployment.ConfigurationExecutor.Execute()
at Microsoft.VisualStudio.SharePoint.Deployment.WspDeploymenHandler.Deploy()
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========
So .. what does this tell us?
Firstly, all of the exceptions are being thrown by internal Microsoft assemblies. There is no custom code, no custom solutions and no 3rd party bolt ons. But the thing that didn’t jump out at me straight away was buried in the middle of the stack trace … a load of references to “conflicts”:
- VSPackage.Module.DetectConflicts
- VSPackage.DeploymentConflictFinder.FindAndAddConflictsTo
- VSPackage.SingleAspectCollisionFinder`1.FindConflicts
- VSPackage.ModuleCollisionFinder
This sparked inspiration… there is an option in Visual Studio 2010 to set Deployment Conflict Resolution on a module that you have added. Deployment Conflic Resolution will automatically check for files that you are deploying to see if they already exist. If they are outdated then Visual Studio can forcibly delete them and upload the newer versions (quite a nice feature .. when it works).