.DLL hell II - The Evil Empire Strikes Back

[.DLL hell II - The Evil Empire Strikes Back]

I can't figure out how this side-by-side assembly stuff it
supposed to work.
I have a stack of four assemblies
A has no references
B references A & C
C References A & B
D References A, B and C

During a built I invariably end up with the wrong
assemblies in the final bin directory even though I have
hard-coded the version numbers for each component to avoid
breaking the build. Worse when I copy the correct
versions off the assemblies for A, B and C to the bin
directory for D and then open D in Visual Studio it,
without warning, copies the wrong versions of the files
back to the bin directory. I've wasted weeks with this
stuff - It makes figuring out the cause of problems really
rather tricky. And its not even a terribly complicated
object stack. How do I build it?

[Jay B. Harlow [MVP - Outlook]]

Re: .DLL hell II - The Evil Empire Strikes Back

I hope this is a typo:
[color=blue]
> B references A & C
> C References A & B[/color]

B references C and C reference B, cannot be done in .NET. As each needs to
be compiled before the other...

I normally have a single solution that has 4 projects A,B,C,D when I build
the solution all the projects get built, and the correct versions of the
dlls are in the correct bin folders. No manual intervention required. I have
solutions with 8 to 12 class libraries each using this method.

Within VS.NET are you referencing the DLL or the project?

Hope this helps
Jay

".DLL hell II - The Evil Empire Strikes Back" <a@b.c> wrote in message
news:0df301c377 a6$06d7ac60$a30 1280a@phx.gbl.. .[color=blue]
> I can't figure out how this side-by-side assembly stuff it
> supposed to work.
> I have a stack of four assemblies
> A has no references
> B references A & C
> C References A & B
> D References A, B and C
>
> During a built I invariably end up with the wrong
> assemblies in the final bin directory even though I have
> hard-coded the version numbers for each component to avoid
> breaking the build. Worse when I copy the correct
> versions off the assemblies for A, B and C to the bin
> directory for D and then open D in Visual Studio it,
> without warning, copies the wrong versions of the files
> back to the bin directory. I've wasted weeks with this
> stuff - It makes figuring out the cause of problems really
> rather tricky. And its not even a terribly complicated
> object stack. How do I build it?
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: .DLL hell II - The Evil Empire Strikes Back

C,
Refer back to your original post you stated:[color=blue][color=green][color=darkred]
> >> I can't figure out how this side-by-side assembly stuff[/color][/color]
> it[color=green][color=darkred]
> >> supposed to work.
> >> I have a stack of four assemblies
> >> A has no references
> >> B references A & C
> >> C References A & B
> >> D References A, B and C[/color][/color][/color]

To compile B, you will need to have C compiled.
To compile C, you will need to have B compiled.
[color=blue]
> Given the problem .NET has with cross referencing of
> classes within objects is my only option to have a
> separate assembly containing the application exceptions I
> need which both C and D can reference? IE[/color]
Instead of having the Exceptions in Assembly B, I would consider having an
Assembly E for the Application Exceptions. Which is a variation of the
Seperated Interface Pattern.

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

Although it is not as common, I would consider having Assembly B publish an
Interface that identifies 'custom exceptions of one of the types found in
C'. In other words a single Interface in Assembly B, that all of the
exceptions in C implement, this interface would not need to have any
members. Which is another variation of the Seperated Interface Pattern.

Hope this helps
Jay

"C" <a@b.c> wrote in message news:0b0901c377 b5$38f2fba0$a60 1280a@phx.gbl.. .[color=blue]
> No it isn't a typo. Its what I want to achieve:
> A) Is an analyser component
> B) Is a logger component
> C) Is a Server component. C may throw one of several
> application exceptions, which have some additional
> properties, exposed on them.
> These are logged by the logger which may additionally
> alert ops to the fact that there is a major problem. It
> does this by looking to see if the type of Exception it
> has been thrown is a custom exception of one of the types
> found in C and then interrogating some of the additional
> properties.
>
> Given the problem .NET has with cross referencing of
> classes within objects is my only option to have a
> separate assembly containing the application exceptions I
> need which both C and D can reference? IE
> A Is the Analyser Component and has no references
> B is the Application Exception Class and has no references
> C Is the logger and references B
> D Is the Server and references A, B and C
> ?
>[color=green]
> >-----Original Message-----
> >I hope this is a typo:
> >[color=darkred]
> >> B references A & C
> >> C References A & B[/color]
> >
> >B references C and C reference B, cannot be done in .NET.[/color]
> As each needs to[color=green]
> >be compiled before the other...
> >
> >I normally have a single solution that has 4 projects[/color]
> A,B,C,D when I build[color=green]
> >the solution all the projects get built, and the correct[/color]
> versions of the[color=green]
> >dlls are in the correct bin folders. No manual[/color]
> intervention required. I have[color=green]
> >solutions with 8 to 12 class libraries each using this[/color]
> method.[color=green]
> >
> >Within VS.NET are you referencing the DLL or the project?
> >
> >Hope this helps
> >Jay
> >
> >".DLL hell II - The Evil Empire Strikes Back" <a@b.c>[/color]
> wrote in message[color=green]
> >news:0df301c37 7a6$06d7ac60$a3 01280a@phx.gbl. ..[color=darkred]
> >> I can't figure out how this side-by-side assembly stuff[/color][/color]
> it[color=green][color=darkred]
> >> supposed to work.
> >> I have a stack of four assemblies
> >> A has no references
> >> B references A & C
> >> C References A & B
> >> D References A, B and C
> >>
> >> During a built I invariably end up with the wrong
> >> assemblies in the final bin directory even though I have
> >> hard-coded the version numbers for each component to[/color][/color]
> avoid[color=green][color=darkred]
> >> breaking the build. Worse when I copy the correct
> >> versions off the assemblies for A, B and C to the bin
> >> directory for D and then open D in Visual Studio it,
> >> without warning, copies the wrong versions of the files
> >> back to the bin directory. I've wasted weeks with this
> >> stuff - It makes figuring out the cause of problems[/color][/color]
> really[color=green][color=darkred]
> >> rather tricky. And its not even a terribly complicated
> >> object stack. How do I build it?
> >>[/color]
> >
> >
> >.
> >[/color][/color]

[C]

Re: .DLL hell II - The Evil Empire Strikes Back

It does - thank you very much.
[color=blue]
>-----Original Message-----
>C,
>Refer back to your original post you stated:[color=green][color=darkred]
>> >> I can't figure out how this side-by-side assembly[/color][/color][/color]
stuff[color=blue][color=green]
>> it[color=darkred]
>> >> supposed to work.
>> >> I have a stack of four assemblies
>> >> A has no references
>> >> B references A & C
>> >> C References A & B
>> >> D References A, B and C[/color][/color]
>
>To compile B, you will need to have C compiled.
>To compile C, you will need to have B compiled.
>[color=green]
>> Given the problem .NET has with cross referencing of
>> classes within objects is my only option to have a
>> separate assembly containing the application exceptions[/color][/color]
I[color=blue][color=green]
>> need which both C and D can reference? IE[/color]
>Instead of having the Exceptions in Assembly B, I would[/color]
consider having an[color=blue]
>Assembly E for the Application Exceptions. Which is a[/color]
variation of the[color=blue]
>Seperated Interface Pattern.
>
>http://www.martinfowler.com/eaaCatal...ratedInterface.[/color]
html[color=blue]
>
>Although it is not as common, I would consider having[/color]
Assembly B publish an[color=blue]
>Interface that identifies 'custom exceptions of one of[/color]
the types found in[color=blue]
>C'. In other words a single Interface in Assembly B, that[/color]
all of the[color=blue]
>exceptions in C implement, this interface would not need[/color]
to have any[color=blue]
>members. Which is another variation of the Seperated[/color]
Interface Pattern.[color=blue]
>
>Hope this helps
>Jay
>
>"C" <a@b.c> wrote in message news:0b0901c377 b5$38f2fba0[/color]
$a601280a@phx.g bl...[color=blue][color=green]
>> No it isn't a typo. Its what I want to achieve:
>> A) Is an analyser component
>> B) Is a logger component
>> C) Is a Server component. C may throw one of several
>> application exceptions, which have some additional
>> properties, exposed on them.
>> These are logged by the logger which may additionally
>> alert ops to the fact that there is a major problem. It
>> does this by looking to see if the type of Exception it
>> has been thrown is a custom exception of one of the[/color][/color]
types[color=blue][color=green]
>> found in C and then interrogating some of the additional
>> properties.
>>
>> Given the problem .NET has with cross referencing of
>> classes within objects is my only option to have a
>> separate assembly containing the application exceptions[/color][/color]
I[color=blue][color=green]
>> need which both C and D can reference? IE
>> A Is the Analyser Component and has no references
>> B is the Application Exception Class and has no[/color][/color]
references[color=blue][color=green]
>> C Is the logger and references B
>> D Is the Server and references A, B and C
>> ?
>>[color=darkred]
>> >-----Original Message-----
>> >I hope this is a typo:
>> >
>> >> B references A & C
>> >> C References A & B
>> >
>> >B references C and C reference B, cannot be done[/color][/color][/color]
in .NET.[color=blue][color=green]
>> As each needs to[color=darkred]
>> >be compiled before the other...
>> >
>> >I normally have a single solution that has 4 projects[/color]
>> A,B,C,D when I build[color=darkred]
>> >the solution all the projects get built, and the[/color][/color][/color]
correct[color=blue][color=green]
>> versions of the[color=darkred]
>> >dlls are in the correct bin folders. No manual[/color]
>> intervention required. I have[color=darkred]
>> >solutions with 8 to 12 class libraries each using this[/color]
>> method.[color=darkred]
>> >
>> >Within VS.NET are you referencing the DLL or the[/color][/color][/color]
project?[color=blue][color=green][color=darkred]
>> >
>> >Hope this helps
>> >Jay
>> >
>> >".DLL hell II - The Evil Empire Strikes Back" <a@b.c>[/color]
>> wrote in message[color=darkred]
>> >news:0df301c37 7a6$06d7ac60$a3 01280a@phx.gbl. ..
>> >> I can't figure out how this side-by-side assembly[/color][/color][/color]
stuff[color=blue][color=green]
>> it[color=darkred]
>> >> supposed to work.
>> >> I have a stack of four assemblies
>> >> A has no references
>> >> B references A & C
>> >> C References A & B
>> >> D References A, B and C
>> >>
>> >> During a built I invariably end up with the wrong
>> >> assemblies in the final bin directory even though I[/color][/color][/color]
have[color=blue][color=green][color=darkred]
>> >> hard-coded the version numbers for each component to[/color]
>> avoid[color=darkred]
>> >> breaking the build. Worse when I copy the correct
>> >> versions off the assemblies for A, B and C to the bin
>> >> directory for D and then open D in Visual Studio it,
>> >> without warning, copies the wrong versions of the[/color][/color][/color]
files[color=blue][color=green][color=darkred]
>> >> back to the bin directory. I've wasted weeks with[/color][/color][/color]
this[color=blue][color=green][color=darkred]
>> >> stuff - It makes figuring out the cause of problems[/color]
>> really[color=darkred]
>> >> rather tricky. And its not even a terribly[/color][/color][/color]
complicated[color=blue][color=green][color=darkred]
>> >> object stack. How do I build it?
>> >>
>> >
>> >
>> >.
>> >[/color][/color]
>
>
>.
>[/color]