Adding C++/CLI code to my project makes app crash on startup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list

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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
On Tue, Dec 5, 2017 at 12:01 PM, Sergio Basurco via Boost-users
<[hidden email]> 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
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
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 <[hidden email]> 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
On Tue, Dec 5, 2017 at 10:31 PM, Sergio Basurco via Boost-users <[hidden email]> 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
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 [hidden email] 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
On Mon, Dec 11, 2017 at 4:43 AM, Sergio Basurco via Boost-users
<[hidden email]> 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
> <[hidden email]> 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
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list

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
[hidden email] 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
[hidden email] 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
Can you put together a minimal toy example?

On Dec 12, 2017, at 5:14 AM, Sergio Basurco via Boost-users <[hidden email]> 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
[hidden email] 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
[hidden email] 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
On Tue, Dec 12, 2017 at 8:50 AM, Rob Conde via Boost-users
<[hidden email]> wrote:
> Can you put together a minimal toy example?
>
> On Dec 12, 2017, at 5:14 AM, Sergio Basurco via Boost-users
> <[hidden email]> 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
> <[hidden email]> 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
> <[hidden email]> 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
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
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.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++/CLI code to my project makes app crash on startup

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On Tue, Dec 12, 2017 at 7:38 PM, Gavin Lambert via Boost-users
<[hidden email]> 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
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users