Adding C++/CLI code to my project makes app crash on startup
Hi, I'm using Boost 1.65.1 with Visual Studio 2015 (v140 compiler). Also, I'm using the following libs dynamically: boost_unit_test_framework boost_log boost_filesystem boost_thread boost_system boost_log_setup boost_chrono boost_date_time boost_regex 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? -- Saludos / Best regards, *Sergio Basurco* Coherent Synchro
On Tue, Dec 5, 2017 at 12:01 PM, Sergio Basurco via Boost-users <boost-users@lists.boost.org> wrote:
Hi,
I'm using Boost 1.65.1 with Visual Studio 2015 (v140 compiler). Also, I'm using the following libs dynamically:
boost_unit_test_framework boost_log boost_filesystem boost_thread boost_system boost_log_setup boost_chrono boost_date_time boost_regex
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?
I'm not sure what you mean by "adding C++/CLI". CLI is strictly .NET-isms shimming atop C++. Literally the CLR supported atop C++. Link order is important CLI or not. You should be able to run C++/Boost "inside" your CLI code, but realize it's not the same thing as running a raw C++ run-time. That said, I've supported it in the past. At the time running Boost.Units within CLI "quantity" based measurement system. Worked fairly well for what I was doing.
--
Saludos / Best regards,
Sergio Basurco Coherent Synchro
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi, Could you please check following setting i visual studio:: Common Properties -> VC++ Directories -> Include Directories, type your boost folder (C:/boostsourcefolder/). and in Common Properties -> VC++ Directories -> Library Directories, type the boost compiled library folder (C:/boostsourcefolder/stage/lib/). On Tue, Dec 5, 2017 at 10:31 PM, Sergio Basurco via Boost-users < boost-users@lists.boost.org> wrote:
Hi,
I'm using Boost 1.65.1 with Visual Studio 2015 (v140 compiler). Also, I'm using the following libs dynamically:
boost_unit_test_framework boost_log boost_filesystem boost_thread boost_system boost_log_setup boost_chrono boost_date_time boost_regex
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? --
Saludos / Best regards,
*Sergio Basurco* Coherent Synchro
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On Tue, Dec 5, 2017 at 10:31 PM, Sergio Basurco via Boost-users <boost-users@lists.boost.org> 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
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 <boost-users@lists.boost.org> 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
On Mon, Dec 11, 2017 at 4:43 AM, Sergio Basurco via Boost-users <boost-users@lists.boost.org> 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 <boost-users@lists.boost.org> 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
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 <boost-users@lists.boost.org> 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 <boost-users@lists.boost.org> 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
Can you put together a minimal toy example? On Dec 12, 2017, at 5:14 AM, Sergio Basurco via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> 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/ 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 <boost-users@lists.boost.org><mailto:boost-users@lists.boost.org> 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 <boost-users@lists.boost.org><mailto:boost-users@lists.boost.org> 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<mailto:Boost-users@lists.boost.org> https://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> https://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> https://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto: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 <boost-users@lists.boost.org> wrote:
Can you put together a minimal toy example?
On Dec 12, 2017, at 5:14 AM, Sergio Basurco via Boost-users <boost-users@lists.boost.org> 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 <boost-users@lists.boost.org> 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 <boost-users@lists.boost.org> 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 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.
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
On Tue, Dec 12, 2017 at 7:38 PM, Gavin Lambert via Boost-users <boost-users@lists.boost.org> 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 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
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 <boost-users@lists.boost.org> 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
participants (7)
-
abhijit kolhe -
Gavin Lambert -
Leon Mlakar -
Michael Powell -
Rob Conde -
Sergio Basurco -
Steven Boswell II