Monday, July 22, 2013

DSOFile in 64bit to deal with Office 2013 custom properties

DSOFile.dll is the way to edit Microsoft office document properties without the office installed. Microsoft claims that it is independent, but I had came across scenarios where it requires one more file installed in the machine which is msoshext.dll at the location.

C:\Program Files\Common Files\Microsoft Shared\OFFICE<version>\msoshext.dll
eg: C:\Program Files (x86)\Common Files\microsoft shared\OFFICE15\msoshext.dll

This post is about an issue which you may face, if you run your application which uses DSOFile.dll in 64 bit machines with 32bit Office 2013 installed. Mainly when you run 32 bit apps in 64 bit.The issue occurs when ever the supporting file msoshext.dll is not present for target version of the applications which uses the DSOFile.dll. Lets see the scenario in deep.

The below code snippet is something which adds a custom property to the word document. If you are not familiar about the custom properties in office document just open a word file in MS word, go to properties page and select the custom tab.


                OleDocumentPropertiesClass doc = new OleDocumentPropertiesClass();
                doc.Open("test.docx"falsedsoFileOpenOptions.dsoOptionOpenReadOnlyIfNoWriteAccess);
                object val = "joysvalue";
                doc.CustomProperties.Add("joyskey"ref val);
                doc.Save();


You may experience as it just stopped updating the custom properties in the above environment (64Bit machines which have 32bit office). ie if you look at the custom properties dialog after opening the docx file you cannot see it there.

But interesting thing is, if you again try to add the same custom property you will get an exception. I tried as much as I can to identify where the custom property is being stored but I can't find out. We can verify it as well by executing the below code


                OleDocumentPropertiesClass oleDocument = new OleDocumentPropertiesClass();
                oleDocument.Open("test.docx"falsedsoFileOpenOptions.dsoOptionOpenReadOnlyIfNoWriteAccess);
                foreach (CustomProperty property in oleDocument.CustomProperties)
                {
                    Console.WriteLine("Pro Name {0},Value{1}", property.Name, property.get_Value());
                }


Simply saying, the first code snippet added the custom property to the document. Its accessible, if we iterate the CustomProperties collection but cannot visible in the office application's custom properties page.

Alternative

When you put this question in developer forums you will get an advise to go with open xml sdk. This is the solution to the problem but the drawback is it will work only with the open xml office documents such as docx,pptx,xlsx etc...The old office documents such as .doc, .ppt, .xls etc... are not at all supported by open xml sdk.So if your application needs to deal with both the formats using same code base you need to find the solution to the DSOFile issues in 64 bit. 

Solution

Install all the latest possible office 2013 updates and make sure you have the msoshext.dll in the right location. If your application is 32 bit you need to have the file in the c:\program files (x86)\ folder. Also make sure that the DSOFile.dll is registered properly for 32 bit (Using C:\Windows\SysWOW64\regsvr32.exe) and 64 bit in the 64 bit environment.

The above updating is applicable to all versions of office, if its installed in 64 bit machines.

2 comments:

Unknown said...

Does your solution work in VBA? I currently have a Word 2003 VBA macro that uses dsofile.dll 1.4 to edit document properties across multiple Word docs. Alas, it doesn't work in Word 2010.

Blogger said...

Are you looking to make money from your websites/blogs via popup ads?
If so, did you try using PopAds?