problem using ... "nested" DLL's ... a DLL referenced inside another DLL ?
-
The terse descriptions here apply to WinForms "classic," not WinForms "Core," which I have found unusable, so far. It's easy to write a Windows Class Library that compiles into a .Dll. I can put a static Class in that code, and declare methods with void or return types, or even Extension methods. Using that .DLL in a new WinForms app project is easy: // assuming thew Dll is named ",,, / TestDLL1 // in the WinForms project which has a reference to TestDLL1 // where the static class in TestDLL1 is named: TestDLLExtension using static TestDLL1.TestDLLExtension; Now: what I can't achieve. 1) I write another Class library, named 'ExtensionsLibrary,' that has a reference to TestDLL1 2) I now add a reference to the ExtensionsLibrary DLL tto the WinForms project. 3) the WinForms project has the refrencee to TestDLL1 removed. I can't find any way to use 'using that allows me to access/use the static methods in TestDll1 referemced by ExtensionsLibrary. In other words, I cannot achieve an "outer" DLL that has referrences to other, "inner," DLL's. Perhaps my error is in thinking this is possible ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
The terse descriptions here apply to WinForms "classic," not WinForms "Core," which I have found unusable, so far. It's easy to write a Windows Class Library that compiles into a .Dll. I can put a static Class in that code, and declare methods with void or return types, or even Extension methods. Using that .DLL in a new WinForms app project is easy: // assuming thew Dll is named ",,, / TestDLL1 // in the WinForms project which has a reference to TestDLL1 // where the static class in TestDLL1 is named: TestDLLExtension using static TestDLL1.TestDLLExtension; Now: what I can't achieve. 1) I write another Class library, named 'ExtensionsLibrary,' that has a reference to TestDLL1 2) I now add a reference to the ExtensionsLibrary DLL tto the WinForms project. 3) the WinForms project has the refrencee to TestDLL1 removed. I can't find any way to use 'using that allows me to access/use the static methods in TestDll1 referemced by ExtensionsLibrary. In other words, I cannot achieve an "outer" DLL that has referrences to other, "inner," DLL's. Perhaps my error is in thinking this is possible ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
For NuGet references, pulling in package A will also pull in all transitive dependencies of package A: NuGet Package Dependency Resolution | Microsoft Learn[^] For assembly references, that doesn't happen. If your project references assembly A, but not assembly B, you won't be able to use any of the methods defined in assembly B. And if you call any methods in assembly A that (directly or indirectly) rely on assembly B, you will get a run-time exception unless assembly B can be located. (eg: The assembly is deployed to the output directory, or the assembly is installed in the GAC.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
The terse descriptions here apply to WinForms "classic," not WinForms "Core," which I have found unusable, so far. It's easy to write a Windows Class Library that compiles into a .Dll. I can put a static Class in that code, and declare methods with void or return types, or even Extension methods. Using that .DLL in a new WinForms app project is easy: // assuming thew Dll is named ",,, / TestDLL1 // in the WinForms project which has a reference to TestDLL1 // where the static class in TestDLL1 is named: TestDLLExtension using static TestDLL1.TestDLLExtension; Now: what I can't achieve. 1) I write another Class library, named 'ExtensionsLibrary,' that has a reference to TestDLL1 2) I now add a reference to the ExtensionsLibrary DLL tto the WinForms project. 3) the WinForms project has the refrencee to TestDLL1 removed. I can't find any way to use 'using that allows me to access/use the static methods in TestDll1 referemced by ExtensionsLibrary. In other words, I cannot achieve an "outer" DLL that has referrences to other, "inner," DLL's. Perhaps my error is in thinking this is possible ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
The
usingstatement establishes a "shortcut" alternative to using the full name of a class: "Form" instead of writing "System.Windows.Forms.Form" each time you want to use it. It doesn't add a namespace to the project - to access those you need to have a refence to the containing assembly. Your ExtensionsLibrary assembly is already built with the reference it needs (and every assembly that uses ExtensionLibrary will need access to the TestDLL1 assembly file in order to work) but that doesn't include the subassemblies when you add a reference to it, sousingdoesn't "know" where to point the shortcut - any more than you can use the full name of a class and the system can work out which .DLL or .EXE file contains it."I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
For NuGet references, pulling in package A will also pull in all transitive dependencies of package A: NuGet Package Dependency Resolution | Microsoft Learn[^] For assembly references, that doesn't happen. If your project references assembly A, but not assembly B, you won't be able to use any of the methods defined in assembly B. And if you call any methods in assembly A that (directly or indirectly) rely on assembly B, you will get a run-time exception unless assembly B can be located. (eg: The assembly is deployed to the output directory, or the assembly is installed in the GAC.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks, Richard. What I am describing does not use NuGet: it has never occurred to me to try and load a DLL via NuGet ... if that is what you are suggesting. In this case, assembly A (DLL) has a reference to assembly B (DLL), and a "using static" using statement to the static class in B. The WinForm app has a reference to A, and I am seeking to call static methods in B from A. If that is not possible, okay.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
The
usingstatement establishes a "shortcut" alternative to using the full name of a class: "Form" instead of writing "System.Windows.Forms.Form" each time you want to use it. It doesn't add a namespace to the project - to access those you need to have a refence to the containing assembly. Your ExtensionsLibrary assembly is already built with the reference it needs (and every assembly that uses ExtensionLibrary will need access to the TestDLL1 assembly file in order to work) but that doesn't include the subassemblies when you add a reference to it, sousingdoesn't "know" where to point the shortcut - any more than you can use the full name of a class and the system can work out which .DLL or .EXE file contains it."I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
Thanks, Griff, imho, "using static" is kind of a different beast: it sure works fine to expose the public static class in a referenced DLL, and its methods ... the "simple" use case I describe first. If a "nested" DLL ... the second example ... is not referenceable, not a problem. You can always make one DLL with multiple static classes, and reference/expose whichever ones you desire ,,, so my question is kind of academic.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, Richard. What I am describing does not use NuGet: it has never occurred to me to try and load a DLL via NuGet ... if that is what you are suggesting. In this case, assembly A (DLL) has a reference to assembly B (DLL), and a "using static" using statement to the static class in B. The WinForm app has a reference to A, and I am seeking to call static methods in B from A. If that is not possible, okay.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
BillWoodruff wrote:
If that is not possible, okay.
Correct. As I said, assembly references don't automatically pull in transitive dependencies, so your WinForms app doesn't actually have a reference to B. I've largely switched to using a private Azure DevOps NuGet feed[^] for cross-solution dependencies. It means other developers can work on my projects without needing to have the correct versions of the referenced assemblies in the same physical or relative path, as well as ensuring that transitive dependencies are always pulled in.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
BillWoodruff wrote:
If that is not possible, okay.
Correct. As I said, assembly references don't automatically pull in transitive dependencies, so your WinForms app doesn't actually have a reference to B. I've largely switched to using a private Azure DevOps NuGet feed[^] for cross-solution dependencies. It means other developers can work on my projects without needing to have the correct versions of the referenced assemblies in the same physical or relative path, as well as ensuring that transitive dependencies are always pulled in.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks, agaib ! As I said to Griff: "You can always make one DLL with multiple static classes, and reference/expose whichever ones you desire ... so my question is kind of academic." Re your use of NuGet and Azure: fascinating; I'm kind of ... by choice ... still using older non-web simple stuff, like WinForms ... other non-technical priorities in my life, now, like staying alive :) Re your signature with quote from Homer: if you happen to be interested in the "mind of Homer," I can send you a link to the most remarkable essay (introduction to a newer translation) on the Attic context out of which Iliad, and Odyssey arise.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, agaib ! As I said to Griff: "You can always make one DLL with multiple static classes, and reference/expose whichever ones you desire ... so my question is kind of academic." Re your use of NuGet and Azure: fascinating; I'm kind of ... by choice ... still using older non-web simple stuff, like WinForms ... other non-technical priorities in my life, now, like staying alive :) Re your signature with quote from Homer: if you happen to be interested in the "mind of Homer," I can send you a link to the most remarkable essay (introduction to a newer translation) on the Attic context out of which Iliad, and Odyssey arise.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
BillWoodruff wrote:
Re your signature with quote from Homer
Wrong Homer. :)
Quote:
Marge: Homer, a man who called himself "you-know-who" just invited you to a secret "wink-wink" at the "you-know-what". You certainly are popular now that you're a Stonecutter. Homer: Oh, yeah. Beer busts, beer blasts, keggers, stein hoists, AA meetings, beer night. It's wonderful, Marge. I've never felt so accepted in all my life. These people looked deep within my soul and assigned me a number based on the order in which I joined.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
BillWoodruff wrote:
Re your signature with quote from Homer
Wrong Homer. :)
Quote:
Marge: Homer, a man who called himself "you-know-who" just invited you to a secret "wink-wink" at the "you-know-what". You certainly are popular now that you're a Stonecutter. Homer: Oh, yeah. Beer busts, beer blasts, keggers, stein hoists, AA meetings, beer night. It's wonderful, Marge. I've never felt so accepted in all my life. These people looked deep within my soul and assigned me a number based on the order in which I joined.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Oh, that Homer :) I nominate this exchange with you for "CP Surreal Posts of the Year." p.s. once you study moods in Homeric Greek, indicative, imperative, interrogative, conditional, and subjunctive ... neurons are ... permanently altered. it took me years to forget them.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
The terse descriptions here apply to WinForms "classic," not WinForms "Core," which I have found unusable, so far. It's easy to write a Windows Class Library that compiles into a .Dll. I can put a static Class in that code, and declare methods with void or return types, or even Extension methods. Using that .DLL in a new WinForms app project is easy: // assuming thew Dll is named ",,, / TestDLL1 // in the WinForms project which has a reference to TestDLL1 // where the static class in TestDLL1 is named: TestDLLExtension using static TestDLL1.TestDLLExtension; Now: what I can't achieve. 1) I write another Class library, named 'ExtensionsLibrary,' that has a reference to TestDLL1 2) I now add a reference to the ExtensionsLibrary DLL tto the WinForms project. 3) the WinForms project has the refrencee to TestDLL1 removed. I can't find any way to use 'using that allows me to access/use the static methods in TestDll1 referemced by ExtensionsLibrary. In other words, I cannot achieve an "outer" DLL that has referrences to other, "inner," DLL's. Perhaps my error is in thinking this is possible ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
To illustrate why my question is academic, and, how simple it can be to have multiple static classes in one DLL, and expose your choice of them and their methods, I offer a terse example: 1) create a WinForm class library with multiple static classes and public static methods: TestDLL_1_1_2023 2) compile it 3) in a WinForm app: reference the compiled DLL. 4) use "static using" statements to expose your choice of methods: // expose string methods using static TestDLL_1_1_2023.StupidStringExtensions; // do not expose numeric methods // using static TestDLL_1_1_2023.StupidNumericExtensions;
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
