Hi Josh,
Got your project file today, thanks. Did some testing with that. I copied one of my simple test Xaml files into that project's folder and renamed it such so I'd be able to open it in Solution Explorer. That's ignoring the rest of the missing files of course.
Interestingly enough, I do see a similar delay of roughly 10 seconds or so when opening that test Xaml file via 'Open with' (using your project). The output window shows that lots of UriFormatException and FileNotFoundExceptions are being logged, which leads me to believe that some Xml/Xaml processing is busy doing something. It opens fine w/o a VS crash though. A few seconds later, 5-10+, I see a thread terminatation logged in the output as well. It once actually said "The thread 'Parse Thread' (0xXXXX) has exited with code 0". I don't create a such thread so that confirms my Xaml parser theory.
Now, I think what might be happening is that some early DPack's request for file code model during Xaml file load or some of its internal thread processing gets in the way, somehow. That I think causes that thread to die a horrible death later on, taking VS along with it. That's why we haven't seen any legit DPack errors logged despite of my trying to narrow down the error spot.
So, here's what we can try to confirm my theory. You could start VS w/o any project loaded, go to DPack options General page and disable 3 main browsers. It should be disabled but go ahead and restart VS just to be sure. Try your test and see if your Xaml files opens fine. If so, close the project, enable one of DPack browsers, restart and try it with that Xaml file again. I'd suggest start enabling it in this order: File, Solution and then Code Browser.
Also, try it with this new beta I've just posted. Just mainly has more logging and exception handling:
http://www.usysware.com/files/DPackSetu ... .0.0.8.exe (845Kb)
Why it happens on that single project baffles me though. Thanks for staying on it with me. You're a brave man.
