I'm building some C++/CLI code into a DLL. This DLL acts as a wrapper to C# code that I use from my native C++ application. I double checked that the DLL is built as x86. My Boost build is also x86. So I don't think it has to do with architecture. Also tried adding /MACHINE:X86 to the linking parameters. My CLI/C++ code does not use boost at all. It is my application that uses both boost code and the CLI dll. Saludos / Best regards, *Sergio Basurco* Coherent Synchro On 06/12/2017 19:51, Steven Boswell II via Boost-users wrote:

On Tue, Dec 5, 2017 at 10:31 PM, Sergio Basurco via Boost-users wrote:

...

I'm using Boost 1.65.1 with Visual Studio 2015 (v140 compiler). Also, I'm using the following libs dynamically:

[...]

And I want to add C++/CLI code which is built with /clr. This used to work with v110 and Boost 1.57.  Now I'm getting this error just when launching the application.

0xc000007b

All binaries are 32bits. I'm also using the following define: BOOST_ALL_DYN_LINK

Any idea on why this may happen?

A Google search says that error 0xc000007b happens when you mix 64-bit and 32-bit code. Keep in mind that CLI code has to be explicitly compiled as 32-bit. The "Any CPU" setting tends to pick the OS' native word-size, which is probably 64-bit.

-Steven

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

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/ So the Wrapper and the SDK are managed, but my application isn't. My application only makes calls to the C++/CLI wrapper. This is working well and worked without issues using Visual Studio 2012 and Boost 1.57. Sorry I don't have anything on GitHub doing exactly this. I'm checking all my binaries but none seem to be x64. The other possible reason I found for error 0xc000007b was linking static boost libraries. But I deleted those just to check and still find the issue. Thanks! *Sergio Basurco* Coherent Synchro On 11/12/2017 15:16, Michael Powell via Boost-users wrote:

On Mon, Dec 11, 2017 at 4:43 AM, Sergio Basurco via Boost-users wrote:

...

I'm building some C++/CLI code into a DLL. This DLL acts as a wrapper to C# code that I use from my native C++ application.

I double checked that the DLL is built as x86. My Boost build is also x86. So I don't think it has to do with architecture. Also tried adding /MACHINE:X86 to the linking parameters.

My CLI/C++ code does not use boost at all. It is my application that uses both boost code and the CLI dll. Explain that.

You cannot do unmanaged things in a managed (CLI) application.

You are probably referencing into an Any CPU or x64 project, which is not guaranteed to work, and/or may require additional parameters.

I'm not sure how you link the Boost DLL with the target application.

As I and others have stated, you can do this with your C++/CLI project, i.e. using Boost "inside", so to speak, but you need to be aware of the CLI-isms bridging into the .NET managed memory space.

Show some projects on Github exactly what you're doing.

...

Saludos / Best regards,

Sergio Basurco Coherent Synchro

On 06/12/2017 19:51, Steven Boswell II via Boost-users wrote:

...

I'm using Boost 1.65.1 with Visual Studio 2015 (v140 compiler). Also, I'm using the following libs dynamically:

[...]

And I want to add C++/CLI code which is built with /clr. This used to work with v110 and Boost 1.57. Now I'm getting this error just when launching the application.

0xc000007b

All binaries are 32bits. I'm also using the following define: BOOST_ALL_DYN_LINK

Any idea on why this may happen? A Google search says that error 0xc000007b happens when you mix 64-bit and 32-bit code. Keep in mind that CLI code has to be explicitly compiled as 32-bit. The "Any CPU" setting tends to pick the OS' native word-size, which is

On Tue, Dec 5, 2017 at 10:31 PM, Sergio Basurco via Boost-users wrote: probably 64-bit.

-Steven

_______________________________________________ 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

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

On Tue, Dec 12, 2017 at 8:50 AM, Rob Conde via Boost-users wrote:

Can you put together a minimal toy example?

On Dec 12, 2017, at 5:14 AM, Sergio Basurco via Boost-users 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.

So the Wrapper and the SDK are managed, but my application isn't. My application only makes calls to the C++/CLI wrapper. This is working well and worked without issues using Visual Studio 2012 and Boost 1.57.

Sorry I don't have anything on GitHub doing exactly this. I'm checking all my binaries but none seem to be x64. The other possible reason I found for error 0xc000007b was linking static boost libraries. But I deleted those just to check and still find the issue.

Thanks!

Sergio Basurco Coherent Synchro

On 11/12/2017 15:16, Michael Powell via Boost-users wrote:

On Mon, Dec 11, 2017 at 4:43 AM, Sergio Basurco via Boost-users wrote:

I'm building some C++/CLI code into a DLL. This DLL acts as a wrapper to C# code that I use from my native C++ application.

I double checked that the DLL is built as x86. My Boost build is also x86. So I don't think it has to do with architecture. Also tried adding /MACHINE:X86 to the linking parameters.

My CLI/C++ code does not use boost at all. It is my application that uses both boost code and the CLI dll.

Explain that.

You cannot do unmanaged things in a managed (CLI) application.

You are probably referencing into an Any CPU or x64 project, which is not guaranteed to work, and/or may require additional parameters.

I'm not sure how you link the Boost DLL with the target application.

As I and others have stated, you can do this with your C++/CLI project, i.e. using Boost "inside", so to speak, but you need to be aware of the CLI-isms bridging into the .NET managed memory space.

Show some projects on Github exactly what you're doing.

Saludos / Best regards,

Sergio Basurco Coherent Synchro

On 06/12/2017 19:51, Steven Boswell II via Boost-users wrote:

On Tue, Dec 5, 2017 at 10:31 PM, Sergio Basurco via Boost-users wrote:

I'm using Boost 1.65.1 with Visual Studio 2015 (v140 compiler). Also, I'm using the following libs dynamically:

[...]

And I want to add C++/CLI code which is built with /clr. This used to work with v110 and Boost 1.57. Now I'm getting this error just when launching the application.

0xc000007b

All binaries are 32bits. I'm also using the following define: BOOST_ALL_DYN_LINK

Any idea on why this may happen?

A Google search says that error 0xc000007b happens when you mix 64-bit and 32-bit code. Keep in mind that CLI code has to be explicitly compiled as 32-bit. The "Any CPU" setting tends to pick the OS' native word-size, which is probably 64-bit.

-Steven

_______________________________________________ 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

_______________________________________________ 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

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

On 13.12.2017 01:38, Gavin Lambert 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. It is indeed a bit tricky to get it right, but yes, it works both ways,

Cheers, Leon

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