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

  • Thread starter Thread starter Sumedh
  • Start date Start date
S

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::Write(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::Write 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.
 
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:
Click to expand...

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
 
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.
 
Sumedh said:
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.
Click to expand...

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.
 
I guess the third option would not be possible (e.g. the real life
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.
Click to expand...

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::Write(this);
}
}

C++/CLI:

void writeObject(Test1^ 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
 
Sumedh said:
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::Write(this);
}
}

C++/CLI:

void writeObject(Test1^ 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?
Click to expand...

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.
 
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.
Click to expand...

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
 
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.
Click to expand...

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
 
Back
Top