June 28, 2009

Media Center Status Application version 0.5.3.1 released

Fixes
  • Fixed 32 bit Configuration Tool to update Recording TV event configuration values
  • Fixed issue that caused error message if Facebook events were disabled but Twitter events were enabled
Download page

June 27, 2009

Vista support when developing Media Center applications on Windows 7

Problem:
I switched from Vista to Windows 7 x64 a while back and currently also do my software development on a Windows 7 machine.

Some time ago I begun getting complaints from some users that they were not able to use my Media Center Status Application as it was giving some "Invalid Application - Unable to launch FBMCE" errors when starting Media Center on Windows Vista.

I hadn't done any drastic changes in my program code and testing the application on Windows 7 machines (both x86 and x64) didn't indicate any issues. Finally I decided to really dig into this and installed Vista to Virtual PC. Well, what do you know, I immediately got the same error users were reporting :)

Solution:
Error message was because I had started to build my application on Windows 7 instead of Vista.

In Windows 7, the Media Center version of the assemblies referenced (Microsoft.MediaCenter.dll and Microsoft.MediaCenter.UI.dll) is 6.1.* but Vista only has versions 6.0.*.

Taking the assemblies from Vista and referencing those directly instead of the ones in Windows 7 GAC solved the issue and the application again works on both Vista and Win7.

June 26, 2009

Media Center Status Application version 0.5.3 released

Changes
  • Option to update status when TV show is being recorded, status will be "is recording PROGRAM NAME"
  • Configuration Tool now correctly shows UAC dialog when starting
  • Vista support is back
Download page

June 5, 2009

MOSS: Unable to import custom SPFields of type User

Problem:
Imagine the following scenario: You have created custom SPField for your Content Type. SPField is of type "User", i.e., a PeopleEditor field where you can select a one or several Active Directory users or groups.

In my case the SPField definition is something like this:

<Field ID="{UNIQUE_GUID}"
Name="ProjectOwner"
Group="MyGroup"
Type="User"
DisplayName="Project Owner"
SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"
StaticName="ProjectOwner"
Required="FALSE">
</Field>

Then you do a STSADM EXPORT and IMPORT for the SPWeb using Content Type using this SPField.

STSADM EXPORT succeeds, but STSADM IMPORT throws error:

Progress: Importing ListItem /a/windows-hardening/Pages?id=1.
FatalError: Value cannot be null.
Parameter name: g
at System.Guid..ctor(String g)
at Microsoft.SharePoint.Deployment.ListItemSerializer.UpdateFieldData(SPListItem listItem, ImportObjectManager objectManager, Guid docId, String fieldName, String value, String value2, Guid gFieldId, Boolean& bCreated, Dictionary`2 brokenFields)
at Microsoft.SharePoint.Deployment.ListItemSerializer.UpdateFieldData(SPListItem listItem, Guid docId, Boolean& bCreated, SPContentTypeId contentTypeId, ImportObjectManager objectManager, Object data)
at Microsoft.SharePoint.Deployment.ListItemSerializer.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)
at Microsoft.SharePoint.Deployment.XmlFormatter.ParseObject(Type objectType,Boolean isChildObject)
at Microsoft.SharePoint.Deployment.XmlFormatter.DeserializeObject(Type objectType, Boolean isChildObject, DeploymentObject envelope)
at Microsoft.SharePoint.Deployment.XmlFormatter.Deserialize(Stream serializationStream)
at Microsoft.SharePoint.Deployment.ObjectSerializer.Deserialize(Stream serializationStream)
at Microsoft.SharePoint.Deployment.ImportObjectManager.ProcessObject(XmlReader xmlReader)
at Microsoft.SharePoint.Deployment.SPImport.DeserializeObjects()
at Microsoft.SharePoint.Deployment.SPImport.Run()

Thoughts:
If you use -nofilecompression parameter when exporting and importing using STSADM, you can look at the exported Manifest.xml and see the difference between fields that have List="UserInfo" and the ones that don't.

OOB field PublishingContact value is exported like this:
<Field Name="PublishingContact" Value="2;UserInfo" FieldId="6677cf63-f416-4e1e-9e6e-f77f243ef4a6" />

while custom ProjectOwner field value without List="UserInfo" in its definition is exported like this:
<Field Name="ProjectOwner" Value="2;691e9a30-76c4-42b6-869f-294c2c68267d" FieldId="6677cf63-f416-4e1e-9e6e-f77f243ef4a6" />

You can see that the custom field contains the GUID of the list where the item is located in, while the OOB field contains clear reference to UserInfo list.

Solution:
First of all, remember to always include List="UserInfo" when defining SPFields of type "User", like this:

<Field ID="{UNIQUE_GUID}"
Name="ProjectOwner"
Group="MyGroup"
Type="User"
DisplayName="Project Owner"
SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"
StaticName="ProjectOwner"
Required="FALSE"
List="UserInfo">

</Field>

If you realize this requirement too late, you can modify the exported Manifest.xml and replace the values of the fields affected from:

<Field Name="ProjectManager" Value="2;GUID_OF_PAGES_LIST" FieldId="6677cf63-f416-4e1e-9e6e-f77f243ef4a6" </>

to

<Field Name="ProjectManager" Value="2;UserInfo" FieldId="6677cf63-f416-4e1e-9e6e-f77f243ef4a6"</>

and import after that.

In addition you need to have custom application that enumerates all existing items and fix field definition on them using API.