assembly build loops?

[Doug Kent]

Sorry if this isn't really the proper group to which to post this topic, but
..NET is my development community, and I'm sure a lot of you might have
something to say about this. :-)

Scenario: I have two shared assemblies, each references the other. This
tends to cause build difficulties since DLL 1 needs DLL 2 to build, and DLL
2 needs DLL 1 to build.

I suspect this scenario might reflect a fundamental flaw in the design of
the code, but on the other hand, the design makes perfect sense to me.

Would anyone like to suggest a best practice?

Thanks,
Doug

[Nick Hounsome]

"Doug Kent" <dkent@_n_o_s_p_a_m.austin.rr.com> wrote in message
news:q7*******************@tornado.texas.rr.com...

Sorry if this isn't really the proper group to which to post this topic,
but .NET is my development community, and I'm sure a lot of you might have
something to say about this. :-)

Scenario: I have two shared assemblies, each references the other. This
tends to cause build difficulties since DLL 1 needs DLL 2 to build, and
DLL 2 needs DLL 1 to build.

I suspect this scenario might reflect a fundamental flaw in the design of
the code, but on the other hand, the design makes perfect sense to me.

Would anyone like to suggest a best practice?

In essence you want something like:

Assembly 1:

public Assembly1Class
{
public IAssembly2 A2;
}

public IAssembly2
{
// stuff from Assembly2Class
}

Assembly 2:

public class Assembly2Class
{
public Assembly1Class A1;
}

Assembly1Class a1 = new Assembly1Class();
Assembly2Class a2 = new Assembly2Class();

a1.A2 = a2;
a2.A1 = a1;
This is only the most limited way of breaking the cycle.
You can go further and make both assemblies use interfaces, put the
interfaces in a new assembly 3 and use reflection to construct the instances
so that neither assembly depends on the other (both depend on the interface
assembly that depends on nothing else)

[Richard MSL]

I believe that I have a similar problem to Doug Kent, except that one
assembly is in C++ and the other is in C#. I have been told that there is no
solution. I can not comprehend the proposed solution offered below. Would it
apply to C++ and C# assemblies? Thanks.

"Nick Hounsome" wrote:

"Doug Kent" <dkent@_n_o_s_p_a_m.austin.rr.com> wrote in message
news:q7*******************@tornado.texas.rr.com...

Sorry if this isn't really the proper group to which to post this topic,
but .NET is my development community, and I'm sure a lot of you might have
something to say about this. :-)

Scenario: I have two shared assemblies, each references the other. This
tends to cause build difficulties since DLL 1 needs DLL 2 to build, and
DLL 2 needs DLL 1 to build.

I suspect this scenario might reflect a fundamental flaw in the design of
the code, but on the other hand, the design makes perfect sense to me.

Would anyone like to suggest a best practice?

In essence you want something like:

Assembly 1:

public Assembly1Class
{
public IAssembly2 A2;
}

public IAssembly2
{
// stuff from Assembly2Class
}

Assembly 2:

public class Assembly2Class
{
public Assembly1Class A1;
}

Assembly1Class a1 = new Assembly1Class();
Assembly2Class a2 = new Assembly2Class();

a1.A2 = a2;
a2.A1 = a1;
This is only the most limited way of breaking the cycle.
You can go further and make both assemblies use interfaces, put the
interfaces in a new assembly 3 and use reflection to construct the instances
so that neither assembly depends on the other (both depend on the interface
assembly that depends on nothing else)

[Nick Hounsome]

"Richard MSL" <Ri*************@nospam.nospam> wrote in message
news:25**********************************@microsof t.com...

I believe that I have a similar problem to Doug Kent, except that one
assembly is in C++ and the other is in C#. I have been told that there is
no
solution. I can not comprehend the proposed solution offered below. Would
it
apply to C++ and C# assemblies? Thanks.
Give us some sort of idea of what your dependencies are.

I assume that your C++ is managed otherwise it is difficult for it to depend
on C#.
If it is managed you can do exactly the same as in my example.
"Nick Hounsome" wrote:

"Doug Kent" <dkent@_n_o_s_p_a_m.austin.rr.com> wrote in message
news:q7*******************@tornado.texas.rr.com...

> Sorry if this isn't really the proper group to which to post this
> topic,
> but .NET is my development community, and I'm sure a lot of you might
> have
> something to say about this. :-)
>
> Scenario: I have two shared assemblies, each references the other.
> This
> tends to cause build difficulties since DLL 1 needs DLL 2 to build, and
> DLL 2 needs DLL 1 to build.
>
> I suspect this scenario might reflect a fundamental flaw in the design
> of
> the code, but on the other hand, the design makes perfect sense to me.
>
> Would anyone like to suggest a best practice?

In essence you want something like:

Assembly 1:

public Assembly1Class
{
public IAssembly2 A2;
}

public IAssembly2
{
// stuff from Assembly2Class
}

Assembly 2:

public class Assembly2Class
{
public Assembly1Class A1;
}

Assembly1Class a1 = new Assembly1Class();
Assembly2Class a2 = new Assembly2Class();

a1.A2 = a2;
a2.A1 = a1;
This is only the most limited way of breaking the cycle.
You can go further and make both assemblies use interfaces, put the
interfaces in a new assembly 3 and use reflection to construct the
instances
so that neither assembly depends on the other (both depend on the
interface
assembly that depends on nothing else)

[Richard MSL]

Thanks for the reply. What I have is a legacy application written in C, that
I have written a new GUI for in C#. It worked in .NET 1.1. The C applications
call a GetScreen function, which is a managed C++ wrapper function that calls
the C# function that makes the WinForm and gets the data. The problem is that
some of the fields on the form can trigger the running of C application code,
so the C# has to call back to a C++ function, which calls the C application
code. Which in turn could initiate another GetScreen. I made it work in 1.1
by using my finished exe as the metadata for building the components, but
that will not work in 2.0, and is not a great solution anyway. Now I have to
be able to build the C, C++ and C# that all depend on each other. So it
sounded similar to the problem described here. Thanks in advance for any
suggestions.

"Nick Hounsome" wrote:

"Richard MSL" <Ri*************@nospam.nospam> wrote in message
news:25**********************************@microsof t.com...

I believe that I have a similar problem to Doug Kent, except that one
assembly is in C++ and the other is in C#. I have been told that there is
no
solution. I can not comprehend the proposed solution offered below. Would
it
apply to C++ and C# assemblies? Thanks.

Give us some sort of idea of what your dependencies are.

I assume that your C++ is managed otherwise it is difficult for it to depend
on C#.
If it is managed you can do exactly the same as in my example.

"Nick Hounsome" wrote:

"Doug Kent" <dkent@_n_o_s_p_a_m.austin.rr.com> wrote in message
news:q7*******************@tornado.texas.rr.com...
> Sorry if this isn't really the proper group to which to post this
> topic,
> but .NET is my development community, and I'm sure a lot of you might
> have
> something to say about this. :-)
>
> Scenario: I have two shared assemblies, each references the other.
> This
> tends to cause build difficulties since DLL 1 needs DLL 2 to build, and
> DLL 2 needs DLL 1 to build.
>
> I suspect this scenario might reflect a fundamental flaw in the design
> of
> the code, but on the other hand, the design makes perfect sense to me.
>
> Would anyone like to suggest a best practice?

In essence you want something like:

Assembly 1:

public Assembly1Class
{
public IAssembly2 A2;
}

public IAssembly2
{
// stuff from Assembly2Class
}

Assembly 2:

public class Assembly2Class
{
public Assembly1Class A1;
}

Assembly1Class a1 = new Assembly1Class();
Assembly2Class a2 = new Assembly2Class();

a1.A2 = a2;
a2.A1 = a1;
This is only the most limited way of breaking the cycle.
You can go further and make both assemblies use interfaces, put the
interfaces in a new assembly 3 and use reflection to construct the
instances
so that neither assembly depends on the other (both depend on the
interface
assembly that depends on nothing else)

[Brian Gideon]

Doug,

I'd say a circular assembly reference does more than make compiling
difficult. It makes it impossible. You have worked around the issue
by bootstrapping the build of the first assembly. That's not something
another developer can do from the code you check into the source code
control library.

The best practice is to separate out those classes that are shared
between your two existing assemblies into a third assembly. You may
need to define interfaces in the third assembly that the classes in the
existing assemblies implement.

Brian

Doug Kent wrote:

Sorry if this isn't really the proper group to which to post this topic, but
.NET is my development community, and I'm sure a lot of you might have
something to say about this. :-)

Scenario: I have two shared assemblies, each references the other. This
tends to cause build difficulties since DLL 1 needs DLL 2 to build, and DLL
2 needs DLL 1 to build.

I suspect this scenario might reflect a fundamental flaw in the design of
the code, but on the other hand, the design makes perfect sense to me.

Would anyone like to suggest a best practice?

Thanks,
Doug