Just posted new DPack version 3.0.15 beta 2, which is gonna run for the next 20 days or so. It includes an important change, which I wanted to get tested a bit more before pushing it out. A bit of explanation is needed about the nature of the changes I made.
Most of the features in DPack rely on Visual Studio file code model (FCM) for project language discovery. Project language is used to match the project to the ones which are fully supported by DPack, C#, VB, etc. Once match’s made DPack can then determine if such and such file in the project a code one or not, and thus, if its code model (CM) can be retrieved. That code model is used by features like Code and Solution Browser, for instance, to discover file members.
So, if project’s file code model is not available then DPack skips the project processing. In other words, this project file code model reliance prevents DPack from being able to process non-supported projects like IronPythin or newly released Lightswitch for instance. In reality this behavior is perfectly fine for the features that rely on individual file code model but makes little sense for the ones that don’t utilize it. For instance, File Browser and Solution Backup shouldn’t care about project’s language, as all they do is either open files or back them up.
The changes I’ve made relax File Browser and Solution Backup file code model reliance. From here on these feature should be able to get to any project file, as long as those files are exposed/accessible via Visual Studio extensibility. In case of File Browser, most/all of those type of files will show up as non-code ones, so make sure to toggle All/Code Files option. All this means that projects like Lightswitch, IronPython, etc. will be (partially) supported now.
Hope this makes sense. Please report any problems you run into. Thanks.
Sergey @ USysWare