Stingray Studio : Getting Started Guide : Chapter 5 Migrating Applications to Stingray Studio : Migrating Projects Created with Visual Studio Versions Earlier than 2010
Migrating Projects Created with Visual Studio Versions Earlier than 2010
Global IDE Pathing
Global IDE directory paths are no longer supported, meaning that Tools > Options > VC++ Directories no longer exists. Instead, this has been moved to *.vcxproj file properties, at Project > Properties > Configuration Properties > VC++ Directories.
Property Sheets
To facilitate easier addition of paths to project files, Stingray projects add two property sheets to every project: SS-Win32-PropSheet and SS-X64-PropSheet. The IDE pathing for Stingray Studio has been added to those property sheets so that appropriate pathing will be picked up when a project is compiled. Property sheets are named based on the pattern SS-[Win32|X64]-PropSheet<VC++-version>.props. So, for Microsoft Visual Studio 2015, with the Visual C++ 14 compiler, the property sheet names would be SS-Win32-Propsheet14 and SS-X64-Propsheet14.
The property sheets for Stingray Studio are located in the <StingrayInstallDir>\Src directory.
Note: In order to move a project to another directory (not a sibling), it is necessary to remove property sheets from each configuration; otherwise the project may become unreadable due to pathing. After moving, property sheets should be re-added.
The Stingray Assistant tool takes care of adding-removing property sheets, particularly while moving the project into another directory. The Assistant tool is located in the <StingrayInstallDir>\Utils directory.
Adding a Property Sheet
Property sheets can be added by selecting the Property Manager tab or going to View > Property Manager. Right-click on a project and select Add New Project Property Sheet… or Add Existing Property Sheet….
NOTE >> Note: Property sheets are added to each configuration in the project. It may be necessary to delete property sheets for configurations that do not require them. After a new property sheet is created, any available settings that are changed are applied to all configurations that contain that property sheet.
Editing an Existing Property Sheet
View property sheets by going to the View > Property Manager window. To edit an existing property sheet, open an appropriate configuration such as Debug, expand the project and the configuration, then right-click on the property sheet and select Properties. This opens the Property Pages dialog, which you can use to change any necessary project settings. Changes made in this property sheet affect all configurations that contain the same property sheet.
*.vcxproj Project Extension
Earlier versions of Visual Studio used the project extension *.vcproj. The project extension is now *.vcxproj. Opening a *.vcproj project or solution file in Visual Studio should open the Project Conversion Wizard, which will convert the project into the new format.
Target Names
Projects that have been converted from an earlier version of Microsoft Visual Studio to versions MSVS 2010 SP1 through MSVS 2013, may generate warnings that the Target Name and the Output Name do not match.
Warning MSB8012 is displayed at the end of the library/assembly build in the output window:
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\<MSBuild
version>\Microsoft.CppBuild.targets(1095,5): warning MSB8012:
TargetPath(<library/assembly fullTargetpath>) does not match the Library's
OutputFile property value (<library/assembly fullOutputFilepath>).
This may cause your project to build incorrectly. 
To correct this, please make sure that $(OutDir), $(TargetName) and
$(TargetExt) property values match the value specified in %(Lib.OutputFile).
This is a known issue, which you can read more about in these locations:
Setting Target Names
One way to resolve the warning is to manually set the Target Name and TargetExt macros in the project properties. To set the Target Name and Target Extension, select Project > Properties and go to the General options to set the Target Name. Use the $(TargetName)$(TargetExt) macro in the project settings for any necessary references.
Some suggestions for these macro settings are:
Target Name: $(ProjectName)
Target Ext: exe, dll, lib, etc. as required by your application
Further suggested settings for these Project properties are:
1. Set Configuration Properties | Linker | General | Output file to $(OutDir)$(TargetName)$(TargetExt).
2. Set Configuration Properties | General | Output Directory to “desired directory path”, which could also be prefixed with $(Platform)\$(Configuration)\.
3. Set Configuration Properties | General | Intermediate Directory to “desired directory path” which could also be prefixed with $(Platform)\$(Configuration)\.
4. Set Configuration Properties | General | Target Name to “desired name for output file”
5. Set Configuration Properties | General | Target Extension to “desired output file extension” (include the preceding dot).
The “desired directory path” is user-defined and should match the end-user’s environment needs.
Build Configurations
Build Configurations Not Checked
When converting a project from a previous version of Microsoft Visual Studio, the Build checkbox is not selected by default in the Configuration Manager. You must manually check the Build checkbox in order for builds to work.
Template Build Configurations
When converting a project from a previous version of Microsoft Visual Studio, there may be a build configuration named Template listed in the Configuration Manager. This build configuration will cause errors if a build is attempted. It is safe to remove this build configuration.
Managed Configurations
This link may be helpful for setting up managed configurations.
To Compile an MFC Executable or Regular DLL Using /clr
1. Right-click the project in Solution Explorer and then click Properties.
2. In the Project Properties dialog box, expand the node next to Configuration Properties and select General. In the right pane, under Project Defaults, set Common Language Runtime support to Common Language Runtime Support (/clr).
In the same pane, make sure that Use of MFC is set to Use MFC in a Shared DLL.
3. Under Configuration Properties, expand the node next to C/C++ and select General. Make sure that Debug Information Format is set to Program Database /Zi (not /ZI).
4. Select the Code Generation node. Set Enable Minimal Rebuild to No (/Gm-). Also set Basic Runtime Checks to Default.
5. Under Configuration Properties, select C/C++ and then Code Generation. Make sure that Runtime Library is set to either Multi-threaded Debug DLL (/MDd) or Multi-threaded DLL (/MD).
6. For Stingray Applications, under the Preprocessor section add the preprocessor command: _MANAGED
To Compile an MFC extension DLL Using /clr
1. Follow the steps in the previous section, “To compile an MFC executable or regular DLL using /clr”.
2. Under Configuration Properties, expand the node next to C/C++ and select Precompiled Headers. Set Create/Use Precompiled Header to Not using Precompiled Headers.
Alternatively, in Solution Explorer, right-click Stdafx.cpp and then click Properties. Under Configuration Properties, expand the node next to C/C++ and select General. Set Compile with Common Language Runtime support to No Common Language Runtime support.
3. For Stingray Applications, make sure that in the Preprocessor section the _MANAGE flag is not defined.
4. For the file that contains DllMain and anything it calls, in Solution Explorer, right-click the file name and then click Properties. Under Configuration Properties, expand the node next to C/C++ and select General. In the right pane, under Project Defaults, set Compile with Common Language Runtime support to No Common Language Runtime support.
Using Precompiled Headers
To use precompiled header files in a project:
1. Right click on the project and select Properties. Under Configuration Properties > C/C++ > Pre Compiled Headers, for all configurations, select Use /Yu for the Precompiled Header option. Select OK.
2. Expand the project in the Solution Explorer and locate the file called stdafx.cpp, or the similar project main cpp file, then right click and select Properties. Under Configuration Properties > C/C++ > Pre Compiled Headers, for all configurations, select Create /Yc for the Precompiled Header option. Select OK.
Using Visual Studio to Compile with an Older Platform Toolset
Some versions of Visual Studio support the use of platform toolsets to compile to an older version of the compiler. For more information, see
Targeting Windows XP
Some versions of Microsoft Visual Studio allow targeting Windows XP specifically. To specifically target Windows XP, choose a platform toolset option with a *_xp identifier, such as v120_xp or v110_xp. See the next section for information on how to choose the platform toolset.
Not all C++ runtime features are supported when targeting Windows XP. Please refer to the following article for more information on targeting Windows XP:
Choosing the Platform Toolset and Building the Library
There are two cases to consider here: Stingray libraries built through Visual Studio projects, and Stingray libraries built through makefiles.
Visual Studio Project-based Libraries
The following Stingray libraries are built through Visual Studio projects:
For these libraries, the work is done in Visual Studio:
1. Open the project in Microsoft Visual Studio. In the Solution Explorer window, right-click on the project and choose Properties.
2. In the Property Pages dialog, select All Configurations or the desired configuration from the Configuration dropdown menu.
3. In the Property Pages dialog, expand the Configuration Properties item and select General.
4. Select the desired platform toolset from the dropdown list. For example:
5. Select the OK button.
6. Build the library.
Makefile-based Libraries
For makefile-based libraries, the platform toolset is changed manually in the *.vcxproj file before the library is built.
1. For each Stingray library you plan to use, open its *.vcxproj file in an editor.
2. Locate the appropriate configuration section and add the toolset set value for the platform you are targeting to the <PlatformToolset> tag. Valid values are v120, v120_xp, v110, v110_xp, v100, and v90. If the <PlatformToolset> tag is not present, add it.
We recommend making this change to all build configurations in the project file.
NOTE >> Note: It is easier to search and replace all existing occurrences of <PlatformToolset>valid-toolset-value</PlatformToolset> with the toolset value you want to use.
Below is an example of where to add or change a <PlatformToolset> element to a specific build configuration in the Objective Chart Library Chart12.vcxproj project file:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Stingray DLL
MFC DLL Debug (asd)|x64'" Label="Configuration">
3. Save the file.
4. If you are targeting Windows XP, either from Stingray Studio Assistant, or by opening <installdir>\Include\SupportedPlatforms.h, set the target NTDDI_VERSION value to Windows XP Service Pack 2 or Windows XP Service Pack 3, depending on the target platform. For example:
5. Rebuild the library by:
*Running the product-specific Build Wizard and selecting Enable _USING_V110_SDK71_ Flag under the Compiler Options section. This adds _USING_V110_SDK_ to the product’s bldback*.mak file under the CUSTOM_CPP section. The Build Wizard can best be found under Stingray in the Windows Start menu or through Stingray Studio Assistant. Please refer to the “Build Wizard” section in this Guide for more information.
*Building the project in MSVC.
Other Considerations
If your application uses the Regex library for Objective Toolkit or Objective Edit, you will need to build this library with the target toolset also.
1. Modify the Regex *.vcxproj files with the appropriate platform toolset as described in the procedure for makefile-based libraries.
2. Modify the Regex makefile.
The makefiles are located in<installdir>\Regex\lib. There are two types: makefiles for static builds, with the pattern vc##.mak, where ## represents Visual Studio C++ compiler version; and makefiles for dynamic builds, with the pattern vc##dll.mak.
For static build makefiles (vc##.mak) follow these steps:
*Near the top of file there is a location to define compiler options such as
Add this definition:
*Much of the rest of the file has compilation lines for various cpp files. Each makefile has several sets of these for each supported configuration. For example:
cl /nologo /MTd /W3 /Gm /EHa /Zi /Od /I..\include /DWIN32 /D_MT /D_DEBUG /D_MBCS /D_LIB /FD /c $(XCFLAGS) ‑Fp$(REGEX_MAK_LIB_OUTPUT_DIR)/$(COMPILER_VERSION)‑re200dm/$(COMPILER_VERSION)-re200dm.pch -Fo./$(REGEX_MAK_LIB_OUTPUT_DIR)/$(COMPILER_VERSION)-re200dm/ -Fd$(REGEX_MAK_LIB_OUTPUT_DIR)/$(COMPILER_VERSION)-re200dm.pdb ../src/cregex.cpp
In each case — it is safest to modify all of the compilation lines — add the new compiler option $(XPTOOLSET) after $(XCFLAGS):
cl /nologo /MTd /W3 /Gm /EHa /Zi /Od /I..\include /DWIN32 /D_MT /D_DEBUG /D_MBCS /D_LIB /FD /c $(XCFLAGS) $(XPTOOLSET) ‑Fp$(REGEX_MAK_LIB_OUTPUT_DIR)/$(COMPILER_VERSION)‑re200dm/$(COMPILER_VERSION)-re200dm.pch -Fo./$(REGEX_MAK_LIB_OUTPUT_DIR)/$(COMPILER_VERSION)-re200dm/ -Fd$(REGEX_MAK_LIB_OUTPUT_DIR)/$(COMPILER_VERSION)-re200dm.pdb ../src/cregex.cpp
For dynamic build makefiles (vc##dll.mak) follow these steps:
*Before the line
located around line 50 in the file, add the definition
*Add the compiler option to the CPP_PROJ line located at around line 90:
CPP_PROJ=/nologo /MD /Wp64 /GX /O2 /I "../include" $(CFGX) /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "RE_DLL_EXPORTS" /D "RE_BUILD_DLL" /Fp"$(INTDIR)\$(LIBNAME).pch" /YX /Fd"$(INTDIR)\$(LIBNAME)" /FD /c
would become
CPP_PROJ=/nologo /MD /Wp64 /GX /O2 /I "../include" $(CFGX) $(XPTOOLSET) /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "RE_DLL_EXPORTS" /D "RE_BUILD_DLL" /Fp"$(INTDIR)\$(LIBNAME).pch" /YX /Fd"$(INTDIR)\$(LIBNAME)" /FD /c
3. Rebuild the library by:
*Running either the Objective Edit Build Wizard and selecting the Regex library option, or the Objective Toolkit Build Wizard and selecting the Regex/HTML option. Once you have successfully run the Build Wizard, the above changes will be picked up by the makefile system.
The appropriate Build Wizard can best be found under Stingray in the Windows Start menu or through Stingray Studio Assistant.
*Building the libraries either through the solutions StingrayLibraries##.sln, Toolkit##.sln, or Edit##.sln, or with the makefiles Toolkit##.mak or Edit##.mak.
Once you have updated and built all the libraries on which your application depends, build your application, linking to these libraries.
Deploying to the Target Platform
When an application has been built with one of the Microsoft Visual Studio platform toolsets, it can then be deployed to the platform for that toolset, assuming the deployment platform has the targeted Windows- and Compiler-specific runtimes (redistributable package) installed. An application will not run on the targeted platform unless the targeted Windows- and Compiler-specific runtimes, especially MFC runtimes, are present.
For Dynamic Link Library (DLL) applications, any DLLs the application depends on will need to be copied to the target platform machine.
For information regarding the minimum service pack levels for Microsoft VC++ Redistributable Packages, refer to:
Redistribution packages can be downloaded from these locations:
*Download Visual C++ Redistributable Packages for Visual Studio 2015 from
*Download Visual C++ Redistributable Packages for Visual Studio 2013 from
*Download Visual C++ Redistributable Packages for Visual Studio 2012 Update 4 from
Specific Issues
The Multi-byte Character Set is No Longer Available with MFC 12.0
In Visual Studio 2013 and later, the MFC libraries for multi-byte character encoding (MBCS) are provided as an add-on to Visual Studio and are available free of charge to Visual Studio customers (Pro, Premium and Ultimate editions only) from the MSDN download site.
Starting with MSVS 2015, the MBCS libraries do not require a separate install but are included in the MSVC installation; just ensure that the MFC checkbox is selected in the installer.
NOTE >> Stingray Studio requires the MBCS libraries and the Stingray Studio libraries will not build correctly without them.
The libraries require about 440 MB, and the installation includes all localized versions of the libraries. You can install the add-on on any machine on which Visual Studio Pro, Premium or Ultimate edition is installed, and which has the in-box MFC feature enabled. If you uninstall or repair Visual Studio, the MBCS libraries will also be uninstalled or repaired. However, if you just remove the MFC feature, the MBCS libraries will remain on your system. If you repair the MBCS libraries, Visual Studio is not modified in any way. The Redistributable Packages for Visual Studio 2013 and later will still include the MBCS MFC DLLs. No additional steps are required to redistribute the DLLs to your customers.
If these MFC libraries are not installed from the MBCS MFC Add-in for MSVS 2013, then the following error appears:
>LINK : fatal error LNK1104: cannot open file 'mfc120.lib'
1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\VC\BIN\link.exe"' :
return code '0x450'
Remove MBCS Character Set
To remove the MBCS as the character set in your project, change the Character Set to Not Set or Unicode under the project settings Configuration Properties > General.
Suppress MBCS Warnings
To suppress warnings about MBCS, define the following macro in your stdafx.h or another appropriate header file:
Some Stingray samples do not suppress this warning because it is displayed via the inclusion of MFC header files that precede Stingray header files.
Output Files Warnings
In Visual Studio 2013, if warnings are issued about being unable to locate vc120.pdb, then change the project properties to use $(IntDir)$(TargetName).pdb or similar in the Configuration Properties > C/C++ > Output Files setting.
ADO Issues as of Windows 7.0 SP1 or Later
When compiling Objective Grid with ADO Grid components from the Build Wizard’s Components page, as shown below, on Windows 7 or later and on MSVS 2012 or later, a few Microsoft issues are exposed.
ADO Design Change as of Windows 7.0 SP1
There is a Microsoft by-design change in ADO in Windows 7 SP1 that interfaces have new GUIDs. The pattern is that most ADO interfaces (say Connection) have new GUIDs while the old GUIDs are assigned to interfaces named xxx_deprecated (say Connection_Deprecated). The reason for this change is mentioned in KB983246:
“Some ADO APIs are platform dependent in ADO 2.7 and later versions. On 64-bit versions of Windows, these ADO APIs process arguments by using a 64-bit data type (such as the LONGLONG data type). However, applications that use these APIs still use the LONG data type. Therefore, you receive a “Type Mismatch” error message when you try to run the macro.”
The interfaces with the new GUIDs (in Windows 7 SP1 or later) don't have this issue.
As a result, if your application is re-compiled on Windows 7 SP1 and it uses the earlier bindings to ADO, it probably will not work on down-level OSs, such as Windows 7 RTM, XP, and so on. Please note that this problem only occurs when the application is re-compiled. Existing applications should run on Windows 7 SP1 without any problems.
Below we suggest three ways to build with ADO on Windows 7 SP1 or later. Our suggestions do not include the main way recommended by Microsoft in output messages when you build Grid:
“Change your target platform to Windows 7 or below if your application requires backward compatibility for the ADO interface.”
If you have to re-compile your application on SP1, here are three workarounds:
1. Request a KB983246 package and install it on your customers' machines. The re-compiled application should work after the package is installed.
2. Re-write your application to use the later binding to ADO, or use interfaces with the names xxx_deprecated.
3. Keep an old version of the ADO typelib (i.e., msado28.tlb) (you can copy it from Windows 7 RTM), then compile your application with the old typelib instead of the one on your system.
Cannot Open SupportedPlatforms.h
If you receive this error:
Fatal error C1083: Cannot open include file “SupportedPlatforms.h” : No such file or directory
it means that you may not have paths set up correctly for the project you are working on. Refer to “Global IDE Pathing”
Ambiguous Call to OpenDocumentFile()
The API for OpenDocumentFile() has changed in CSingleDocTemplate and CMultiDocTemplate to:
virtual CDocument* OpenDocumentFile(LPCTSTR lpszPathName,
BOOL bAddToMRU, BOOL bMakeVisible = TRUE);
A second boolean parameter to add to the MRU list can be added to the call to resolve it.