Comments on Chris O'Brien: Fix to my Config Store framework and list provisio...

An interesting discussion. I've found both Con...

2009-11-09T02:49:01.254Z

An interesting discussion. I've found both ContentTypeRef and ContentTypeBinding are required for everything to hang together "properly":

http://blog.mediawhole.com/2009/11/contenttyperef-vs-contenttypebinding.html

I reckon. Though I don't know what happens if the ...

2009-04-24T11:39:00.000+01:00

I reckon. Though I don't know what happens if the List doesn't have *any* content type defined for it. Maybe you have to have at least one ContentTypeRef'd content type, but you can then bind other ones later.

And you would need a ListInstance node in the feature too. So, I think you'd need:

- ContentType node for your content type
- List node to define the type of list
- ListInstance create on of your lists
- ContentTypeBinding to attach the content type to your newly created list.

Actually, I suppose that highlights the main difference - the ContentTypeRef connects the content type when the list is defined, and so it's provisioned already attached, while the ContentTypeBinding is attaching one AFTER the list exists.

Interesting :-) So having read your article, do w...

2009-04-23T16:35:00.000+01:00

Interesting :-)

So having read your article, do we conclude you can use either ContentTypeRef or ContentTypeBinding if deploying a list + content type in the same Feature?

C.

I had a bit of a look out of curiousity. It seems that the ContentTypeRef is for when you initially define the list, and the ContentTypeBinding is for when you want to add one later.

@Andy, :-) On point 5, yes I agree that's the re...

2009-04-23T13:09:00.000+01:00

@Andy,

:-)

On point 5, yes I agree that's the reason why it's safe to remove those fields - I should have been clearer there.

Interesting you raise ContentTypeBinding. I use this in other areas (e.g. associating content types with Pages libraries). Don't think it had occurred to me that I could use it here also.

Which kinda makes me wonder why the schema provides two ways of doing the same thing, but that could lead to whole 'nother discussion ;-)

Cheers,

C.

@Marshal, Interesting - think that's effectively ...

2009-04-23T12:19:00.000+01:00

@Marshal,

Interesting - think that's effectively what our code workaround did. Assume there's no data loss doing it this way?

Seems to point more and more that the December CU was 'less tolerant' of mistakes in the provisioning XML perhaps?

Thanks,

C.

P.S. Good to see you're using both Config Store and Language Store :-) I'll backport this fix to Language Store over the next week or so and release a new version.

Nice to know that even MVPs can have problems with...

2009-04-23T08:08:00.000+01:00

Nice to know that even MVPs can have problems with the CAML schema!

Regarding point 5, isn't it just that you don't have to include fields that are being inherited from a parent content type? Therefore, all the 'System' ones (which come from the 'Item' content type, or higher) aren't required, but are implied?

Also, you can use the ContentTypeBinding element to attach one to a list.

Hello Chris, We were have same issue with config a...

2009-04-23T05:04:00.000+01:00

Hello Chris,
We were have same issue with config and lang store after DEC CU... and we got it resolved by removing config content type from list and re-attaching it to list from browser....