inter-dependency between C++/CLI and C# dlls

[Sumedh]

Hi everyone

There is a C# project which calls C++/CLI dll to be able to call
native C++ including templates. But the C++/CLI code itself also
requires the C# dll to get the types. For example:

C#:

class Test1
{
void Write()
{
Test1Native::Wr ite(this);
}
}

C++/CLI:

class Test1Native
{
static void Write(Test1^ obj)
{
// calls to some global template and other native C++ functions
here.
}
}

This creates a build inter-dependency problem since the C++/CLI
requires the C# dll while the C# code requires the C++/CLI dll.
Currently i have a couple of possible approaches:
* Repeated builds with different configurations. To do this place the
C# code that calls the C++/CLI code in #if which is unset in the first
build pass, then C++/CLI dll is built and finally build C# again with
the macro defined. This is not nice especially since we shall just be
providing the library with no say on the applications' build
procedure.
* Call Test1Native::Wr ite using reflection from C# to break the
compile time dependency -- this one does not appear very clean either
and shall incur a small overhead (though probably negligible) when
done multiple times.

Is there some other known way to deal with such situations?
Thanks.

[Bruno van Dooren]

There is a C# project which calls C++/CLI dll to be able to call

native C++ including templates. But the C++/CLI code itself also
requires the C# dll to get the types. For example:

Hi,
Choose door number 3: split the C# project into 2 parts so that the C++/CLI
project and the C# project depend on a common C# class library.
That way your dependencies are tree shaped instead of circular.

If that is really not an option, I'd go for reflection because at least you
can wait until runtime to satisfy the dependencies.

Normally I really don't like shifting problems from build time to runtime,
but cyclical building dependencies are even uglier.

Kind regards,
Bruno van Dooren MVP - VC++
http://msmvps.com/blogs/vanDooren

[Sumedh]

Thanks for the reply.

I guess the third option would not be possible (e.g. the real life
class is quite close to the example i have given where the Test1.Write
is a virtual function). Reflection seems to be only real alternative
then.

regards,
sumedh.
On Mar 12, 4:04 pm, "Bruno van Dooren"
<bruno_nos_pam_ van_doo...@hotm ail.comwrote:

There is a C# project which calls C++/CLI dll to be able to call
native C++ including templates. But the C++/CLI code itself also
requires the C# dll to get the types. For example:

Hi,
Choose door number 3: split the C# project into 2 parts so that the C++/CLI
project and the C# project depend on a common C# class library.
That way your dependencies are tree shaped instead of circular.

If that is really not an option, I'd go for reflection because at least you
can wait until runtime to satisfy the dependencies.

Normally I really don't like shifting problems from build time to runtime,
but cyclical building dependencies are even uglier.

Kind regards,
Bruno van Dooren MVP - VC++
http://msmvps.com/blogs/vanDooren

[Ben Voigt]

"Sumedh" <su*****@gmail. comwrote in message
news:11******** **************@ q40g2000cwq.goo glegroups.com.. .

Thanks for the reply.

I guess the third option would not be possible (e.g. the real life
class is quite close to the example i have given where the Test1.Write
is a virtual function). Reflection seems to be only real alternative
then.

Define an interface in the C++/CLI assembly, that the C# client must
implement and pass in. In your specific example, the only reverse call is
to a function, so you can use a delegate instead of a full interface. The
delegate can either be passed to C++ as an argument to each function needing
it, or stored as a static variable/property of one of the C++ classes.

>
regards,
sumedh.
On Mar 12, 4:04 pm, "Bruno van Dooren"
<bruno_nos_pam_ van_doo...@hotm ail.comwrote:

There is a C# project which calls C++/CLI dll to be able to call
native C++ including templates. But the C++/CLI code itself also
requires the C# dll to get the types. For example:

Hi,
Choose door number 3: split the C# project into 2 parts so that the
C++/CLI
project and the C# project depend on a common C# class library.
That way your dependencies are tree shaped instead of circular.

If that is really not an option, I'd go for reflection because at least
you
can wait until runtime to satisfy the dependencies.

Normally I really don't like shifting problems from build time to
runtime,
but cyclical building dependencies are even uglier.

Kind regards,
Bruno van Dooren MVP - VC++
http://msmvps.com/blogs/vanDooren

[Sumedh]

I guess the third option would not be possible (e.g. the real life

class is quite close to the example i have given where the Test1.Write
is a virtual function). Reflection seems to be only real alternative
then.

Define an interface in the C++/CLI assembly, that the C# client must
implement and pass in. In your specific example, the only reverse call is
to a function, so you can use a delegate instead of a full interface. The
delegate can either be passed to C++ as an argument to each function needing
it, or stored as a static variable/property of one of the C++ classes.

Thanks, but didn't get this completely. The class will look something
like the following:

C#:

class Test1
{
public int First
{
get
{
return m_first;
}
}
public string Second
{
get
{
return m_second;
}
}

void Write()
{
Test1Native::Wr ite(this);
}
}

C++/CLI:

void writeObject(Tes t1^ obj)
{
writeObject(obj->First); // writeObject is a global overloaded
template function
// some more calls to native C++ functions.
writeObject(obj->Second);
// some more calls to native C++ functions.
}

An interface for a particular class can be provided, but this needs to
be done for many different classes. So do you mean an interface for
each such class?
regards
sumedh

[Ben Voigt]

"Sumedh" <su*****@gmail. comwrote in message
news:11******** *************@n 33g2000cwc.goog legroups.com...

I guess the third option would not be possible (e.g. the real life
class is quite close to the example i have given where the Test1.Write
is a virtual function). Reflection seems to be only real alternative
then.

Define an interface in the C++/CLI assembly, that the C# client must
implement and pass in. In your specific example, the only reverse call
is
to a function, so you can use a delegate instead of a full interface.
The
delegate can either be passed to C++ as an argument to each function
needing
it, or stored as a static variable/property of one of the C++ classes.

Thanks, but didn't get this completely. The class will look something
like the following:

C#:

class Test1
{
public int First
{
get
{
return m_first;
}
}
public string Second
{
get
{
return m_second;
}
}

void Write()
{
Test1Native::Wr ite(this);
}
}

C++/CLI:

void writeObject(Tes t1^ obj)
{
writeObject(obj->First); // writeObject is a global overloaded
template function
// some more calls to native C++ functions.
writeObject(obj->Second);
// some more calls to native C++ functions.
}

An interface for a particular class can be provided, but this needs to
be done for many different classes. So do you mean an interface for
each such class?

Yes.

That's the only way to unravel the dependency. However, I understood that
your customers would write custom code calling your C++/CLI assembly? In
that case you had better provide a clean set of API interfaces.

>

regards
sumedh

[Sumedh]

Yes.

That's the only way to unravel the dependency. However, I understood that
your customers would write custom code calling your C++/CLI assembly? In
that case you had better provide a clean set of API interfaces.

Thanks. Normally the client code will call the C# assembly and not the
C++/CLI assembly directly. Providing an interface for each class seems
to be the cleanest way.
regards
sumedh

[Sumedh]

Yes.

That's the only way to unravel the dependency. However, I understood that
your customers would write custom code calling your C++/CLI assembly? In
that case you had better provide a clean set of API interfaces.

Thanks. Normally the client code will call the C# assembly and not the
C++/CLI assembly directly. Providing an interface for each class seems
to be the cleanest way.
regards
sumedh