Posts Tagged ‘visual studio’

The field with Id {} defined in feature {} was found in the current site collection or in a subsite

Tuesday, November 1st, 2011

This is a known bug in Visual Studio. It seems to occur most often when using VS to deploy (and redeploy) declarative content types to a SharePoint site. I’ve seen it happen most often when deploying List Definitions and List Instances. There are a variety of steps out there to try to make it go away:

1. Retract solution, close VS, restart VS, deploy solution.
2. Deploy project, attempt to activate via UI, deactivate, retract, restart VS, deploy solution.
3. Deploy, retract, deploy. Open Task Manager, kill VSSHostP4.

Deploying after this should be resolved.

Error activating features. Field ” could not be found, it may have been deleted by another user.

This is not a bug, more of an irritation. If you’re deploying List Instances using Visual Studio, you may see this if you create your List Definition/Content Type/Fields, but then forget to add the Fields to your List Schema. At the top of the Schema, you can supply a

ContentTypeRef

(the ID of your Content Type) and then in the Fields collection, essentially copy your Field definitions in.

Other deployment related issues

One other issue you may encounter is in the ordering of items in your Feature/Package. It might seem obvious but you must ensure things are ordered in the way that they will be needed during deployment. That is,

  • Fields
  • Base content types
  • Content types that inherit base content types
  • Anything that uses the content types and fields, e.g., Document Set Content Type. Note: if your Document Set is using a custom Welcome Page (deployed via a module/element), this must be deployed first
  • List definitions
  • List instances
  • Anything else

You can arrange the deployment order in the Feature designer screen. But be warned- if you’ve got a lot of Elements in your project (and multiple projects in a solution), then it’s a pretty gnarly process.

Other deployment pointers? Leave a comment below.

SharePoint 2010 + Kofax Express + Object reference not set to an instance of an object

Friday, July 1st, 2011

I’ve been working with Kofax Express 2.0 recently to move documents from a scanner directly in to a SharePoint document library. I was using a custom list definition (created in Visual Studio) but was experiencing a strange error. If I created an instance of my list through the UI and then tried to scan from Kofax directly in to SharePoint, it was working no problem. However, if I tried to scan directly to SharePoint to the instance of the list created by the Visual Studio solution, I was getting the common error – “Object reference not set to an instance of an object”. There were no helpful logs on the Kofax or SharePoint end, and it was only through trial and error that I found the issue. I noticed that when the list was created through the UI, it was created with a URL of “/Document Library Name” whereas in my list instance definition in Visual Studio, I had given it a URL of “/Lists/Document Library Name”. It was the Lists part at the beginning which was causing an error. I don’t know why this caused Kofax to fail to find the library, but nevertheless, setting the URL in the list instance as just “/Document Library Name”, resolved the issue.

SharePoint workflow + list item edit + value cannot be null

Thursday, May 26th, 2011

You may encounter a random error when using a custom Visual Studio SharePoint 2010 workflow. Everything appears OK, but when you go to edit the item that the workflow is running on, the EditForm fails to load and you see an error like:

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ArgumentNullException: Value cannot be null.
Parameter name: s

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[ArgumentNullException: Value cannot be null.
Parameter name: s]
System.IO.StringReader..ctor(String s) +10151478
System.Xml.XmlDocument.LoadXml(String xml) +51
Microsoft.SharePoint.Publishing.Internal.WorkflowUtilities.FlattenXmlToHashtable(String strXml) +90

(more…)

SharePoint + Visual Studio + Get Current User

Wednesday, May 4th, 2011

A frequently asked question in the MSDN forums is “how you can get access to the user who is interacting with your workflow?”. For example, the user modifying a task. The workflow is likely running in a different context and/or session to your browser session so there’s not an obvious tie-up.

However, in this scenario, you can get the login name of the person who modified the SharePoint task, via the Executor property of the OnTaskChanged event. Simply bind the Executor property to a string (e.g., “taskLastModifiedBy”) and whenever the task changes, SharePoint will copy the user ID to this property in the format of DOMAIN\\LoginName. You can then get an SPUser object for that login name with, e.g.

SPUser user = workflowProperties.Web.AllUsers[taskLastModifiedBy];

Note: On a related subject, and the thing that prompted this post – if you’re trying to update a Person or Group field on your workflowProperties.Item, then you must pass it an SPUser object! This is bizarre, because other types of list (e.g, the task list) you can pass it a string and SharePoint will do the rest. I spent ages and all kinds of different things and always getting the “Invalid data has been used to update the list item. The field you are trying to update may be read only.” error. Annoying.

(more…)

Visual Studio 2010 Workflow + Infopath 2010 forms – troubleshooting

Monday, March 28th, 2011

Microsoft markets that Sharepoint Designer workflows are directly exportable to Visual Studio workflows. And in many ways, this is absolutely true. It’s trivial to create a .wsp from an SPD workflow and import it to VS. However, if you then inspect the workflow that has been created for you, a little concern would not be underestimated. If your SPD workflow was what you wanted, then you could be reasonably confident that its VS version would do the same job. But presumably your reason for importing to VS is because you need more control over the workflow in the longer term, in which case, you’re likely to be left underwhelmed by what the import process creates for you. Imagine creating a webpage in Microsoft Word and you’ll get the drift.

So when faced with a similar proposition, recreating the workflow in Visual Studio from scratch immediately became apparent as the best solution. After all, the intent and purpose of the workflow was clear; recreating it in VS ought to have been a doddle. However, to complicate matters, the SPD workflow used Infopath edit forms. This turned out to be easy in SPD, but non-trivial in Visual Studio. Getting an Infopath form to register with a VS workflow project requires various items, that VS may not do automatically for you.

(more…)