Which project's responsibility should it be, to reference DLLs needed by a referenced DLL?
Looking through the web config files for a large solution (50+ projects) I've begun maintaining, I see a reference pattern I don't quite understand
At least 10 of the projects in this solution send emails and hence depend on another project (also in the solution) that produces Mailing.dll
In turn that Mailing project uses Azure queues and some other things. The mailing solution references Microsoft.WindowsAzure.Storage, but not Microsoft.WindowsAzure.Diagnostics (hereafter referred to as WA.D)
I see in the 10 projects that use Mailer/send emails, the references include various versions and source locations of WA.D and every web config file has a binding redirect for WA.D. Compilation warnings about choosing, or unable to choose a version are seen
If I strip out the references from the 10 projects, and strip the binding redirects I get the ASP.NET yellow screen of death complaining that it can't find the WA.D.dll - this was expected because it realises a situation where the WA.D.dll isn't in the output bin directory. In all the cases I looked at, the YSOD was referring to a call to a mailer.dll method as the point of failure, but debug stepping into the mailer would eventually arrive at a call to some windows azure related queue operation
Now, if I reference WA.D.dll from the Mailer project, then everything works again: Mailer builds, a sole version of WA.D dll appears, the other projects function, there aren't any build complaints about multiple versions of assemblies. Mailer genuinely appears to be the thing that relies on a dll that relies on WA.D
The 10 projects don't appear to have a direct dependency on WA.D themselves anywhere else
I'm hence slightly puzzled why the original devs would have not set a reference to WA.D on Mailer (the thing that most directly uses it) and instead set a reference on N number (at least 10) of other projects, that required Mailer but in doing so allowed a mish mash of versions and even inconsistent binding redirects to creep in (some redirects would point requests for 2.9 to 2.2 dll)
Is there an advantage to this approach (top level project that uses mailer, is responsible for referencing WA.D) or should I switch things over so that the lowest possible level of DLL (mailer) is responsible for referencing the assemblies it needs?
Is this project relatively isolated in its affliction because of something peculiar about the azure SDK?
ps; if it's relevant, owing to the fact that we've had issues with the deploy targets not having Azure SDK installed I'm using a set of unofficial NuGet packages that include just the specific Azure DLLs required for this project. Some of this might have come out of the fact that these DLLs aren't officially available on their own
Edit:
Abbreviated solution explorer representation:
Now:
Website1
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website2
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website3
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Mailer --seems to be what really requires windowsazure.diagnostics
+-References
+-WindowsAzure.Storage
Also seems to work:
Website1
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website2
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website3
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Mailer
+-References
+-WindowsAzure.Storage
+-WindowsAzure.Diagnostics
+-app.config
c# dll
asked Nov 27 '18 at 12:50
Caius JardCaius Jard
12k21240
add a comment |
Looking through the web config files for a large solution (50+ projects) I've begun maintaining, I see a reference pattern I don't quite understand
At least 10 of the projects in this solution send emails and hence depend on another project (also in the solution) that produces Mailing.dll
In turn that Mailing project uses Azure queues and some other things. The mailing solution references Microsoft.WindowsAzure.Storage, but not Microsoft.WindowsAzure.Diagnostics (hereafter referred to as WA.D)
I see in the 10 projects that use Mailer/send emails, the references include various versions and source locations of WA.D and every web config file has a binding redirect for WA.D. Compilation warnings about choosing, or unable to choose a version are seen
If I strip out the references from the 10 projects, and strip the binding redirects I get the ASP.NET yellow screen of death complaining that it can't find the WA.D.dll - this was expected because it realises a situation where the WA.D.dll isn't in the output bin directory. In all the cases I looked at, the YSOD was referring to a call to a mailer.dll method as the point of failure, but debug stepping into the mailer would eventually arrive at a call to some windows azure related queue operation
Now, if I reference WA.D.dll from the Mailer project, then everything works again: Mailer builds, a sole version of WA.D dll appears, the other projects function, there aren't any build complaints about multiple versions of assemblies. Mailer genuinely appears to be the thing that relies on a dll that relies on WA.D
The 10 projects don't appear to have a direct dependency on WA.D themselves anywhere else
I'm hence slightly puzzled why the original devs would have not set a reference to WA.D on Mailer (the thing that most directly uses it) and instead set a reference on N number (at least 10) of other projects, that required Mailer but in doing so allowed a mish mash of versions and even inconsistent binding redirects to creep in (some redirects would point requests for 2.9 to 2.2 dll)
Is there an advantage to this approach (top level project that uses mailer, is responsible for referencing WA.D) or should I switch things over so that the lowest possible level of DLL (mailer) is responsible for referencing the assemblies it needs?
Is this project relatively isolated in its affliction because of something peculiar about the azure SDK?
ps; if it's relevant, owing to the fact that we've had issues with the deploy targets not having Azure SDK installed I'm using a set of unofficial NuGet packages that include just the specific Azure DLLs required for this project. Some of this might have come out of the fact that these DLLs aren't officially available on their own
Edit:
Abbreviated solution explorer representation:
Now:
Website1
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website2
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website3
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Mailer --seems to be what really requires windowsazure.diagnostics
+-References
+-WindowsAzure.Storage
Also seems to work:
Website1
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website2
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website3
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Mailer
+-References
+-WindowsAzure.Storage
+-WindowsAzure.Diagnostics
+-app.config
c# dll
asked Nov 27 '18 at 12:50
Caius JardCaius Jard
12k21240
1
Re binding redirects - only the executable .config matters for that; e.g. web.config. All the *.dll.configs will make no difference. Visual Studio liberally adds them which is probably the main reason they're still there. Typically when say one dependency requires foo.v1 and another requires foo.v2, and they're compatible enough for this, you would have a single binding redirect in web.config saying v1-2 maps to v2.
– sellotape
Nov 27 '18 at 13:15
Re the rest, does the app use dependency injection?
– sellotape
Nov 27 '18 at 13:18
i'll add a clarifier that this project contains multiple websites, hence multiple "final" web confgs. It uses DI, castle windsor is the ioc container
– Caius Jard
Nov 27 '18 at 13:18
It is not unusual. You'd have to look in the source control revision list to be sure, but there was a change in the C# compiler around the v4.5 time frame. It became more demanding about being able to recognize types that are exposed through the public interface of a library. Types from WA.D in this case. It matters for overload resolution, previously it treated "don't recognize it" as "not eligible as an overload", that could gast the flabber of a programmer pretty badly. Adding a reference to the assembly that contains that type was the workaround. What you're doing sounds fine to me.
– Hans Passant
Nov 27 '18 at 13:22
add a comment |
Looking through the web config files for a large solution (50+ projects) I've begun maintaining, I see a reference pattern I don't quite understand
At least 10 of the projects in this solution send emails and hence depend on another project (also in the solution) that produces Mailing.dll
In turn that Mailing project uses Azure queues and some other things. The mailing solution references Microsoft.WindowsAzure.Storage, but not Microsoft.WindowsAzure.Diagnostics (hereafter referred to as WA.D)
I see in the 10 projects that use Mailer/send emails, the references include various versions and source locations of WA.D and every web config file has a binding redirect for WA.D. Compilation warnings about choosing, or unable to choose a version are seen
If I strip out the references from the 10 projects, and strip the binding redirects I get the ASP.NET yellow screen of death complaining that it can't find the WA.D.dll - this was expected because it realises a situation where the WA.D.dll isn't in the output bin directory. In all the cases I looked at, the YSOD was referring to a call to a mailer.dll method as the point of failure, but debug stepping into the mailer would eventually arrive at a call to some windows azure related queue operation
Now, if I reference WA.D.dll from the Mailer project, then everything works again: Mailer builds, a sole version of WA.D dll appears, the other projects function, there aren't any build complaints about multiple versions of assemblies. Mailer genuinely appears to be the thing that relies on a dll that relies on WA.D
The 10 projects don't appear to have a direct dependency on WA.D themselves anywhere else
I'm hence slightly puzzled why the original devs would have not set a reference to WA.D on Mailer (the thing that most directly uses it) and instead set a reference on N number (at least 10) of other projects, that required Mailer but in doing so allowed a mish mash of versions and even inconsistent binding redirects to creep in (some redirects would point requests for 2.9 to 2.2 dll)
Is there an advantage to this approach (top level project that uses mailer, is responsible for referencing WA.D) or should I switch things over so that the lowest possible level of DLL (mailer) is responsible for referencing the assemblies it needs?
Is this project relatively isolated in its affliction because of something peculiar about the azure SDK?
ps; if it's relevant, owing to the fact that we've had issues with the deploy targets not having Azure SDK installed I'm using a set of unofficial NuGet packages that include just the specific Azure DLLs required for this project. Some of this might have come out of the fact that these DLLs aren't officially available on their own
Edit:
Abbreviated solution explorer representation:
Now:
Website1
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website2
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website3
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Mailer --seems to be what really requires windowsazure.diagnostics
+-References
+-WindowsAzure.Storage
Also seems to work:
Website1
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website2
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website3
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Mailer
+-References
+-WindowsAzure.Storage
+-WindowsAzure.Diagnostics
+-app.config
c# dll
asked Nov 27 '18 at 12:50
Caius JardCaius Jard
12k21240
Looking through the web config files for a large solution (50+ projects) I've begun maintaining, I see a reference pattern I don't quite understand
At least 10 of the projects in this solution send emails and hence depend on another project (also in the solution) that produces Mailing.dll
In turn that Mailing project uses Azure queues and some other things. The mailing solution references Microsoft.WindowsAzure.Storage, but not Microsoft.WindowsAzure.Diagnostics (hereafter referred to as WA.D)
I see in the 10 projects that use Mailer/send emails, the references include various versions and source locations of WA.D and every web config file has a binding redirect for WA.D. Compilation warnings about choosing, or unable to choose a version are seen
If I strip out the references from the 10 projects, and strip the binding redirects I get the ASP.NET yellow screen of death complaining that it can't find the WA.D.dll - this was expected because it realises a situation where the WA.D.dll isn't in the output bin directory. In all the cases I looked at, the YSOD was referring to a call to a mailer.dll method as the point of failure, but debug stepping into the mailer would eventually arrive at a call to some windows azure related queue operation
Now, if I reference WA.D.dll from the Mailer project, then everything works again: Mailer builds, a sole version of WA.D dll appears, the other projects function, there aren't any build complaints about multiple versions of assemblies. Mailer genuinely appears to be the thing that relies on a dll that relies on WA.D
The 10 projects don't appear to have a direct dependency on WA.D themselves anywhere else
I'm hence slightly puzzled why the original devs would have not set a reference to WA.D on Mailer (the thing that most directly uses it) and instead set a reference on N number (at least 10) of other projects, that required Mailer but in doing so allowed a mish mash of versions and even inconsistent binding redirects to creep in (some redirects would point requests for 2.9 to 2.2 dll)
Is there an advantage to this approach (top level project that uses mailer, is responsible for referencing WA.D) or should I switch things over so that the lowest possible level of DLL (mailer) is responsible for referencing the assemblies it needs?
Is this project relatively isolated in its affliction because of something peculiar about the azure SDK?
ps; if it's relevant, owing to the fact that we've had issues with the deploy targets not having Azure SDK installed I'm using a set of unofficial NuGet packages that include just the specific Azure DLLs required for this project. Some of this might have come out of the fact that these DLLs aren't officially available on their own
Edit:
Abbreviated solution explorer representation:
Now:
Website1
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website2
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website3
+-References
+-WindowsAzure.Diagnostics
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Mailer --seems to be what really requires windowsazure.diagnostics
+-References
+-WindowsAzure.Storage
Also seems to work:
Website1
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website2
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Website3
+-References
+-Mailer
+-Web.config --dependency/redirect to windowsazure.diagnostics
Mailer
+-References
+-WindowsAzure.Storage
+-WindowsAzure.Diagnostics
+-app.config
c# dll
c# dll
asked Nov 27 '18 at 12:50
Caius JardCaius Jard
12k21240
asked Nov 27 '18 at 12:50
Caius JardCaius Jard
12k21240
edited Nov 27 '18 at 13:36
Caius Jard
asked Nov 27 '18 at 12:50
Caius JardCaius Jard
12k21240
asked Nov 27 '18 at 12:50
Caius JardCaius Jard
12k21240
asked Nov 27 '18 at 12:50
Caius JardCaius Jard
12k21240
12k21240
1
Re binding redirects - only the executable .config matters for that; e.g. web.config. All the *.dll.configs will make no difference. Visual Studio liberally adds them which is probably the main reason they're still there. Typically when say one dependency requires foo.v1 and another requires foo.v2, and they're compatible enough for this, you would have a single binding redirect in web.config saying v1-2 maps to v2.
– sellotape
Nov 27 '18 at 13:15
Re the rest, does the app use dependency injection?
– sellotape
Nov 27 '18 at 13:18
i'll add a clarifier that this project contains multiple websites, hence multiple "final" web confgs. It uses DI, castle windsor is the ioc container
– Caius Jard
Nov 27 '18 at 13:18
It is not unusual. You'd have to look in the source control revision list to be sure, but there was a change in the C# compiler around the v4.5 time frame. It became more demanding about being able to recognize types that are exposed through the public interface of a library. Types from WA.D in this case. It matters for overload resolution, previously it treated "don't recognize it" as "not eligible as an overload", that could gast the flabber of a programmer pretty badly. Adding a reference to the assembly that contains that type was the workaround. What you're doing sounds fine to me.
– Hans Passant
Nov 27 '18 at 13:22
add a comment |
1
Re binding redirects - only the executable .config matters for that; e.g. web.config. All the *.dll.configs will make no difference. Visual Studio liberally adds them which is probably the main reason they're still there. Typically when say one dependency requires foo.v1 and another requires foo.v2, and they're compatible enough for this, you would have a single binding redirect in web.config saying v1-2 maps to v2.
– sellotape
Nov 27 '18 at 13:15
Re the rest, does the app use dependency injection?
– sellotape
Nov 27 '18 at 13:18
i'll add a clarifier that this project contains multiple websites, hence multiple "final" web confgs. It uses DI, castle windsor is the ioc container
– Caius Jard
Nov 27 '18 at 13:18
It is not unusual. You'd have to look in the source control revision list to be sure, but there was a change in the C# compiler around the v4.5 time frame. It became more demanding about being able to recognize types that are exposed through the public interface of a library. Types from WA.D in this case. It matters for overload resolution, previously it treated "don't recognize it" as "not eligible as an overload", that could gast the flabber of a programmer pretty badly. Adding a reference to the assembly that contains that type was the workaround. What you're doing sounds fine to me.
– Hans Passant
Nov 27 '18 at 13:22
1
1
Re binding redirects - only the executable .config matters for that; e.g. web.config. All the *.dll.configs will make no difference. Visual Studio liberally adds them which is probably the main reason they're still there. Typically when say one dependency requires foo.v1 and another requires foo.v2, and they're compatible enough for this, you would have a single binding redirect in web.config saying v1-2 maps to v2.
– sellotape
Nov 27 '18 at 13:15
Re binding redirects - only the executable .config matters for that; e.g. web.config. All the *.dll.configs will make no difference. Visual Studio liberally adds them which is probably the main reason they're still there. Typically when say one dependency requires foo.v1 and another requires foo.v2, and they're compatible enough for this, you would have a single binding redirect in web.config saying v1-2 maps to v2.
– sellotape
Nov 27 '18 at 13:15
Re the rest, does the app use dependency injection?
– sellotape
Nov 27 '18 at 13:18
Re the rest, does the app use dependency injection?
– sellotape
Nov 27 '18 at 13:18
i'll add a clarifier that this project contains multiple websites, hence multiple "final" web confgs. It uses DI, castle windsor is the ioc container
– Caius Jard
Nov 27 '18 at 13:18
i'll add a clarifier that this project contains multiple websites, hence multiple "final" web confgs. It uses DI, castle windsor is the ioc container
– Caius Jard
Nov 27 '18 at 13:18
It is not unusual. You'd have to look in the source control revision list to be sure, but there was a change in the C# compiler around the v4.5 time frame. It became more demanding about being able to recognize types that are exposed through the public interface of a library. Types from WA.D in this case. It matters for overload resolution, previously it treated "don't recognize it" as "not eligible as an overload", that could gast the flabber of a programmer pretty badly. Adding a reference to the assembly that contains that type was the workaround. What you're doing sounds fine to me.
– Hans Passant
Nov 27 '18 at 13:22
It is not unusual. You'd have to look in the source control revision list to be sure, but there was a change in the C# compiler around the v4.5 time frame. It became more demanding about being able to recognize types that are exposed through the public interface of a library. Types from WA.D in this case. It matters for overload resolution, previously it treated "don't recognize it" as "not eligible as an overload", that could gast the flabber of a programmer pretty badly. Adding a reference to the assembly that contains that type was the workaround. What you're doing sounds fine to me.
– Hans Passant
Nov 27 '18 at 13:22
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53500146%2fwhich-projects-responsibility-should-it-be-to-reference-dlls-needed-by-a-refer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53500146%2fwhich-projects-responsibility-should-it-be-to-reference-dlls-needed-by-a-refer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Re binding redirects - only the executable .config matters for that; e.g. web.config. All the *.dll.configs will make no difference. Visual Studio liberally adds them which is probably the main reason they're still there. Typically when say one dependency requires foo.v1 and another requires foo.v2, and they're compatible enough for this, you would have a single binding redirect in web.config saying v1-2 maps to v2.
– sellotape
Nov 27 '18 at 13:15
Re the rest, does the app use dependency injection?
– sellotape
Nov 27 '18 at 13:18
i'll add a clarifier that this project contains multiple websites, hence multiple "final" web confgs. It uses DI, castle windsor is the ioc container
– Caius Jard
Nov 27 '18 at 13:18
It is not unusual. You'd have to look in the source control revision list to be sure, but there was a change in the C# compiler around the v4.5 time frame. It became more demanding about being able to recognize types that are exposed through the public interface of a library. Types from WA.D in this case. It matters for overload resolution, previously it treated "don't recognize it" as "not eligible as an overload", that could gast the flabber of a programmer pretty badly. Adding a reference to the assembly that contains that type was the workaround. What you're doing sounds fine to me.
– Hans Passant
Nov 27 '18 at 13:22