How to determine the ProjectItem language type without opening the document in vsx?

When a file is open in the 开发者_开发技巧visual studio editor, through the EnvDTE.Document.Language property a string result such as "CSharp", "C/C++", "HTML", "JScript", etc. is returned specifying the language of a file. I'd like to be able to access that same language information when a file is not open (i.e. from a ProjectItem context).

EnvDTE.ProjectItem.FileCodeModel.Language seemed promising, but only gave me a result for CSharp files. No information was available for HTML, XAML, etc.

I could make assumptions based on file extensions, but being able to retrieve the language as interpreted by Visual Studio (presumably through the language service(s)) would be a lot more robust. It seems like the information is available since it is stored on the document, but I haven't been able to find the right API for accessing it.

Any help or suggestions would be greatly appreciated. :)

For anyone else who may stumble upon this, I found an approach that will work. I'm still interested to hear if anyone has a cleaner solution.

• Import the Microsoft.VisualStudio.Package.LanguageService.9.0 (or equivalent) assembly.
• Instantiate an EditorFactory
• Call GetLanguageService on the EditorFactory instance, passing the extension of the project item (i.e. System.IO.Path.GetExtension(ProjectItem.Name))
• Compare the returned language service GUID against known constants. You can dig these out of your registry under HKEY_USERS\.DEFAULT\Software\Microsoft\VisualStudio\10.0_Config\Languages\Language Services (or equivalent)

Here are the language service guids I found to save someone else the trouble of looking them up:

CSharp: "{694DD9B6-B865-4C5B-AD85-86356E9C88DC}"
C/C++: "{B2F072B0-ABC1-11D0-9D62-00C04FD9DFD9}"
CSS: "{A764E898-518D-11d2-9A89-00C04F79EFC3}"
HTML: "{58E975A0-F8FE-11D2-A6AE-00104BCC7269}"
JScript: "{59E2F421-410A-4fc9-9803-1F4E79216BE8}"
XAML: "{c9164055-039b-4669-832d-f257bd5554d4}"
XML: "{f6819a78-a205-47b5-be1c-675b3c7f0b8e}"

Note: I found that the JScript language service was incorrectly mapped to HTML by default.