Posts Tagged ‘deployment’

« Older Entries

SharePoint 2010: The filename, directory name, or volume label syntax is incorrect

Monday, November 7th, 2011

This is a peculiar little bug. When creating a List Definition, you may encounter the following error when you try to deploy:

The filename, directory name or volume label syntax is incorrect.

It took a while to track the cause, seeing as a lot of info out there info out there relates to things to do with file systems, which in this case, obviously wasn’t the cause.

The bug for me was that I had created a List Definition and called it My.List.Definition – notice the multiple periods. I wanted it to match the namespaces that we were using. It turns out that the second period trips it up. When you create a List Definition with multiple periods, the List Definition only gets the first period, e.g., My.List, whereas the Elements.xml file for the List Definition still references My.List.Definition – hence it can’t deploy properly.

To fix, edit the Elements.xml file to match the List Definition name. However, I’ve experienced knock-on issues as a result of this, for example, instances of the List Definition fail to deploy. It seems more reliable to completely delete the List Definition and recreate it with at most one period in the name.

Tags: ,
Posted in SharePoint | No Comments »

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.

Tags: , ,
Posted in SharePoint | No Comments »

More fun with deploying Document Sets via XML

Thursday, September 15th, 2011

To finish a set of posts about the fun I’ve had in deploying document sets as XML content types, here’s a fun little bug vagary I encountered. In the video walkthrough, there’s a section on deploying the custom WelcomePage to your site, and provisioning some WebParts automatically to that page.

You achieve this in the Elements.xml file of your WelcomePage module by including some <AllUsersWebPart>> sections. Within those tags, you enter the definition of the webpart, and you can reuse the built-in webparts.

(Hint: to get at the required definition for built-in SP webparts, find the webpart in the Webparts Gallery in Site Settings, save a copy of the file to your hard drive (as a .dwp file) and then open that file in Visual Studio. You get the required info. Neat.)

You can then deploy your feature, and assuming you’ve covered all the bases your Document Sets, with custom Welcome Page should be deployed. But here’s a problem. Let’s say you make some changes to it, and redeploy the feature. You may experience one of a series of behaviours:

1) None of your changes are displayed
2) Your changes are displayed OK
3) You end up with multiple webparts on your custom Welcome Page.

It’s the third issue I tripped over, and it seems to occur if/when you manually deactivate and reactivate your feature (using the “deploy” feature from VS doesn’t seem to cause this.) It makes some sense – the Elements.xml file says “add these webparts to this page”. Assuming you’ve not added any FeatureDeactivating event receiver to remove the webparts when the feature is deactivated, well, you’ll end up with lots of webparts on the one page.

This being the case, how do you actually go about getting rid of the extra webparts on the page? Retracting the solution doesn’t help. You could completely bin your site content type, site or even site collection. That would probably do it. But it’s a bit drastic. The alternative? Update the database manually. You can decide if this is more drastic than the previous options.

To be clear, you should never, ever, on any account, ever, manually hack the SharePoint content database!

But if you want to do it, here’s how:

(more…)

Tags: , , , , , ,
Posted in SharePoint | 3 Comments »

Updating declarative XML content types

Thursday, September 15th, 2011

Becoming a SharePoint developer is always a journey – every new day you spend doing something, the more you learn. More often than not, the more “little subtleties” you uncover about the great wide SharePoint platform. I recently tripped over one such example. This “issue” is not new in SharePoint development – it certainly goes back as far as MOSS2007, but unless you’re actually doing it, it’s not something you’d instinctively just know.

Creating content types via XML Visual Studio

As soon as you start building SharePoint solutions of any real size and complexity, you’ll quickly learn that creating fields and content types via the UI, or SharePoint Designer, is not a great solution. For instance, there’s no supported way to move a SPD designed solution from e.g., Dev to Live – that is, with SPD, you design directly against live. This can be OK for initial deployments, but as soon as the system has data in and you need to start potentially breaking things, this is not a good place to be in. The alternative to this is develop Visual Studio solutions and features, which are deployable pretty much wherever you’d like. You can define fields and content types in XML, and when you’re finished, package it all up and deploy. Simple, right? Well, no, not necessarily – as I mentioned recently, this process is not without its bugs and issues.

I’ve deployed a few solutions in this way, and was (until today) singing the praises of deploying content types via XML, thinking how wonderful it was to have the flexibility to build in dev, test and then deploy (i.e. what you can’t do with SPD). And of course, if you make any changes, you can update your solution and hey presto, nice neat update.
(more…)

Tags: , , , , , , ,
Posted in SharePoint, Tech | No Comments »

Error occurred in deployment step ‘Activate Features’: Invalid field name.

Monday, September 12th, 2011

I posted about an issue I had been facing with deploying document sets via XML, where things like the custom welcome page and the shared fields (defined in XmlDocuments) wasn’t showing up.

Here’s a further issue I encountered. I defined my Document Set content type in the usual way. A bunch of Site Fields, then the Content Type definition, and then within the FieldRefs section some FieldRef elements for the fields to use.

At some point, I started to experience a strange error – when I was deploying the solution, I would get an error:

Error occurred in deployment step ‘Activate Features’: Invalid field name.

After a bit of research, things pointed to the fact that this error was caused by not declaring a Name attribute in the FieldRef. And adding a Name in to the FieldRef resolved the problem. However, I had another solution, doing the same thing, which would deploy successfully, but didn’t specify the Name attribute!

After some trial and error, I narrowed it down to the Overwrite attribute of the content type declaration. According to MSDN:

Optional Boolean. TRUE to overwrite an existing content type with the same ID.
The default is FALSE.

I’d set this to true, for obvious reasons. If you remove the attribute, then FieldRef with no Name attribute deploy successfully. And the existing content type is overwritten as well!

Yet another bug/feature/futureproof attribute (like Version, it seems) that displays inconsistent behaviour and can cause lots of issues! Well worth getting used to the ContentType and Field schemas, and I’d suggest using the bare minimum of attributes required.

Tags: , , , ,
Posted in SharePoint | No Comments »

« Older Entries