Re: [Boost-users] Adding C++/CLI code to my project makes app crash on startup

19 Dec 2017

      The issue came from my builder, which was duplicating the binaries when 
creating my program. Here's basically what I had before:

    CLI_source1 -> cli_file1.obj
    CLI_source2 -> cli_file2.obj

    [cli_fil1.obj, cli_file2.obj] -> [cli_library.lib, cli_library.dll]

    [native_src, boost_shared_lib.lib, cli_library.lib, cli_file1.obj,
    cli_file2.obj] ->  program.exe (Builds but crashes!)

And here's the fixed version. Note that I was linking the cli binaries 
twice, bundled in a library and then also using the .objs.

    [native_src, boost_lib.dll, cli_library.lib] ->  program.exe (Works!)

It's not clear to me why exactly it crashed with the stack buffer 
overrun error. But at least I managed to fix it. Thanks for all the replies!

Saludos / Best regards,

*Sergio Basurco*
Coherent Synchro

On 13/12/2017 4:20, Michael Powell via Boost-users wrote:
...
...
On 13/12/2017 02:52, Michael Powell wrote:
...
...
I have a native (unmanaged) C++ application that consumes a C# SDK using
a
C++/CLI wrapper. This is achieved using a wrapper similar to the one
described here:
http://pragmateek.com/using-c-from-native-c-with-the-help-of-ccli-v2/
You have the bridge entirely backwards. CLI does not bridge C# to C++.
Rather, it bridges C++ to CLI.
It is true that the main intent of C++/CLI is to allow you to more easily
call native code from a managed application, rather than the reverse.
But the bridge can be used both ways, although there are some caveats
related to AppDomains, decompilers, delegates, and garbage collection, which
can surprise people.
You also need to be really careful about what things you put in header files
when they are being shared between native and managed code.
If, by "caveats", you mean being careful to do native things in an
otherwise CLI/.NET/managed environment, I agree. That was never CLI's
On Tue, Dec 12, 2017 at 7:38 PM, Gavin Lambert via Boost-users
 wrote:
purpose, however, as far as I know it's history to be.
They've even gone as far as to provide "managed" collections support
for the "native" C++, etc, to give you an idea.
Cheers. Good luck!
...
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users