This release adds support to Visual Studio 2012 Professional to previous 3.5 release. 

 Where can you get it?

•  The Spec Explorer download can be found on the Spec Explorer home page on Visual Studio Gallery.
• See the on-line Release Notes for the latest, more detailed description of installation requirements, major features, bug fixes and known issues. Further information can also be found on Test Tools in Visual Studio 2010 and 2012 (The Spec Explorer Forum has been retired), The Spec Explorer Team Blog, and the latest Spec Explorer Help Documentation is always available in the MSDN library.
• Please note that Spec Explorer 2012 Release 3.5 runs only on Visual Studio 2012 and 2010. The 90 day trial version of Visual Studio can be found at here.

We hope you enjoy this release and look forward to hearing feedback from the Spec Explorer community.

The Spec Explorer Team

We can implement our own data loader to load data from external source, and use this loader to initialize the state. Note that since data loading method might involve native invocation, we’d better set our loader to native (more details can be found at https://msdn.microsoft.com/en-us/library/ee620483.aspx).

Here is an example:

Model.cs

using System;
using System.Collections.Generic;
using System.Text;
using System.Linq;
using Microsoft.Modeling;
using Microsoft.Xrt.Runtime;
using System.IO;

[assembly: NativeType(typeof(Sample.MyLoader))]
namespace Sample
{
    static class MyLoader
    {
        internal static Sequence<UserData> Load()
        {
            int i;
            UserData data;
            Sequence<UserData> dataSequence = new Sequence<UserData>();
            string[] contents = File.ReadAllLines("c:\\temp\\data.txt");
            for (i = 0; i < contents.Length; i=i+2)
            {
                data.Name = contents[i];
                data.Address = contents[i + 1];
                dataSequence = dataSequence.Add(data);
            }
            return dataSequence;
        }
    }

    public struct UserData
    {
        public string Name;
        public string Address;
    }

    static class ModelProgram
    {
        static Sequence<UserData> Data = MyLoader.Load();

        [Rule]
        static Sequence<UserData> ShowData()
        {
            return Data;
        }

        [Rule]
        static void Clear()
        {
            Data = new Sequence<UserData>();
        }
    }
}

Config.cord

using Sample;
using Microsoft.Modeling;

config Main
{
    action abstract static Sequence<UserData> Adapter.ShowData();
    action abstract static void Adapter.Clear();

    switch StepBound = 128;
    switch PathDepthBound = 128;
}

machine ModelProgram() : Main
{
    construct model program from Main
}

And the data under c:\temp

Lisa
#5, Danling Street
Bob
Queen Square

Then we explore the ModelProgram machine, and get the exploration graph like:

Of course the data source is not limited to text files, you can design your own loader to make your model more powerful.

Please feel free to share your thoughts or other good approaches to initialize initial state.

Spec Explorer 2010 Release 3.5

Hello!  We are delighted to announce the newest version of Spec Explorer 2010, Release 3.5.

Spec Explorer 2010 Release 3.5 contains new features, improved documentation, plus over 60 bug fixes. It runs on the Visual Studio 2010 Professional level product and above.

What’s New in Spec Explorer?

This release contains new / enhanced features including:

· Model change detecting:

The model change detecting feature detects all model changes and decides if Spec Explorer needs to re-explore the model. For specific machines, if Spec Explorer detects any change in the model code, cord script files, or other inputs, or detects a tool version change, Spec Explorer will start a new exploration; otherwise, Spec Explorer will use existing exploration result files for current exploration viewing, test code generation, and user customized post processing. The UI has been updated to allow you to force Spec Explorer to re-explore the machines.

· Multiple machine processing:

Now you can select multiple machines in Exploration Manager and explore, generate test code, or perform post processing tasks on them. For multiple machine processing, Spec Explorer generates a summary including all information of the batch-processing.

· Cord context menu:

Spec Explorer adds a new context menu item “Go To Definition” in the Cord editor, which enables users to navigate to specific configurations and machines. This is part of an ongoing effort to improve the Cord editing user experience and the general integration of the tool with Visual Studio.

Where can you get it?

• The Spec Explorer download can be found on the Spec Explorer home page on Visual Studio Gallery.
• See the on-line Release Notes for the latest, more detailed description of installation requirements, major features, bug fixes and known issues. Further information can also be found on The Spec Explorer Forum, The Spec Explorer Team Blog, and the latest Spec Explorer Help Documentation is always available in the MSDN library.
• Please note that Spec Explorer 2010 Release 3.5 runs only on Visual Studio 2010. The 90 day trial version of Visual Studio 2010 can be found at here.

We hope you enjoy this release and look forward to hearing feedback from the Spec Explorer community.

The Spec Explorer Team

Spec Explorer 2010 Release 3.4

Hello!  We are delighted to announce the newest version of Spec Explorer 2010, Release 3.4.

Spec Explorer 2010 Release 3.4 contains new features, improved documentation, plus over 50 bug fixes. It runs on the Visual Studio 2010 Professional level product and above.

What’s New in Spec Explorer?

This release contains new / enhanced features including:

• Dynamic traversal: Dynamic traversal provides a new test case generation mechanism. It works by traversing the exploration result (with a user-customizable strategy) while invoking the corresponding actions on the system under test at test runtime.
• Validation performance improvement: The performance of Cord validation has been greatly improved.
• Exploration cleanup: This enhanced feature provides a post-exploration process to remove redundant states/steps.
• Getting partial exploration result: If exploration time exceeds the value of switch ExplorationTimeout or you click the “Stop” button during exploration, a partially explored / cleaned-up result will be displayed.
• Model program construct from multiple namespaces / types: This feature allows a model program to be constructed from a list of comma-separated model namespaces / types.
• Fully-qualified-name support for static action invocations: Fully qualified names are used to distinguish different static action invocations with the same method name.
• Validation task in SpecExplorer.exe: New task “Validate” has been added as a task in SpecExplorer.exe

Where can you get it?

• The Spec Explorer download can be found on the Spec Explorer home page on Visual Studio Gallery.
• See the on-line Release Notes for the latest, more detailed description of installation requirements, major features, bug fixes and known issues. Further information can also be found on The Spec Explorer Forum, The Spec Explorer Team Blog, and the latest Spec Explorer Help Documentation is always available in the MSDN library.
• Please note that Spec Explorer 2010 Release 3.4 runs only on Visual Studio 2010. The 90 day trial version of Visual Studio 2010 can be found at here.

We hope you enjoy this release and look forward to hearing feedback from the Spec Explorer community.

The Spec Explorer Team

Hello again!  We are proudly announcing the newest version of Spec Explorer 2010, Release 3.3. The next step has been taken from being resident on DevLabs to being a Power Tool on Visual Studio gallery where you can find the new home page for Spec Explorer.

Spec Explorer 2010 Release 3.3 contains new features, continued improvement in documentation, plus over 100 bug fixes.

What’s New in Spec Explorer?

New features added in Release 3.3 include:

• On-The-Fly (OTF) testing: On-The-Fly testing provides a new means to use Spec Explorer to create and run tests directly from models (machines). In On-The-Fly testing, the selection and evaluation of model actions (including events) is alternated with execution by the System Under Test/adapter.

• Visual state search: This new feature in the Spec Explorer view enables the search for and highlighting of specific states.

• Probe logging: Newly provided recording of probe values in states enhances analysis of test logs.

• Test method customization: New control of test attributes in generated test code offers expanded support for other test frameworks in addition to the default one provided by Visual Studio.

Additionally, a Spec Explorer extension for UML is also being released at this time that is not included in the main Spec Explorer MSI and must be downloaded separately. Documentation for the UML extension can be found here.

Where can you get it?

• The Spec Explorer downloads can be found on the Spec Explorer home page on Visual Studio Gallery.

• See the on-line Release Notes for the latest, more detailed description of installation requirements, major features, bug fixes and known issues. Further information can also be found on The Spec Explorer Forum, The Spec Explorer Team Blog, and the latest Spec Explorer Help Documentation is always available in the MSDN library.

• Please note that Spec Explorer 2010 Release 3.3 runs only on Visual Studio 2010 Professional Edition or higher. The 90 day trial version of Visual Studio 2010 can be found at here.

We hope you enjoy this release and look forward to your help by feedback and community involvement to continue making Spec Explorer better and better.

The Spec Explorer Team

The Calculator

The core calculator model is a simple four function calculator. But infix calculators aren't entirely simple, because calculators demonstrate rich variations in outputs depending upon the exact order of input sequences of numbers, operations, and pressing the Equals keys. This implementation (and model) emulates the Windows Calculator. It is similar to but is slightly different from most store-bought calculators, especially in how the Equals key first repeats upon multiple key pushes and how an operation is done when only one operand has been provided. The model and implementation provided, however, should match up with the Windows calculator found under Accessories in the Windows Start menu. The Visual Studio 2010 solution for this example can be found here.

The Scenario

For the purposes of this sample, first the calculator functionality was created as a standalone product. This was then integrated with connection access that allowed the calculator to be used as a service. These were then modeled together as single integrated service. The calculator service model can be explored by itself and its implementation can optionally be tested standalone. The security authorization model controls access to the calculator via a simple minded Access Control List (ACL) consisting of a list of authorized users.  (Note that the full ACL target resources and operations were not of interest for testing purposes so were not modeled). This simplified ACL was modeled on its own and can be explored on its own. Testing the ACL implementation requires the calculator service only for its connection capabilities.

How the Two Model Program Rule Sets Work Together

The ACL (authorization) model and the calculator service model actually synchronize on only a few actions, specifically connection and disconnection. They interleave the rest. The two model programs use the |?| operator to achieve this.  Thus the authorization model can manage its ACL,  allow and release user authorization on its own, as shown by exploring machine AuthorizationSlice, while the calculator model independently can do all of its calculator functionality (actions and events) .  The vast majority of the all-important security related sequencing is done by transition modes in the authorization model. By carefully controlling when the synchronized actions (connect and disconnect) can occur the authorization model imposes the majority of inter-model sequencing constraints expressed by the joint model.  Internally within the calculator service, however, the rules are generally aware that they must be connected to be enabled but have no knowledge at all of the authorization rules.

The end-to end-control is shown, not surprisingly, by machine EndToEndControl (Slice and Test) in the Cord file. It specifies that between ACL creations and disposals, users can be authorized multiple times, and between multiple authorizations the current user can connect multiple times, and within a connection multiple operations can be performed.  This models the functionality of the core authorization sequences. Multiple simultaneous users and connections were not modeled. Had this been a test objective, likely instance based modeling would have been used and the implementation would be have been multithreaded. The current model (and the current implementation) adequately tests basic end-to-end functionality.

How the Implementation Does This

The implementation is written as four layers. The top level static class acts as the interface that implements the controllable and event actions declared in Cord. Thus it can be considered to be an adapter layer. The rest of the implementation is written as three layers, each of which is represented by a single object. There is an object that implements all of the calculator functionality, one that manages the connection to the calculator object, and finally one that represents the ACL control logic. In principle, the calculator object could be replaced by the real Windows calculator, but that has not been attempted.

Things to look for

In addition to modeling the active (behavioral) joining of two rule sets, this sample illustrates several important features of using Spec Explorer.

Cord

The Cord file is structured around logical groups of configurations, which of course is what configs are supposed to do for a living. The use of parameters in machines is shown by the DoubleOperand machine. The machines related to test purposes are built up from scenarios to model slices to test cases. For example,  BigLongScenario to BigLongSlice to BigLongTest. There are a number of helper machines such as FullStart, CloseDown, SingleOperation. Fairly rigorous testing of calculator key sequences is shown by all the scenarios that  are included in AllOperationsTogetherSlice (and Test).

But in many ways the most interesting machines deal with constructing and joining the two rule sets. The machine called AuthorizationSlice builds the (sliced) ACL model program and CalculatorService constructs the model program of the calculator service. These two model programs are actually independent of each other and use their own rule sets kept for convenience in separate name spaces and files. They make no assumptions about each other.

Machine JointModel is the one that joins the two by means of the partially synchronizing |?| operator, aka the “synchronized-interleaved parallel composition operator”.   This synchronizes when both machines try to produce the same action just like the parallel synchronization operator ||-- in this case the connection and disconnection related actions--but interleaves otherwise when either machine produces an action unique to itself, just like the ||| operator. It may be that |?| is one of the more underappreciated operators in Cord.  There are subtleties in its definition, but it is behaviorally powerful as shown.

Machine SimpleDirectSlice (and Test) deserves quick mention. If uncommented in CalculatorService.Connect (file Calculator.cs), the implementation will allow the calculator service to be tested on its own by automatically creating an ACL and authorizing a fictitious user. (The users defined for model slicing in configuration Authorize are neither fictitious nor necessarily innocent but that's another story.) This implementation short circuit would ordinarily be a security hole, since the ACL logic is being neutered, but is useful for testing and illustrates one way to get around the layering of the implementation code. Note that no changes were necessary in the CalculatorServiceModel rules to make this test generation work correctly because those rules by themselves do not depend on the ACL logic to which they are later composed only by the |?| operator

Model and Implementation Code

The model and implementation code is heavily commented and largely self-explanatory.  The model code uses helper functions extensively. In both the model code and the implementation, state data is initialized actively in a constructor or other method. This promotes consistency and successful re-running of the same code in a test sequence or between test case executions.

Note that a rule may be blocked from producing a step in a helper function such as in CalculatorServiceModel.RequiresConnected (in file ArithmeticRules.cs).  A rule method must reach all the way to an exit point without violating any Condition class constraints in order for any step(s) to be produced. Otherwise that rule execution is completely discarded during exploration and no step is produced outgoing from the current state by that rule.

In the same model rule set, the rule for the Divide action shows how a special condition, often an exception, can be converted into the expectation of a following event. Spec Explorer actions are indivisible which means they cannot suddenly be stopped and switched to another one. But at model evaluation time, the new state can reflect that a condition has occurred in the prior step (from a prior rule firing). In this case, the rule for OperationError will pick up on that fact that previously Divide had found and marked that the denominator was zero. A quick look at the configuration called Operation in Cord shows that the OperationError action is to be treated as an event. This is the only place to find out that the OperationError rule described an event, as it does not matter to the rule itself whether it is an input or output action to the SUT. Rather, the rule just knows under what conditions that the step can be seen externally to the SUT.  It does matter, of course, to exploration and test code generation both of which will treat the event appropriately (which is why the Cord code tells them).

The actual implementation of the OperationError event can be found in CalculatorService (in file Calculator.cs). Notice it requires an instance of the correct name (OperationError) of a correct kind of delegate type. In this case it happens to be called OperationErrorHandler, but the type name may be chosen at will. The event is actually raised in this sample by helper method CalculatorService.RaiseError which is a callback used by the calculator object if it encounters a problem with divide by zero. The event will be placed on Spec Explorer's run time event queue for future consideration and the Divide action will run to completion, returning a zero value if a problem occurred as tested by scenario DividebyZero in Cord. When the model indicated the event would be eligible for consideration the queue will be examined and in the two cases of the ZeroDivide scenario it will be found. The third case does not look for the event and shows that a test may conclude successfully in an accepting state even if there are events left on the event queue.

Part of the moral of this story is that controllable actions (that is, inputs to the SUT) in the implementation are simple methods, but observable actions  (that is, events) are implemented quite differently (as described above).  Whereas in the rules, such actions are indistinguishable.  And only in Cord, as the bridge in between, does Spec Explorer learn which is supposed to be which.

Actions

In the most general notion, an action describes an interaction with the System Under Test (SUT) as seen from the tester's (or test system's) perspective. Spec Explorer recognizes three kinds of atomic actions that are discrete and indivisible: events, call actions, and return actions. Events represent autonomous messages coming from the SUT. A call action represents a stimulus from the test system to the SUT (as originally decided in the model). A return action must always follow after a call action without any intervening actions. The return actions capture the response (if any) from the SUT.

For further reference see Actions in the on-line documentation.

Action Declarations

Actions are declared in Cord configs using definitions that are like C# signatures preceded by the keyword "action". Cord expects the target SUT assemblies, or the adapter assemblies that wrap access to the SUT, to provide the .Net code that corresponds to each action. Put another way, the code to implement actions ultimately belongs not to the model but rather to the implementation to be invoked at test run time only.

An action declaration in Cord is always one of two kinds: a synchronous action declaration, which is the default, or an explicitly stated event action declaration. A synchronous action declaration actually forms the indivisible pair of an atomic call action followed by the corresponding atomic return action. The target of a call/return pair is implemented by a single method in the SUT, or the adapter to the SUT. Tests generated from Spec Explorer models invoke these methods on the SUT, and block waiting for them to return.

Event action declarations describe a single atomic action that indicates the SUT has sent a message on its own in keeping with the .Net event model. Events are implemented as standard C# events in the SUT (or adapter). Tests generated from Spec Explorer models subscribe to these events and add them to a queue as they arrive. Events from this queue are consumed when the test reaches a point where one or more events are expected.

Action Invocations

In Cord the use of an action in a behavioral (regular) expression is called an invocation, e.g. Add(1,2)/3.  The arguments of an invocation can be variables or literals. Action invocation arguments, if specified, must always match in type and position with the signature provided by the action declaration in the applicable Cord config. Cord allows for polymorphic overloading of action declarations and Spec Explorer will chose the correct action declaration accordingly.

Note: action invocations do not directly call the implementation because they belong to the modeling. The implementation only becomes available at test execution time. Action invocations are also used to annotate rules, which are the other major part of modeling.

For further reference see Invocation in the on-line documentation.

Steps

Steps are the transitions in the graph. Step labels are action invocations that appear as transition (edge) labels in the exploration result graph.

At test run time, these step labels are translated into either method calls to the SUT (or adapter) that implement the call/return pair, or expected events. For call/return pairs, the generated test code will call the implementation (or adapter) method (call action step). The test code then will note the response with the actual out and result values given by the SUT (return action step). For events coming from the SUT (or adapter), all parameters will be considered as outputs. The actual values found at run time (for out parameters, results and event parameters) will be compared to the expected values from the model ("the oracle"). Only if these values meet all corresponding conditions will the test case succeed.

Like all behavioral modeling, Spec Explorer is ultimately interested in what can actually be seen in terms of inputs and outputs to the System Under Test (SUT), i.e. the actions. Everything else in Spec Explorer exists just to determine the legal sequence of steps (behavior) that a compliant SUT will be expected to follow in a test case. Even Spec Explorer's advanced notion of "state" is used only at modeling (exploration) time by a rule (see below) to determine if a particular step label would be permitted at that point in the sequence, but state does not partake in the actual test execution. Only step labels interpreted as invocations to the SUT (or adapter) and events are relevant to testing, as just described above.

Rules

Rules determine what steps can be produced leading from the current state in the model program. All rules are tried out by exploration from each state.

In Spec Explorer, rules are represented by model program methods that have been marked with the Rule attribute. The Rule attribute has an optional Action argument that specifies the action invocation.

Since rules exist to specify what steps the model program allows from a given state, the true output of a rule is zero or more step labels representing possible next actions from that state. Because of advanced features in Spec Explorer such as domains and parameter generation, it quite possible for a single rule to yield multiple instances of step labels for a given state. Of course a particular rule method always produces the same kind of step label in keeping with the Cord action declaration that matches the action invocation of its Rule attribute, but each step label will have a different combination of parameter values.

When a rule method is explored in order to generate step labels, the action invocation contained in its Rule attribute is used to map the exploration supplied input values to the rule method and to map back out/result values after the rule method has executed (as discussed below). A step label that cannot be produced by a rule due to violating a constraint in a Condition class method (e.g., Condition.Istrue) is simply discarded and will not appear in the exploration graph.

The action invocation in the Rule attribute is used to establish the correspondence between the Cord action declaration signature and the potentially different rule method signature in a way that is quite unique to Spec Explorer:

1. The name of the action invocation annotating a rule does not need to match the name of the rule method. It must however match the name of an action declaration in the Cord config that the model program is constructed from (e.g. "construct model from MyConfig").
2. Remember that action invocation arguments must always match in position and type compatibility with the corresponding action declaration signature in Cord.
3. If an action invocation argument is a literal value (for example, a number) it is not mapped at all to the rule method parameters! The rule method may simply assume what it wants when the action invocation parameter has that value without having to explicitly test for it.
4. If an action invocation argument is a variable rather than a literal value, it is mapped by name only, not by position, to the corresponding rule method parameter. If no such mapping is possible a validation error occurs. The type of the rule method parameter must agree with the corresponding type in the Cord definition. This includes the special names that can be used as action invocation arguments: "this" (represents the receiver of an instance-based rule method) and "result" (represents the return value of a non-void rule method). Note that the apparent return value of a C# rule method simply maps to the "result" output parameter.
5. All parameters of a rule method must appear in the action invocation annotating it. If one or more of the rule parameters do not appear in the corresponding action invocation, a validation error will result. This includes the special parameters "this" (for instance-based rules) and "result" (for non-void rules). For Example,

   In Cord:

   action abstract Sum(int x);

    

   In Model Program:

   static int stateTotal;

            [Rule(Action = "this.Sum(op) / result")]

      int AddtoTotal(int op) {

      return stateTotal += op;}

6. If the Action keyword is not specified in the rule annotation (e.g. "[Rule]"), Spec Explorer will automatically construct an invocation based on the rule method signature. The method name of the rule will be used as the action name (which must then match an action declaration in the corresponding Cord config), and the method's parameter names will be used as the action invocation parameters. For example, if the method signature is "int MyMethod(string name, float age)", the constructed action invocation will be "Action = "this.MyMethod(name,age)/result".

Summary: The action invocation in the Rule attribute must match in type and position (but not necessarily in name) the signature of the Cord action declaration. Rule method parameters must match the action invocation in the Rule attribute in name and type, but not necessarily position.

An Example

  Action Declaration in Cord:

action abstract static bool Login(string user,int securityLevel);  

Rules in the Model Program

1. The rule for a power user at security level 1 to login successfully (if unknown user, the rule itself fails, i.e. the action label will not be produced).
2. The rule for a power user at security level 1 to login unsuccessfully (if unknown user, the rule fails).
3. The rule for a normal user at any other security level allows login only if the user is already known and legal security levels also must be a positive integer value.

public static class MyModel

{

    static bool loggedIn; // State variable for Login status

  static string userName; // current user id with prefix

  static int securityRing; // current security level

  static Set<string> PowerUsers; // Level 1 people (initialized elsewhere)

  static Set<string> NormalUsers;// Normal users (initialized elsewhere)

// Rule for successful login at security level 1

[Rule(Action="Login(userId, 1) / true")]    

static void LoginLevel1Worked(string userId)

{

  Condition.IsTrue(PowerUsers.Contains(userId)); //Unknown-step fails

  userName="P."+userId; // Step possible; add Power User Prefix

  securityRing=1;       // Assumed due to Action label

  loggedIn=true;        // Already know this login is good

                        // result==true assumed due to Action label

}

// Rule for failed login at security Level 1

[Rule(Action="Login(string userId, 1)/ false")]

static void LoginLevel2Failed(string userId)

{

  Condition.IsFalse(PowerUsers.Contains(userId)); //Unknown-step fails

  loggedIn=false; // Still in rule; so assumed due to Action label

  securityRing=0; // Logged out default state values

  userName="";

                 // result==false assumed due to Action label

}

// Rule for login attempt at any level except security level 1

[Rule(Action="Login(userId, securityCode) / result")]

static bool LoginNotLevel1(string userId, int securityCode)

{

  Condition.IsTrue(securityCode > 1); // Rule only for legal non-level 1

  if (NormalUsers.Contains(userId)) // Step OK; check if user known

  {

  userName="U."+userId; // User known, so login succeeds

  securityRing=securityCode;

  loggedIn=true;

  }

  else // User unknown, so login fails

{    

  loggedIn=false;

  securityRing=0;

  userName="";

  }

  return loggedIn; // result == returned value

}

}

Rob DuWors

Hello!  We are delighted to announce the newest version of Spec Explorer 2010, Release 3.2.

Spec Explorer 2010 Release 3.2 contains new and enhanced features, improved documentation, plus over 110 bug fixes. It runs on the Visual Studio 2010 Professional level product and above.

What’s New in Spec Explorer?

This release also contains new features including:

• New Model Wizard: The new Model Wizard conveniently consolidates solution and project creation by unifying the previously separate Spec Explorer Model Project and Spec Explorer Base Solution templates.

• Choice API: The new Choice feature has been added to assist support where the System Under Test may provide one of several compliant responses to a single action. While Spec Explorer previously supported such non-determinism the new feature makes it simpler to model.

• SpecExplorer.exe: The automation version of Spec Explorer has been updated to support the newest standard format for exploration results and to provide better automation support for custom-written post processor extensions.

• Improved Documentation: While continuing to improve the overall quality of the Spec Explorer documentation the description of the Cord Scripting Language has been extensively revised in particular, and every page of the documentation now has a version header to clearly indicate the version of Spec Explorer that the documentation describes.

Where can you get it?

• The Spec Explorer downloads can be found on the Spec Explorer home page on DevLabs.

• See the on-line Release Notes for the latest, more detailed description of installation requirements, major features, bug fixes and known issues. Further information can also be found on The Spec Explorer Forum, The Spec Explorer Team Blog, and the latest Spec Explorer Help Documentation is always available in the MSDN library.

• Please note that Spec Explorer 2010 Release 3.2 now runs only on the released version of Visual Studio 2010. It does not work with Beta 1 or 2 or the Release Candidate versions of Visual Studio 2010, nor with Visual Studio 2008. The 90 day trial version of Visual Studio 2010 can be found at here.

We hope you enjoy this release and look forward to hearing feedback from the Spec Explorer community.

The Spec Explorer Team

The training is long (about 8 hours), but we have split it for your viewing convenience into 4 lectures (sessions). Each session has in turn 4 parts.

Session 1 Session 2 Session 3 Session 4

Caveat: The quality of the screen captures makes them hard to read. These videos will be replaced with new ones recorded with a better quality in the future. Please, forgive any inconvenience this might cause you.