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.
Related
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.
I have small projects that are alike, using the same class,
I keep the same file in every project, But when I want to make a change, I have to visit all my projects and update them.
While developing a project in Delphi, I would put my related class in just one directory , I would just update in that class and build all of them, all projects would be updated at the same time
how do i do this in visual studio , I made a project group, I added a class to the group, but the projects in the group cannot access this class. How should I use a method?
common class I will use in all projects , 2nd and 3rd other projects, there is more
You should start with a class library (dll) project with your shared code, then add reference to that project/library on the projects you'll need to consume it.
Here's a Microsoft tutorial about this:
https://learn.microsoft.com/en-us/dotnet/core/tutorials/library-with-visual-studio
You can create new project of dll library. This library can be referenced by all other projects. This is way how you can use the same interface in all other projects.
I need to implement 2 set of plugin libraries with exactly the same code for 2 different external applications (I have no control of the external applications). Both applications expose .net classes with exactly the same API in different namespaces.
MyLibrary1 references VendorLibrary1
MyLibrary2 references VendorLibrary2
Both VendorLibrary1 and VendorLibrary2 expose SomeClass (class has the same name) with exactly the same methods.
How can I avoid the need to maintain 2 sets of identical source files (project files, references, cs files etc) which only differ in the using statements and references?
I already have 3 solution ideas which I consider too complicated so I am looking for something simpler/more elegant way of achieving this.
Solution 1
Somehow create wrappers around the vendor libraries which allows switching the library using DI or some other means. The vendor libraries expose 100+ classes and most of them I am using so this is a considerable work and wrapping everything and using wrapped types in method signatures can quickly make this very complicated.
Solution 2
Use #if compiled defines in the using statements. Eg.
#if VENDOR1
using Vendor1NameSpace;
#else
using Vendor2NameSpace;
#endif
Put all classes in one shared project and create 2 libraries, one library defines VENDOR1 and references VendorLibrary1 and the other defines VENDOR2 and references VendorLibrary2
I would need to create 2 sets of of all of my libraries, one for VENDOR1, one for VENDOR2
I think from this point on I need to maintain the using statements manually, can not rely on Resharper.
Solution 3
Implement the library against VendorLibrary1 and use a script which duplicates the solution. While duplicating the solution project references and namespaces in using statements are changed from VendorLibrary1 to VendorLibrary2, Vendor1NameSpace to Vendor2NameSpace etc.
I have created a simple code generator which implements solution 3. Code is developed against Vendor1 libraries and the code generator duplicates the library (project files with new name and source files) for Vendor2. It replaces referenced dlls in the project file and replaces namespaces in the source files. Works well.
I'm working on an application that loads in plugins through Assembly.Load. I want to make sure plugins DLLs don't contain more compiled code then they need. Currently I've got 2 projects:
Application
MyPlugin
MyPlugin has a class implementing IPlugin from the Application project, and references the project to do so.
Is this the correct way to do it or should I put IPlugin (along with interfaces for anything plugins need access to) in a separate project, or is there some other better way to do it?
I would definitely create a new project containing only the contracts (interfaces) which could be referenced by the plugin projects. Besides, take a look at MEF
this is a great way to create a plugin architecture in .NET. And it also is a part of .NET.
Honestly, I can't word my question any better without describing it.
I have a base project (with all its glory, dlls, resources etc) which is a CMS.
I need to use this project as a base for othe custom bake projects.
This base project is to be maintained and updated among all custom bake projects.
I use subversion (Collabnet and Tortise SVN)
I have two questions:
1 - Can I use subversion to share the base project among other projects
What I mean here is can I "Checkout" the base project into another "Checked Out" project and have both update and commit seperatley. So, to paint a picture, let's say I am working on a custom project and I modify the core/base prject in some way (which I know will suit the others) can I then commit those changes and upon doing so when I update the base project in the other "Checked out" resources will it pull the changes? In short, I would like not to have to manually deploy updated core files whenever I make changes into each seperate project.
2 - If I create a custom file (let's say an webcontrol or aspx page etc) can I have it compile seperatley from the base project
Another tricky one to explain. When I publish my web application it creates DLLs based on the namespaces of projects attached to it. So I may have a number of DLLs including the "Website's" namespace DLL, which could simply be website. I want to be able to make a seperate, custom, control which does not compile into those DLLs as the custom files should not rely on those DLLS to run. Is it as simple to set a seperate namespace for those files like CustomFiles.ProjectName for example?
Think of the whole idea as adding modules to the .NET project, I don't want the module's code in any of the core DLLs but I do need for module to be able to access the core dlls.
(There is no need for the core project to access the module code as it should be one way only in theory, though I reckon it woould not be possible anyway without using JSON/SOAP or something like that, maybe I am wrong.)
I want to create a pluggable environment much like that of Joomla/Wordpress as since PHP generally doesn't have to be compiled first I see this is the reason why all this is possible/easy. The idea is to allow pluggable themes, modules etc etc.
(I haven't tried simply adding .NET themes after compile/publish but I am assuming this is possible anyway? OR does the compiler need to reference items in the files?)
UPDATE (16/05/2010):
I posted a similar question with a little more detail for question 2 on Experts-Exchange. I don't want to post all that info here as it just will be too messy but it explains question 2 in greater detail.
For your first question, you want to use svn externals. More details can be found here: http://svnbook.red-bean.com/en/1.0/ch07s03.html
For your second question, you need to create a seperate assembly and the easiest way is to create a new project within your solution. You can't have a single project emit 2 dll's (that I know of)
For your first question:
If the base project is a library then there is nothing stopping you from creating the following directory structure on your SVN:
Base project
Cool project nr 1
Cool project nr 2
All projects built on the Base project will include a relative reference and then everybody can checkout his Cool project X and the Base project and work on them. Checking-in changes for Base project will allow everybody else to see them by updating their Base project image. Advantage: only one SVN trunk required.
For your second question :
I tried my best, but I can't understand what you're asking :).