Visual Studio and MxSuite

When you start a new version of MxSuite, the following dialog box is displayed:

Click Yes to set the Visual Studio options to the installation folder of the version of the MxSuite that is starting. See below.

You can also use this procedure to set the necessary Visual Studio properties.

1.Be sure all instances of Visual Studio are closed.

2.Start MxVDev or MxTransIt from the Windows Start menu.

3.Select Help->Set as Current Version from the MxVDev or MxTransIt main menu.

The Visual Studio properties are set to the installation folder of the version of the MxSuite that is running. See below.

You can view the current settings in Visual Studio by selecting View->Property Pages and using the dialog box shown below. (For older versions of Visual Studio, see below.) Changing the VC++ Directories options from inside Visual Studio is not recommended; use the Set as Current Version command as described above.

All three VC++ directories must point to the same MxSuite version, for example:

Executable Directories: C:\Program Files\MxSuite 3.36.17.26140\MxVDev\bin

Include Directories: C:\Program Files\MxSuite 3.36.17.26140\MxVDev\Harness\include

Library Directories: C:\Program Files\MxSuite 3.36.17.26140\MxVDev\Harness\lib

Changing the VC++ Directories options from inside Visual Studio is not recommended; use the Set as Current Version command as described above.

Options in Visual Studio 2005 and Earlier

1.Launch MxVDev.

2.Open the MxVDev project. This starts the MxVMC and opens a window such as this:

3.Launch MSVS.

4.Open the MSVS solution or project.

5.Select Debug‑>Attach to Process from the MSVS main menu. (In MSVC 6.0, select Build‑>Start Debug‑>Attach to Process.)

6.Click the Select button and select Native.

7.Select MxRTE.exe and click the Attach button.

8.Set any desired breakpoints in Visual Studio.

9.In MxVDev, click to run the test.

1.Launch Visual Studio.

2.Load the solution or project.

3.Select Debug->Exceptions or Debug->or Exception Settings from the MSVS main menu. Ensure that all boxes are checked. (Note: If this command is not available, you can add it using Tools->Customize. Refer to Visual Studio documentation.)

4.Ensure the project's Command property is set to MxRTE.exe.

a.Select the project in the Solution Explorer:

b.Select Project‑>Properties from the MSVS main menu.

c.Select Configuration Properties>Debugging in the left panel.

d.Ensure that the path in the Command property is set to the version of MxRTE.exe that you are using for testing.  For example:
 
C:\Program Files\MicroMax\MxSuite 3.34.47.25054\bin\MxRTE.exe

e.Enter the relative path for the MxV project under Command Arguments. (Usually "..\..\MxV.mxp"). The path is relative to the Visual Studio Output Directory, which is specified in Configuration Properties>General.

f.Set Debugger Type to Native Only.

g.Click OK.

5.Press F5 to start debugging.

Often a tester is given packages of source code where the modules are split between multiple directories (typically sorted by subsystem or functionality). When you compile these for your ECU, the make file or build script should ensure all of the modules know all of the locations to look for header files. When you first import the source modules into Visual Studio to create a VMC, this information is not necessarily retained. To save time, instead of changing every #include statement throughout the VMC project, it is easier to add all of the source module directories to the list of additional include directories (see  figure below for the location of this dialog).

One pitfall however, is that if you use the browser to select the appropriate directories, they are saved as absolute paths. That means that any time the project is relocated or checked out of a repository to another machine, the build process will break. Instead, it is better to use the macros provided to keep the include directories relative to the project.

So for example, if you select the directory "C:\Projects\TurnDoorSample\SUT\App" with the browser, then move the project to a different directory (such as My Documents) the VMC project will fail its next compilation. If you use the macro $(SolutionDir), it resolves to the SUT directory no matter where you place it, so the compilation succeeds.

The screen shots below show a properly configured MSVS project for the Turn Door Sample.

MxSuite uses the following criteria to select the Visual Studio version for builds started with the Build and Rebuild All verbs in MxTransIt and from Regression Tests:

1.If installed, the Visual Studio version that was used to create the solution is selected first. It uses the configuration specified in each project file that is in the solution.  Build errors may occur in this case (for example, if a solution is a 2013 solution, but has 2012 projects in it, MxSuite will attempt to build with 2013, but the 2012 projects will fail unless 2012 is also installed.

Special Note about Visual Studio 2008 solutions: Visual Studio 2008 must be installed if it is a 2008 solution. This installation cannot be reliably detected, so this may cause build errors, however a best attempt is made to try to build.

2.If the Visual Studio version detected in the solution file is not detected as being installed, or if the Visual Studio version is unknown (as when a new version has come out), MxSuite attempts to use the latest version of Visual Studio installed on the system. In general, this should not cause problems, except in the cases of the compiler being more strict about warnings (and warnings as errors is set), or more strict about standards compliance.  In this case, ALL projects in the solution file are overridden and forced to be built with the specified toolset.

The Launch Solution verb uses the Microsoft Visual Studio Version Selector. Generally, it uses the version of Visual Studio that was most recently used to save the solution (.sln) file. If it is not possible to use the solution file version (for example, if it is no longer installed), it will use the most recently installed version.

Notes:

•If you use the One-way upgrade wizard in Visual Studio, you cannot open the project with the original version. For more information, see Microsoft documentation.

•You can open a solution file with Notepad to see its version.

To force a retarget of the solution (VS 2012 solutions and greater with no automatic update project dialog):

1.In Windows Explorer, right-click the solution file and  select “Open With->” the desired Visual Studio version.

2.When the solution opens, right click the solution in the solution explorer, and click Retarget Solution, then click OK about the upgrading of projects. If the Retarget dialog opens automatically, click OK and proceed to step 3.

3.IMPORTANT: After retargeting, the solution file MUST be saved manually. Select the Solution File in Solution Explorer, and either press Ctrl-S, click the SAVE button in the toolbar, or select File->Save <solution>. SAVE ALL DOES NOT SAVE THE UPDATED SOLUTION FILE.

Build Error

If the build log includes an error message similar to this, it can usually be resolved by using the re-targeting procedure above:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.targets(44,5): error MSB8020: The builds tools for v140 (Platform Toolset = 'v140') cannot be found. To build using the v140 build tools, either click the Project menu or right-click the solution, and then select "Update VC++ Projects...". Install v140 to build using the v140 build tools.