0

I'm writing a extension-based program where you can add a module to it by inserting a compatible DLL into a folder titled "Modules". I've figured out how to access the relative-located extensions without explicit references (and that took quite a while of playing with reflection).

The program will come in two versions. One with a GUI, and one as a console application. They both will serve the same purpose and do the same things but they target different audiences (some prefer use a Console Application while others like a Windows Form), so they both need access to the same methods. My solution to that was to create a core library DLL which contains all the necessary methods which both versions will 100% be using.

Modules also use the Core DLL and therefore the Core DLL needs to be in the same folder as those modules.

My problem is I want to access this Core DLL from the Modules folder, but I don't want to have to have a program.exe.config lying around, because that config somewhat nullifies the purpose of having the Core library in the Modules folder.

using Core;

namespace Placeholder {
    class Program {
        // Code goes here
    }
}

I need to keep that using directive, but I want it to look for the DLL in the Modules folder. The directory tree for the program would always be as follows:

Root
|- Program.exe
|- ProgramGUI.exe
|- Modules/
   |- Core.DLL
   |- Any other extensions

From what research I've done, there isn't any actual way to do what I'm asking, but none of the questions I've found are specifically asking what I want to know either. I felt I should ask directly, just to be sure.

To clarify:

  • I NEED the Core using directive. There is no way around this.
  • I do not want to have to have a Program.exe.config
  • I want the Core DLL in the Modules folder, which will always be relative to both versions of Program.

    • Is there any way to do what I am asking?

    In the event that there isn't, is it possible to package the Program.exe.config with both versions of the program and have it extracted from the program before using directives are resolved, or must it be shipped outside the program?

    If you need specific code samples please ask and I will provide.

    Thanks.

    dbc
    • 104,963
    • 20
    • 228
    • 340
    Xyrhen
    • 1
    • Why don't you just add `Core` as a dependency to each module? That way it's embedded in the .DLL of each module. – CthenB Jul 10 '17 at 15:25
    • 2
      `using` deals with namespaces, not assemblies. Anyway, you can use [Assembly.LoadFrom](https://msdn.microsoft.com/en-us/library/1009fa28.aspx) before you actually invoke anything from the dll. See also [AppDomain.AssemblyResolve](https://msdn.microsoft.com/en-us/library/h538bck7.aspx) – Jester Jul 10 '17 at 15:35
    • Since you misunderstand what `using` does in the first place, it is not clear what sort of answer you would consider appropriate here. A `using` directive does not, as you seem to believe, have any similarity whatsoever to e.g. `#include` in C/C++, and doesn't have _anything_ to do with where on disk a referenced assembly is found. The best way to make sure assemblies can be found is to simply deploy them with the program; i.e. make sure all the assemblies are in the same directory with the program. This happens by default when you build in Visual Studio. – Peter Duniho Jul 10 '17 at 15:54
    • @Chrontenise I'm trying to avoid unnecessarily increasing the filesize of each modular extension. If the Core DLL is already in the same folder they can already gain appropriate access. – Xyrhen Jul 10 '17 at 17:14
    • @Jester Would your method permit me to natively run methods inside Core as if they were parts of a referenced class/namespace? For example: Core contains method `Cat()`. Could I run that method with `Core.Cat()` in my code? – Xyrhen Jul 10 '17 at 17:16
    • @PeterDuniho if I remove Core.DLL from the location of my application it does not start because it cannot find the required item. There is obviously some relation to where on the disk it is. What I need to do is reference Core.DLL and use all its methods in my code (like described in the above reply) without it having to be on the same directory level as the executable. Is this possible or do I have to have Core.DLL in the same directory as the executable? – Xyrhen Jul 10 '17 at 17:19
    • _"What I need to do is reference Core.DLL and use all its methods in my code...without it having to be on the same directory level as the executable"_ -- why? _"Is this possible"_ -- yes, it's possible, it's just that the `using` directive has _nothing_ to do with how to achieve it. The comment above (from Jester) refers you to run-time mechanisms you can use. Another approach would be to install the DLL in the GAC (but that's a bit of a sledge-hammer solution). The _best_ solution is to abandon the goal, and to just put a copy of the DLL in the program directory. – Peter Duniho Jul 10 '17 at 17:32
    • @PeterDuniho I'm trying to minimise file usage. I don't want to have to use an App.config. At present it does look as though abandoning the actual goal and integrating the solution Chrontenise offered into each of my modular extensions is the best course of action. I wanted to clarify that there wasn't a way of doing what I wanted before I go that route though. – Xyrhen Jul 10 '17 at 17:42
    • _"I'm trying to minimise file usage"_ -- why? How large is the DLL? How large is your disk? Is the savings in disk space really worth the expenditure of your time and the complication of the code? Note that it is non-trivial to implement the suggestion you're referring to; VS won't by default actually embed a referenced DLL into another. You would need to ilmerge.exe to do that. – Peter Duniho Jul 10 '17 at 17:44
    • I think I somewhat had a similiar problem as I wanted to write pluggable extension and load them into my application. If I understand correctly, you want the dll to be in a seperate location, should work with reflection like [here](https://stackoverflow.com/questions/44312597/get-methods-and-attributes-from-dll-assembly). In my third code snippet I use local path, but you can concatenate a sub directory too. Then it'd be best to keep an array of `MethodInfo`, but as you can see: invoking is less comfortable. Suggestion for easier calls: maybe you can make delegates out of the MethodInfo calls –  Jul 10 '17 at 21:49

    0 Answers0