Setting a default to the site collection administrator value

If you are like me, you may find yourself constantly creating site collections manually to test and retest something or other, and scripting the site collection creation doesnt always make sense - depending on what you are testing.

Today I got tired of entering the user name over and over again in the site collection administrator box - it is always the name of my user - which is the only user in my domain as it is a stand along development box. So...I hacked the page for site collection so it would have a default and I won't have to worry about it. Note that this should only be done in development boxes, and at your own risk.

My solution was to edit the built-in "createsite.aspx" file, sitting at "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\ADMIN\createsite.aspx". In that file I located the "PeopleEditor" control with ID "PickerOwner" and added CommaSeparatedAccounts="mydomain\ishai". Save, and done!

Activating Features using PowerShell does not trigger feature event code

If you ever try to activate a feature using powershell, and the code the feature was supposed to run doesnt run (or it runs, but doesnt reflect your changes) consider this- PowerShell, much like IIS, scans the GAC when it is started and caches the assemblies there. If you redeployed your code with modifications to your feature event handler (or anything else) and use an already open powershell window, the code will fail or will run the old version of the code, because it is cached.

Lesson learnt: always close the powershell window and open a new one when deploying a package...

Setting the "AllowedContentTypes" for a document set doesnt work

I really liked Cory's article on how to deploy documents sets using declartive XMl. However, when implementing it, I noticed two issues that prevented sharepoint from using the AllowedContentTypes declartion I used.

The first - the culprit was Inherits="TRUE" Version="0" in the content type declaration. If I removed those, sharepoint created the content type with the allowed content types properly defined.

The second one is that the content type that is referenced inside the AllowedContentTypes has to be created by a seperate feature. I had carefully made sure that all the document content types are declared before the document sets, but nothing worked until I seperated the document sets to a seperate feature, with a dependancy on the document content types' feature.

Duplicate content type "report" error

If you have a visual studio project that deploys a content type with the name "Report" - it may work...until you try to deploy it to a different site template. Different site templates in sharepoint contain different built-in content types, which explains why you should test your content type deploying solutions on different templates before announcing them ready for production!