- 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
June 28, 2009
Media Center Status Application version 0.5.3.1 released
Fixes
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.
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
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.
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:
while custom ProjectOwner field value without List="UserInfo" in its definition is exported like this:
<Field Name="ProjectOwner"
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.
Subscribe to:
Posts (Atom)