Category Archives: Developer

Information for those developing systems or software using EA

Global replace leads to EA Installation Inspector V2

For the first time in so many years of using EA I had the need to do a global text search and replace – one of my clients wanted to rename something!  Now I knew that EA did not provide anything as standard, however a quick look on the sparx community site to find an addin from Helmut Ortmann that does just want I needed – ho_Replace.  I was set and my task was done within minutes – thank you Helmut.

However, as you can probably guess it didn’t stop there.  As reading on the download page there was a comment regarding a problem with installing the tool.  Although I had installed without a problem I thought I’d run my Installation Inspector to check the entries only to discover it wasn’t listed. So how does EA know about it?

I quickly discovered that EA not only looks for AddIns declared in HKCU\Software\Sparx Systems\EAAddins, but also in HKLM\Software\Wow6434Node\Sparx Systems\Addins, a location my tester wasn’t checking.  So to help those looking for these extra AddIns I’ve modified the code, which now checks both HKCU and HLKM locations.

EA Installation Inspector V2 Screenshot

EA Installation Inspector V2 Screenshot

Also, as I often find that the line is longer than the screen I’ve added a pop-up form which displays the detail for a single entry, making it much easier to read.

EA Installation Inspector V2 Pop-Up

EA Installation Inspector V2 entry detail Pop-Up

For those who have downloaded already may be worth updating to ensure you can see the other stuff.

I’ve also been thinking about adding a facility to change the target DLL file – not least as I find that during testing of existing installed AddIns with VS it doesn’t update the DLL location as required.  Is this something of interest to others? Are there other functions that would help when developing/testing AddIns?

I have updated the entry on the sparx community site – where you can download this new release.

Adrian

Advertisements

End-to-end development with EA – Part 1

Spurred on by the information from last weeks EAUG meeting that Sparx use EA to develop their own code rather than the traditional IDE’s, I really thought it was about time to check out how much of an end-to-end development can be done within EA, and in particular when I had to dip out and use other tools.  An experiment that has been on the list for so long that I thought I’d spend a few hours to  just take a look, and see what I could do in that time.

Summary

As described below, the outcome of my brief experiment has been to develop code, build and debug two very simple applications – a console “hello world” type application and a windows form application. The only task that I wasn’t able to do within EA was the creation of the MSBUILD project files.  It may be that this can be done – but not clear from the documentation – so one of the investigations for part 2.

NB: The experiment has been to check out the process rather than write some outstanding code, so both applications are trivial and the code illustrated does not include any error checking not has it been thoroughly tested!

Before proceeding it is assumed that the reader is familiar with EA and I will only be highlighting stuff that is particularly pertinent.

Building a simple console application

The steps involved were:

  1. Create a package – in which to locate the relevant element (I also created a working diagram on which to put classes and scribble notes)
  2. Create a class – which had to i) be stereotyped “Module” and ii) have a method Main()
  3. Generate the code from EA – (Select the class and press <F11>)
  4. Edit the code – in my case adding a MsgBox (code illustrated below)
  5. Create a Build script within EA’s Execution Analyser
  6. Create a Debug script within EA’s Execution Analyser

Of course, in doing this there are some important points to note – it is very easy to miss something small and spend an age looking for the problem (well that’s software)

So I’ll now go through the steps, outlining some of the important, but not all the details.


Creating the “Hello main module”

This is simply a class (stereotype <<module>>) with a single operation (Sub Main).  When created you generate the code using the code engineering | generate code  (<F11>) – ensuring that you set the language (VB.NET) and a suitable path.

Then open the source file (F12) and edit the code – this is what my trivial application looks like:

Public Module Hello
Public Sub Main()
MsgBox("Hello, World!") 
End Sub
End Module

The Build Script

To be able to build the code in EA you will need to create a suitable build script.  There are in fact a few steps involved here which I will cover. Within EA this is under the Analyser section  – to access the Execution Analyser (shift + <F12>)

Using the Execution Analyser I added a package script to my package and configured the build commands – see screenshot below (detail also provided later where you can see the full line) :

In some more detail there are a few things to note:

  • The default directory uses an alias – this is configured in the “Settings | Local directories and  paths” – the screenshot below illustrates the setting for this alias.

This is really useful for keeping the paths portable, however I have learnt that the path for the source files are hardcoded into the element (“Genfile”) and so it is essential that you set up the alias before you do your code engineering.  Of course, if you import source code I don’t think it does a substitution of the path with an alias on import so the “Genfile” field may needed editing (something I should probably check as I’m not sure of all the rules).

The detail of the script in my example is:

call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat"
msbuild Hello.vbproj
  • The 1st line sets up the environments for the build tools – I just used the Visual Studio (VS) environment batch file, which is probably over the top in terms of what is needed but is quick!  This file may be in a different location on your machine – so check before assuming where it is!
  • The 2nd line builds the VB project using the project file which I had to generate outside of EA – see below – the location of this file is in the default directory.

Creating the MSBUILD Project file

There are three ways of building the (VB) code.

  1. Use the VBC compiler directly – this worked fine but when thinking about creating larger projects I anticipate that it may get a little complicated, so shelved it.
  2. Use the VS solution file – my thinking is that if you are using VS (devenv) then why use EA for your development.
  3. Use MSBUILD – this provides the richness needed to build larger applications in a structured manner whilst remaining clear of VS, so the selected solution.  MSBUILD is a very powerful tool – I’ve spent many hours exploring its capabilities and can say that it’s not for the faint hearted, but then again once configured for a specific setup it can be edited for a wide range of applications.

Below is the project file for the example for my Hello console app:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>
    <ProductVersion>
    </ProductVersion>
    <SchemaVersion>
    </SchemaVersion>
    <ProjectGuid>{335417AA-BED0-4434-9E63-59AC5DDD365B}</ProjectGuid>
    <OutputType>Exe</OutputType>
    <StartupObject>Hello.Hello</StartupObject>
    <RootNamespace>Hello</RootNamespace>
    <AssemblyName>Hello</AssemblyName>
    <FileAlignment>512</FileAlignment>
    <MyType>Console</MyType>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
    <PlatformTarget>x86</PlatformTarget>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <DefineDebug>true</DefineDebug>
    <DefineTrace>true</DefineTrace>
    <OutputPath>bin\Debug\</OutputPath>
    <DocumentationFile>Hello.xml</DocumentationFile>
    <NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
    <PlatformTarget>x86</PlatformTarget>
    <DebugType>pdbonly</DebugType>
    <DefineDebug>false</DefineDebug>
    <DefineTrace>true</DefineTrace>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DocumentationFile>Hello.xml</DocumentationFile>
    <NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
  </PropertyGroup>
  <PropertyGroup>
    <OptionExplicit>On</OptionExplicit>
    <OptionCompare>Binary</OptionCompare>
    <OptionStrict>Off</OptionStrict>
    <OptionInfer>On</OptionInfer>
  </PropertyGroup>
  <ItemGroup>
    <Import Include="Microsoft.VisualBasic" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="hello.vb" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.VisualBasic.targets" />
</Project>

The easy way to get started, other than copy the above – making sure you change the GUID and filenames etc … – is to create a simple VS project and use this as a starter.  You will then need to remove stuff that is not required or relevant to a basic build.  In fact I used VS to create the initial Property Groups, and now just reuse these for many projects – BUT don’t assume you can ignore it as if you make changes to the type of application you are generating they will need changing!  Worth noting that the Property Groups define the output files – and so are relative to the root location in this example.

The rest of the file will needs reviewing / modifying to reflect the specific application for example the ItemGroups with the imports and Compile and the key files.

If you are moving out of the safety of VS then you really need to spend the time learning about MSBuild. I have made numerous notes during my days of learning – although it was similar to tools I used in the distant past it’s different!


Building the “hello” application

Having configured the build script and called project file, building the application is initiated by selecting (checkbox) of the desired package script and using the Execution Analyser Build command (Ctrl + Shift + F12) – see screenshot below

Assuming all has been configured correctly then you should see a “Build succeeded”
message in the “System Output | Build”  tab – if not at least there should be some messages that could help resolve the problem.  In my case, a simple typo!

Setting up the Debugger

Although my example application does very little, it is instructive to run the debugger to check out the process.

To use the debugger a script will need to be configured within the Execution Analyser.  Selecting the appropriate package script and make the relevant additions under the Debug section as outlined in the screenshot below (but with you alias, paths, executable)HelloWorldDebugScript

The following must be set:

  • Required debugger – e.g. Microsoft.NET
  • Default directory – this is set to the root of my code tree
  • Application path – path from the “Default directory” to the application AND including the application file name e.g. Hello.exe

Debugging your application

With the code built and the debug script configured it is simply a case of setting breakpoints and starting the debugger.

Open the required source file (e.g. Hello.vb) and set a break point by simply clicking on the grey left hand border at the desired line (a red dot should appear).

Then press <F6> to start the debugger.

The EA debugger operates in a similar, but different, manner to the MS debugger, so beware that shortcut keys are different.  And there you are the application that you have code and built within EA is now running.

It is worth noting that the execution analyser has some really useful features that can be used with the debugger some of which I have covered in a previous post  and in which I list other information / tutorials that I found useful.


Extending to a windows application

Having got a basic console application working the next test was to check out the generation of a windows application.  For this example, I planned to use MS Windows form library and create the form/controls programmatically – no wizards/VS type tools involved.

To test the capability I added a simple create form function – see commented code below – to my Hello.vb code, and made a call to the code in the “Main” function.

    Public Sub CreateMyForm()
        ' Create a new instance of the form. 
        Dim form1 As New Form()
        ' Create two buttons to use as the accept and cancel buttons. 
        Dim button1 As New Button()
        Dim button2 As New Button()

        ' Set the text of button1 to "OK".
        button1.Text = "OK"
        ' Set the position of the button on the form.
        button1.Location = New Point(10, 10)
        ' Set the text of button2 to "Cancel".
        button2.Text = "Cancel"
        ' Set the position of the button based on the location of button1.
        button2.Location = New Point(button1.Left, button1.Height + button1.Top + 10)
        ' Make button1's dialog result OK.
        button1.DialogResult = DialogResult.OK
        ' Make button2's dialog result Cancel.
        button2.DialogResult = DialogResult.Cancel
        ' Set the caption bar text of the form.   
        form1.Text = "My Dialog Box"

        ' Define the border style of the form to a dialog box.
        form1.FormBorderStyle = FormBorderStyle.FixedDialog
        ' Set the accept button of the form to button1.
        form1.AcceptButton = button1
        ' Set the cancel button of the form to button2.
        form1.CancelButton = button2
        ' Set the start position of the form to the center of the screen.
        form1.StartPosition = FormStartPosition.CenterScreen

        ' Add button1 to the form.
        form1.Controls.Add(button1)
        ' Add button2 to the form.
        form1.Controls.Add(button2)

        ' Display the form as a modal dialog box.
        form1.ShowDialog()

        ' Determine if the OK button was clicked on the dialog box. 
        If form1.DialogResult = DialogResult.OK Then
            ' Display a message box indicating that the OK button was clicked.
            MessageBox.Show("The OK button on the form was clicked.")
            ' Optional: Call the Dispose method when you are finished with the dialog box.
            form1.Dispose()
            ' Display a message box indicating that the Cancel button was clicked. 
        Else
            MessageBox.Show("The Cancel button on the form was clicked.")
            ' Optional: Call the Dispose method when you are finished with the dialog box.
            form1.Dispose()
        End If
    End Sub 'CreateMyForm

To build this code required a few additions to the project file to import the relevant windows libraries within the relevant ItemGroups as illustrated below:

  <ItemGroup>
    <Import Include="Microsoft.VisualBasic" />
	<Import Include="System" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="hello.vb" />
  </ItemGroup>
    <ItemGroup>
    <Reference Include="System.Drawing" />
    <Reference Include="System.Windows.Forms" />
  </ItemGroup>

With those modification done it was a case of rebuilding the application (ctrl + shift + F12) and then it is all ready for debugging.

It was as easy as that.


Conclusions

This simple experiment has illustrated how to build both a console and a windows forms application using EA as the build and debug environment.

So here are some of my observations to date:

  • EA provides a framework into which the design, analysis and development can exist – a real plus in keeping information aligned
  • The VEA analyser has some really useful stuff – and I can imagine that this will be really useful with some checking out complex projects
  • For those not used to writing project files it may not be suitable, certainly not for the faint hearted – I’ve written quite a few and still don’t get it correct 1st time (or 2nd…) but the I’m also of an age when I am used to getting involved in the grubby details of compiling, linking and all that command line stuff from the 70’s – age does have some benefits!

Things I will explore/review

  • Could I manage the build project files with EA – using the “Tools | Customize” options I have included Notepad++ so can just jump to the editor from EA – perhaps that’s good enough but does leave the build files outside of EA (in the same way that the source files remain external once generated… )
  • The feasibility of doing end to end development with much larger and complex programs – it may be great for team working or not, how does it compare with other tools – I’ve used the analyser with a large AddIn and it worked fine if a bit slow, and I’m sure that there is more to explore here
  • In a broader sense the ability to tie in all the testing and extend the end point to support on going maintenance – with the aim that all the information throughout the lifecycle could be kept in an EA repository.  Is that realistic?  Is that desirable?
  • The ability to generate the windows form dialogs from EA – to date I’ve written my own libraries that convert an EA UI form to windows forms/controls – does EA hold any secrets that would streamline this process

So in wrapping up.  Although with these initial tests EA works I’m not sure how practical it will be, not least if you are tied to other tools it is always difficult to change unless there is a compelling reason to make the change.  For example, I can see that if you are working with client based applications then the VS wizards are useful.  Also if you like the features of edit and run mode that can operate with the VS debugger this is another difference.  But I think this is only the start and I’m keen to understand more.

So the questions that probably needs to be asked is  “Does EA have some really compelling features that would make a change from Visual Studio or similar IDE’s to EA as the development platform?”

With that thought I’ll publish this post.

There is so much more to Tagged Values than I thought

For years I’ve used the tagged values within EA.  However, for some reason I have always assumed that they were just used for strings and a few other basic types for storing numbers.  However,  this is not the case.  As I was reviewing the user guide for some related information the other day, I was surpised but delighted to discover that there is so much more, with support for a much wider range of tagged value types, with some really useful functionality.

Without repeating the detail (that’s in the manual – “Tagged Value Types”) the support for types goes way beyond the basic string, integer and other number formats to much more complex and functionally richer items including:

  • String based items (Directories, Filenames, URLs)
  • Date
  • Selection from Pre-defined reference data e.g. Authors, Phases, Roles
  • Reference to element or elements within the model
  • Checklists
  • Custom Tagged Value types that are defined using a template and can help validate data entry
  • and finally the ability to use an “AddIn” to respond to the tagged value broadcast event and hence provide an open ended ability to interprete what is stored, the actions etc

For these complex types suitable context sensitive dialogues are presented to support the setting of the tagged value.  Furthermore, each of these types can be set to apply to element types and/or stereotypes – the screenshot below illustrates a range of different typed tagged values for an element; in this case a class.

Examples of typed tagged values

Creating tagged values can be done using the “Settings |UML Types | Tagged Value Types” – remember to check the syntax in the user guide for specifying the “Type” , “Values”,  etc – the following screenshot illustrates a tagged value that will reference a Requirement element which has a stereotype “test”.

Creating a new typed tagged value

Typed tagged values can also be created through templates or MDG – so a bit more reading to do on this when I need to use them.

As Tagged Values are stored as reference data they can be exported to /imported from other model. The screenshot below illustrates the menu selections used to export the data –  note that a further dialog will appear where you select “UML Types | Property Types”Menus to export reference data

Now of course with this new knowledge I can immediately think if only I’d known about these before.   In particular, in setting up a model for a project I’ve found it useful to preset tagged values to ensure consistency, and the wider range of types would have been really useful.  Plus the ability to use an AddIn provides a means to “validate” actions, and much more.

Well this new found discovery just highlights how much exists within EA.  And in case you haven’t clocked all this stuff before – check out the user guide section on “Tagged Value Types” – really worth a read!

Results from my initial experiments of coding from EA

I’ve had a successful and interesting play with starting to use EAs code engineering capabilities with a particular focus on using the Analyzer.  So before I forget some of the interesting stuff I’ll jot down some of my observations that may be of use to others going down the same route.

Running the demos

With anything new it makes sense to start with the examples that are provided by the vendor as one would hope that:

  1. They work – and there is a good feel factor encouraging more use of the tool
  2. Illustrate some of the good stuff that the tool – once again enhancing its value

So what have I done over the last week:

  • Worked through some of the VEA examples (C++ native and C# .NET) – build, debugged and analyzed
  • Tested the analyzer with a simple VB.NET windows application
  • Tested the analyzer with an EA Add-In with EA – and that was really magic

So I’ll go through my observations in turn:

Before you start

Checked out the product demonstration videos:

Get the resource booklets:

NB: Sparx have tutorials, white papers, resource booklets – all with good information but in different places on their website so often not easy to find!

And don’t forget the Help and/or user guide to check details (most problems arise as some of the detail is missed!)


Working through some of the Sparx examples

I started by viewing the webinar and then aimed to work through the VEA booklet to test the examples provided.  I was already familiar with basic code engineering both forward and reverse engineering of code, having used this before to either produce a basic source file from the classes I had developed or capturing information from existing code to aid with its documentation.  Hence, I assumed it would go smoothly and I must say that most worked as expected.  So what were the Gotcha’s:

  • Location of source code –  If you import the source code and then subsequently move the code the link between the source and model is lost, hence when you try to view the source code it’s no longer there.    This is because on the initial source code import EA stores the filename in the field “Genfile” of the class as a static value i.e.. is not updated.  The answer is either to reimport the code (something that can lead to a bit of a mess unless you are careful – I know!) or modify Genfile directly to reflect the new location – may be worth including an alias (ID) in the path which can be modified if the code is moved again.  I did the later and used eaDocX to facilitate the work by outputting the relevant classes and their GenFile field to a spreadsheet, editing the GenFile path and importing the modified worksheet and thus resolving the issue.  Clearly the easy option for avoiding this situation is not to move the source code after you import.
  • Don’t forget spaces in pathnames can be an issue – when setting up any local directories it could be that spaces are present in paths – beware as when VEA runs a script it should be considered  as a command line operation and be formatted correctly within quoted (“) strings e.g. “%MSVS%\devenv.com”, otherwise the command is not recognised by the command line interpreter correctly.
  • Failure to build – having got the source code linked and set up the “Local directories” to set the IDs used in the examples (VEA for the source code files and MSVS for devenv.com) I thought it would all just work, wrong!  The short story is that on some operating systems (in my case Windows 7) User Access Control (UAC) operates which means that some applications require administrator priveleges to run, one of these being devenv.com.  So with EA running as a normal user on my system, when I initiated the build the return status was OK however nothing happened.  By setting EA to run as administrator (if unsure how to change see EA help for information) it all just worked as per the video (it took me a little while to get here because I assumed that I would be prompted as and when needed – I wasn’t!)

So no groundbreaking issues but a bit frustrating – so with that done I was able to explore the VEA examples.  I could use EA as my debugger, able to access normal features of an IDE such as breakpoints, variables etc with the added options such as recording information that could subsequently be converted into sequence diagrams (just remember that EA uses F6 not F5!! )


My own test application

The next check was to build and test a simple windows application of my own (in VB.NET) and see how that worked.  Basically no real problems:

  1. Created a simple windows application in VS-2010
  2. Create a package and imported the source code
  3. Created build and debug scripts
  4. Tested – OK
  5. Adding a new class within EA and generating/editing code from EA worked however the source file wasn’t added to the VS project file so needed to edit this manually (could have done by switching to VS but wanted to see what can be done within VS)
  6. Tested – OK

There is a short write up of this as a PDF if you are interested: – HowToBuildASimpleApplicationToUseWithTheVEA


Testing an EA AddIn

As my day job often involves writing AddIns I was curious to check out if and how EA could be used to test an AddIn.  Not least would it help with

  1. Checking my code flows etc
  2. Producing better documentation to help with ongoing support

I was pleasantly surprise when this worked.  Although I did experience and I am still exploring a couple of issues with building my AddIn from within EA (I don’t think this is an EA issue), the debugger worked fine.

I configured the debug script as illustrated in the screenshot below.

Debug Script For EAAddIn

Debug Script For EAAddIn

So to run a debug session:

  1. Ensure that there are no instances of EA running
  2. Start an instance of EA (lets call it EA1) and open the AddIn model with the scripts, source code, etc
  3. Check the process ID of this instance of EA –  (I used the Process monitor within the sysinternals suite to get the process ID and monitor my system) – EA1 – it should be the only instance running.
  4. Run the testing instance of EA(EA2) and take a not of its Process ID
  5. In the Model instance of EA (EA1) start the debug script which will want to “Attach to process”
  6. When requested select the EA process with the process ID for EA2
  7. You are all set to start setting breakpoints, recording information to produce sequence diagrams etc

Worth remembering that the execution of your AddIn will be very, very much slower than normal, so factor this into any tests you propose (often time to get a cup of coffee when doing a run!) i.e. small tests only.


What next?

So a pleasingly successful result from my initial tests. I now want to explore the analyzer further – probably back to re-reading the booklets and check out what I’ve missed and what I’ve still to do.  I do know that I want to:

  • Get the Profiler working with a .NET application – so far it worked for native applications but not for my windows app etc
  • Test the use of the simulator and see how I would use this in my work
  • Review the various diagram generation options with a view to understanding how they would help with documenting my applications
  • Look at making changes to the applications from within EA and understanding limitations etc e.g. when adding a class, sync the code, management of the project file..
  • Explore what the VS MDG offers
  • And of course explore using with other languages – Java – this may be some time off yet!

So until next time have fun with EA

Using EA to debug an EA AddIn

Resolved all my initial VEA configuration issues and very pleased to have got going, not only with exploring the Sparx demos, but also with my own applications.

Testing an EA AddIn

As my day job often involves writing AddIns I was curious to check out if, and how EA, could be used to test an EA AddIn.  Not least as it would help me with

  • Checking my code flows etc
  • Producing better documentation to help with ongoing support

I was pleasantly surprise when this worked.  Although I did experience and I am still exploring a couple of issues with building my AddIn from within EA (I don’t think this is an EA issue), the debugger worked fine.  The key thing to remember is that one instance of EA is running as any other application that could be debugged, in this case from another instance of EA.

So the first step is to configure the Debug setup within the Execution Analyzer.  The set up I used is as illustrated in the screenshot below – the key point is that the debugger will need to “Attach to process” – this will be the EA instance in which the AddIn will be running.

Debug Script For EAAddIn
Debug Script For an EA AddIn

So before we start there will be 2 instances (EA Processes) of EA running.

  • EA1 – which will be the instance that is running the Analyzer
  • EA2 – the instance in which we will run the AddIn under test

So to run a debug session:

  1. Ensure that there are no instances of EA running – ensures that you don’t get mixed up with the different process
  2. Start an instance of EA (this will be) and open the AddIn model with the scripts, source code, etc for the Execution Analyzer
  3. Check the process ID of this instance of EA –  (I used the Process monitor within the sysinternals suite to get the process ID and monitor my system) – Note: EA1 should be the only instance running.
  4. Start another instance of EA(EA2) that will execute the AddIn and take a note of its Process ID
  5. In the Model instance of EA (EA1) start the debug script which will want to “Attach to process”
  6. When requested select the EA process with the process ID for EA2
  7. You are now in a position to debug your AddIn using the EA1 instance – using source code and setting breakpoints, recording information to produce sequence diagrams etc

With respect togetting it going that’s all I needed to do – the next steps are down to the developer and what information they seek to find.

It is worth remembering that the execution of code using the Analyzer is very, very much slower than normal.  First time I didn’t think and it took ages to capture information for my AddIn.  So it is important to be selective about the areas in which you are working and the information you are trying to capture. At least there is probably time to get a cup of coffee when doing a run!

Have fun

Adrian