The ORM Foundation

Get the facts!

NORMA for VS2012 - Bug?

Last post 12-21-2013 15:03 by Ken Evans. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • 12-14-2013 16:42

    NORMA for VS2012 - Bug?

    Using NORMA for VS2012

    With an open model, VS2012 crashes when I select the "Model Note" feature in the ORM Toolbox.
    The debugger output is in the attached file.

    The "Model Note" feaure works OK using the same model in VS2010. 



  • 12-15-2013 2:41 In reply to

    Re: NORMA for VS2012 - Bug?

    Hi Ken,

    I'm not seeing it. Your debugger output is just the list of loaded Dlls. The last one (Microsoft.VisualStudio.Modeling.Sdk.10.0) is a little odd in Visual Studio 2012--you'll see the one NORMA is using (11.0) higher in the list, and the 10.0 version is typically used by Visual Studio 2010. It is possible something else you have loaded is pulling this in and causing a versioning conflict, but I find that unlikely.

    Have you tried a toolbox reset (right click on the toolbox and choose Reset Toolbox)?

    You'll have to get me a real call stack for me to have a chance on this one (the Debug tab in the Output window is not a call stack). I've posted directions on how to do recently.


  • 12-15-2013 6:53 In reply to

    Re: NORMA for VS2012 - Bug?

     Hi Matt,

    a) "Reset Toolbox" worked - but VS2012 took a long time about it (30+ Seconds +)

    b) The "VS2010" stuff appeared because VS2012 gave me an option of VS2012 or Vs2010 and I chose VS2010. 

    c) Now to the curious bit:
    Here are the debugging instructions that you gave to Jim Ludden a while ago: 

    1. Open a NORMA file in VS and get to the point right before you crash
    2. Open another VS instance
    3. Attach a debugger to the first instance of devenv.exe (.NET 4.0 for Visual Studio 2010)
    4. In the Debugging tab in the Tools/Options dialog, turn off 'Enable Just my Code'
    5. Open the Debug/Exceptions dialog and set the 'Common Language Runtime Exceptions' dialog to 'Break when Thrown'
    6. Continue working

    I had the same problem as Jim with step 5  (Could not see a "Break when Thrown" option.)

    So now I had the following situation.

    VS2012 Instance 1 - in debug mode with an object-role model loaded and showing on the drawing surface.
    VS2012 Instance 2 - open on a separate monitor.

    However, when I selected View>Toolbox in VS2012 Instance 1  - the ORM Designer toolbox did not appear.
    So I was not able to test the "Model Note" feature.

    When I stopped the debugger, the View>Toolbox command worked as expected. 



  • 12-18-2013 18:53 In reply to

    Re: NORMA for VS2012 - Bug?

    Ken Evans:
    "Reset Toolbox" worked - but VS2012 took a long time about it (30+ Seconds +)

    VS is loading all of the installed packages to reset the toolbox, not just the NORMA package. It takes a while.

    A backup option is to clear the NORMA user information in the registry editor by deleting the key at HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\ORM Solutions [use different numbers for different VS versions 8.0=2005,9.0=2008,10.0=2010, 11.0=2012, 12.0=2013]. This puts NORMA back in the same state as the first time it is launched and should reset all NORMA-related toolbox items. This is, however, a little more complicated than just executing 'Reset Toolbox'.

    Ken Evans:
    The "VS2010" stuff appeared because VS2012 gave me an option of VS2012 or Vs2010 and I chose VS2010.

    I don't know my way around VS2012 to know when or where you were given this option. Would you care to elaborate? Although the NORMA installation packages use different setup identifiers, they use all of the same identifiers in memory, so if you ever tried to load two versions into the same Visual Studio instance then your results are undefined.

    Ken Evans:
    I had the same problem as Jim with step 5  (Could not see a "Break when Thrown" option.)

    The issue is likely with the somewhat obscure (.NET 4.0 for Visual Studio 2010) comment in my instructions. In the Attach to Process dialog you'll see an Attach to: header on the left and a Select button on the right. NORMA is a managed code app, so you want to force it to attached managed code. You must choose the type of debugging you want to do before attaching to the process. For VS2005 and 2008, you need to check the Managed (v3.5, v3.0, v2.0) item. For VS2010 and higher you need the Managed(v4.5, v4.0) items. You cannot select both simultaneously.

    With this in place you will have two versions o fhte Debug/Exceptions dialog. When Enable Just my Code is turned on, you'll see columns called Thrown and User-unhandled. When just my code is off, you will see only a Thrown column. Check the box in the Thrown column for the Common Language Runtime Exceptions category.

    You should be able to verify these steps even if you have nothing to debug at the moment.

    Ken Evans:
    ORM Designer toolbox did not appear 

    It didn't appear with the designer selected? The ORM Designer items are collapsible. Is there even an 'ORM Designer' section showing at the top of the Toolbox window? Is it expanded or collapsed?


  • 12-19-2013 19:24 In reply to

    Re: NORMA for VS2012 - Bug?

     Hi Matt,

    Thanks for your extensive comments & apologies for my delayed response. (Caused by the time it took me to make the video!)

    I did not see the VS2010/VS2012 option this time.
    - probably because I used VS2012 for the second instance instead of VS2010 as I did on my first attempt.

    So the video shows:

    a) that the ORM Designer toolbox disappears when you select the debugger - and reappears when you stop debugging
    b) the long list of options that appears in step 5 instead of "Break when thrown".

    The agenda for the video is at the bottom of this post. 

    To see the video click here


  • 12-20-2013 21:04 In reply to

    Re: NORMA for VS2012 - Bug?

    Hi Ken,

    Thanks for the video. It makes it clear what is happening.

    The first problem is that you're attaching to the wrong VS process. You're trying to debug the process running NORMA, not the second VS instance your just launched. What you're actually doing is attaching the VS instance that is already running NORMA to the second, newly launched VS instance. You can see this in the process dialog because it shows the title for the main window of the process you're attaching to. You'll see 'start page' in there, which is not in the NORMA instance (the actually devenv.exe instance that you're in will not show in this dialog because you can't use a single process to debug itself).

    So, switch to the second VS process you launched to do the debugging, change all of your debug settings there, and attach it to the VS instance hosting NORMA if you want to debug the NORMA designer.

    The toolbox clearing out is normal behavior for all VS designers when you switch from edit mode to run mode (note the (Running) in the title bar).

    The second problem is that you didn't actually set the type of code you want to debug, as discussed in my previous response. The 'Attach to' line in your process dialog says "Automatic: Native code". You open the correct dialog to attach to managed code, but cancel out before you do anything. You need to pick the correct version of managed code (Managed (v4.5, v4.0) in this VS version). Note that if you attach the processes in the right direction and a NORMA designer is open, you might see the correct managed choice as the automatic choice. If not, you need to switch it. Debugging native code won't ever help you here.

    Third, in the exceptions dialog, you don't need to expand the top level headers. Just check the box beside the header throw all of them.


  • 12-21-2013 15:03 In reply to

    Re: NORMA for VS2012 - Bug?

    Hi Matt,

    Thanks for your guidance which I used to make this new video which shows my current understanding of the first steps of the NORMA debugging procedure. Please confirm that I have now got it right.

    Once we have a version of this video that shows the complete procedure, I will upload it to the Library for use by others as needed.

    Of couse, since you have done such a good job so far, I don't have a bug to use as an example of the complete procedure.

    So please will you:
    1: Describe the next steps that you would like people to take to report a bug if they find one (so that I can extend the video).
    2: Let me have some buggy code for use as an illustration in the extended video.


Page 1 of 1 (7 items)
© 2008-2014 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service