[CONNECT C++] Setting up C++ Visual Studio Project problems

hoping someone might be able to help me out. I have been writing addins in C#, but now im trying to start out with using c++/Cli for some wrappers. but I'm getting errors from the start...

here are the steps I took to create a c++/Cli  class project.

1.open VS2015 and create new c++/CLI class project,

2. close and open the sln file from MicroStation SDK command prompt

3. add include location to properties.

4. add lib location to properties

5. then all I did was start to add using statements to my header file. I only added #include<Mstn\MdlApi\MdlApi.h>

once I added that I got 2 errors.

cannot open source file "_config-eccp.h"

and #error directive: Data Alignment must be defined in basedefs.h.

im a newbie what it comes to c++...

Parents
  • Hi John,

    "2. close and open the sln file from MicroStation SDK command prompt"

    Why?, Why not using Visual Studio?

    "5. then all I did was start to add using statements to my header file. I only added #include<Mstn\MdlApi\MdlApi.h>"

    From screen shot I assume cppWrappers.h has Common Language Support?

    If it has then you can not include MdlApi.h there. You are mixing managed and unmanaged code!

    "cannot open source file "_config-eccp.h"  usually means your project settings are wrong!

    regards

    Nenad

  • "2. close and open the sln file from MicroStation SDK command prompt"

    Why?, Why not using Visual Studio?

    Hi ,

    For now the existing (simple) Visual Studio Project Templates rely on a couple shell configuration variables allowing Visual Studio (devenv) to dynamically update the paths based on where the user installed the products (MS and SDK) w/o regard to where a user installs products or their application source code.  I am contemplating in an update or two to those templates to defer to having the templates extract locations via registry lookups vs. config variables to help ensure portability and continuity of compiling apps w/o issue from one developer's box to another's.

    HTH,
    Bob



  • For now the existing (simple) Visual Studio Project Templates rely on a couple shell configuration variables allowing Visual Studio (devenv) to dynamically update the paths based on where the user installed the products (MS and SDK) w/o regard to where a user installs products or their application source code.

    This is "technical justification" and it's the core concept. But I have to say I have extended it over time to cover literaly everything related to any my project. From "I accept it" I moved to "I understand it" and at the end "it's base platform for all projects" ;-)

    The shell (now Windows command shell, but can be PowerShell also in future) defines complete environment for the project. It's simple to pass not only MicroStation + SDK locations, but also other configurations related to project (Boost libraries location, DB configuration...).

    It allows to create environment that is isolated completely from outside dependencies (as Bob mentioned) where MicroStation and SDK are installed, but also what product/SDK is used to compile and run tests and also where the project root is stored.

    A consequence of this "orthogonality to local conditions" is when it's stored in GIt (or other repository type), it can be easily shared by different people with very different installations. Usually I need only 2 local files (shell shortcut and local configuration file) that are specific to local computer and are not shared.

    A few years ago I extended the shell to include also sandbox, so any testing can be done just calling MicroStation with exactly defined workspace shared again in Git by all member teams. No situations like "it works on this computer and not on that" anymore, which has saved huge amount of time on every project again and again (especially when the most of my projects are international and difference between "this" and "that" computers are thousand of kilometers ;-)

    So my summary is: Despite of the shell seems to be like weird dinosaurus, it allows to create isolated environment designed individually for every project. In fact, Visual Studio does the same: When any task like compilation is created, it starts a shell at background, pass all  all project variables to it and starts proper tool (usually MSBuild, but can be bmake, CMake or whatever else).

    With regards,

      Jan

Reply
  • For now the existing (simple) Visual Studio Project Templates rely on a couple shell configuration variables allowing Visual Studio (devenv) to dynamically update the paths based on where the user installed the products (MS and SDK) w/o regard to where a user installs products or their application source code.

    This is "technical justification" and it's the core concept. But I have to say I have extended it over time to cover literaly everything related to any my project. From "I accept it" I moved to "I understand it" and at the end "it's base platform for all projects" ;-)

    The shell (now Windows command shell, but can be PowerShell also in future) defines complete environment for the project. It's simple to pass not only MicroStation + SDK locations, but also other configurations related to project (Boost libraries location, DB configuration...).

    It allows to create environment that is isolated completely from outside dependencies (as Bob mentioned) where MicroStation and SDK are installed, but also what product/SDK is used to compile and run tests and also where the project root is stored.

    A consequence of this "orthogonality to local conditions" is when it's stored in GIt (or other repository type), it can be easily shared by different people with very different installations. Usually I need only 2 local files (shell shortcut and local configuration file) that are specific to local computer and are not shared.

    A few years ago I extended the shell to include also sandbox, so any testing can be done just calling MicroStation with exactly defined workspace shared again in Git by all member teams. No situations like "it works on this computer and not on that" anymore, which has saved huge amount of time on every project again and again (especially when the most of my projects are international and difference between "this" and "that" computers are thousand of kilometers ;-)

    So my summary is: Despite of the shell seems to be like weird dinosaurus, it allows to create isolated environment designed individually for every project. In fact, Visual Studio does the same: When any task like compilation is created, it starts a shell at background, pass all  all project variables to it and starts proper tool (usually MSBuild, but can be bmake, CMake or whatever else).

    With regards,

      Jan

Children
No Data