We use team foundation server as a version tool for our DSL projects. However, since the debugging project runs only in the hive mode and the tfs-plugin is not available in the hive, it is clumbersome to keep the debugging project up to date.

If the DSL is changed and you do not have the latest debugging project, then visual studio crashes during start-up if an old model was open the previous time the debugging project was used. The work around is to remode the model(s) from the debugging project, and to recreate them or to obtain their corresponding versions.

I think the editor should give an error in the format of a message but a crash is rather drastic. My question is if you can also add some clue about what is wrong. This improves the backwards compatibility in a sence that at least you can try to fix the xml manually.

Hi John,

Which CTP are you using?

If it's the June one, then this is a bug if a malformed model file can crash VS.

If it is June and you're able to get us a call stack by attaching a debugger to that exp version of VS that would be useful.

Hi Gareth,

It is the june version. Getting the stack isn't that simple, but i will do my best.

John

Usually this is caused by unhandled exception thrown back into VS's load code. When managed exception gets thrown into unmanaged VS code, it often crashes VS. In June CTP, the error handling of generated serialization code was not very good, so handled exceptions may occur; in recent builds, we've fixed few load issues and the next release should be better at handling bad model files. But to be safe, it'll help if you can get a call stack, or if you can send us your model with the bad model file.

To make it easier to get the callstack, you can do this: in the debugged project, delete the Debugging.suo and Debugging.csproj.user files. This will cause no file to be opened automatically the next time you open the debugged project. Then in the debugging project, turn on catching all exceptions, and you should be able to see if any exception is thrown when you try to open the model file (after the debugged project is loaded). Thanks!

Thanx Jing,

I followed your suggestions. The exception thrown is:

+ $exception {"Domain object with identity f5ea6659-0cc0-471e-aa01-e3e486c3dbd6 was not found in directory."} System.Exception {Microsoft.VisualStudio.Modeling.DomainDataNotFoundException}

The show call stack is rather empty:

[External Code]
> Ordina.WebScenario.Designer.DslPackage.dll!Ordina.WebScenario.Designer.Ordina_WebScenario_DesignerExplorerBase.FindRootElements(Microsoft.VisualStudio.Modeling.Store store = {Microsoft.VisualStudio.Modeling.Store}) Line 70 + 0x34 bytes C#
[External Code]

The exception's callstack contains more info:

The code in the generated file ModelExplorer.cs is:

/// <summary>

/// Returns the root elements to be displayed in the explorer.

///</summary>

protected override global::System.Collections.IList FindRootElements(DslModeling::Store store)

return store.ElementDirectory.FindElements(global::Ordina.WebScenario.Designer.WebScenarioModel.DomainClassId);

I' am about to determine if the id is really not there.

The id referred to the root element (which naturally exists). When i removed the content of the element and the diagram, i was able to load the (empty) model again.

There seems to be no reason why the exception was thrown.

Hi Jing,

That can not be the case, since the model is loaded normally by double click on the model in the solution explorer. There is no special loading algorithm written by me.

John