We Keep Coding

Is there an elegant way to separate Plugin Interface and Implementation in C#?

I am developing a C# desktop application that should try to find and consume a plugin hosted in a totally different C# project so that the application does not know anything of the plugin host project and its types.
If the plugin DLL is found in my application EXE folder, I should be able to create an instance of the plugin interface. But to do so in the application, I would need to make the plugin assembly known to the application solution at compilation time, which is not permissible due to the project management issues.
The only way to do it, as far as I can see, is to have two assemblies: the one with the interface only, which can be added to the application solution, and the other one with the plugin implementation.
But is there a possibly more elegant solution?

The only way to do it, as far as I can see, is to have two assemblies: the one with the interface only, which can be added to the application solution, and the other one with the plugin implementation
This is the solution I have used for plugins. The interface project is hosted in the main application solution, with the interface dll either manually copied to the plugin solution, or referenced thru nuget. I'm not aware of any solution that is more elegant.
Changes to the interface will be slightly cumbersome, but this is not necessarily a bad thing since frequent changes to public APIs can be difficult for the user of the API. It is a good idea to have some plan for how different API versions should be handled by the plugin implementation. For example by exposing a version property in the interface that can be used to determine what methods are safe to call or not.

Implement same interface in different projects

I have an API project and a class library project that contains interfaces. So I have a third project that implements interfaces and a project that implements the same interfaces of project 3. Therefore, projects 3 and 4 know about project 2.
My problem is that I want to call the implementations through my class library project (the second), but this project does not know the implementation projects.
How can I call implementation projects through my second project?
The idea is that I have many implementation projects, so I just want to create another new project and implement the interface without having to change the code very much in project 2.
I'm using .NET Core 2.0 in all projects

This is a classic 'plugin' system.
Define the interface in project 2 (the 'hosting' project)
3 and 4 reference 2 in order to get the interface definition (also classically to get services offered by the hosting project)
Now you need to make the host (2) dynamically load the plugins.
You can do this 'by hand'. = Enumerate the DLLs is a specific directory and find the ones that implement the interfce.
Or you can use various frameorks to do it. MEF is a well know one. Look here for more info Implementing Plugin Architecture - Dynamic DLL loading

It is difficult to know exactly what you should do without knowing what you are trying to accomplish, but...
Create a project, call it 2.a that contains just the interfaces. Assuming that Project 2 uses the implementations in both 3 and 4, it takes out a reference on 2.a, 3 and 4.

Creating reusable code modules (e.g. C++ style classes, headers) in C#

In C++, you can create usable code modules by creating a class, and giving out header and implementation files to the developers who want to use your class.
I want to do this in C# but I have little experience with the C# language. Basically I need to create a class that can be reused by another C# programmer in Visual Studio 2010. I know that referencing DLLs is one way to use other peoples' classes. Do I need to create a DLL to achieve what I want to accomplish? Or are there other, better ways?
For example, let's say I create a Cow class that can "moo". In C++, someone who uses my class would just include Cow.h, instantiate a Cow object myCow, and then call myCow.moo(). How can I achieve this simple task in C#?
Thanks for your time and patience.

Yes, just create Class Library project and share the resulted dll's.
Other developers will just need to add a reference to your dll and after that they're free to use any public objects from your library.

It is the standard to create a dll to distribute reusable code.
You could look into old school COM objects, but I would steer clear of them and just use a well organized class library.

Of course you can always share your source files, but the recommended .Net way of distributing reusable code is though dlls. This allows developers using any .Net language to use your code (they don't have to use the same language as your project).
It also makes it easier to maintain the project. If you share source code then it will likely be more difficult to distribute updates than if you just needed to update a single dll. If you have multiple projects referencing the same dll, they can all reference it from the same location and whenever the dll is updated, all the projects that use it will automatically use the updated dll the next time they compile the project. You can also update the dll without having to recompile the projects that use it (though you can't change the names/signatures of anything that is being used by the project).

c# plugin system question

so I implemented a really simple plugin system.
i have the following Assemblies:
MainApp
IPlugin
PluginApp
Both MainApp and PluginApp conatin a reference to the IPlugin. Now, in MainApp I scan a plugins folder and search for things that implement the IPlugin interface.
However, it is not working because both MainApp and PluginApp reference their own copy of IPlugin.dll so they are not recognized as a match when using Type.IsAssignableFrom()!
help?

You could try putting your code that defines the plugin into a satellite dll assembly. That way both your main code and the plugins reference the same types.
If the plugin can maintain it's own dll instead of using the same dll as the application you will run into versioning issues. How will your main app handle calling plugins that don't implement the same interface?
When we did this in our own software we had to resort to reflection method calls instead of casting to the interface. It wasn't elegant.
What about adding the assemblies dll into the plugin directory. They have to reference the dll when they create their application, but force them to use the main assemblies version of the dll when the plugin is actually run?

DLL - Using main project classes in library class

I've never tried separating down my projects into DLLs but something I'm working on at the moment calls for a more modular approach. What I want to be able to do is switch out versions of a number of my classes easily to push updates to users without them having to re install my entire application.
These classes create instances of other classes which are defined within the application and shouldn't be part of the modules which are switched in and out - they're central. Obviously in the class Library project these classes are undefined as they are only defined in the main application. How do I go about enabling the class library to use these main application classes?
All help is much appreciated.