DLL - Using main project classes in library class - c#

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.

Related

WPF Application = Exe + DLL + Custom Visualizer ? Can I do all 3 of them?

As the title says, I have a WPF form that I want to build in 3 separate projects:
A Windows application, used standalone by clicking the .exe file
A GUI control that can be imported and used in some other projects (dll)
A Custom Visualizer, that can also be used to view a collection of some specific types (dll)
The interface and all the functionality will be the same(identical) between the 3 projects
My questions are the following:
Can this be achieved by making only one project? Or do I have to make 3 separate projects?
If there is not other way but to make 3 separate projects, how can I have the logic for the controls in a separate project common for all of them?
All the logic is now in the controls events (MouseWheel, button click etc)
I need to use net framework 4.7.2 (or 4.8). Can I make all the projects with this? Or can I also use .net 6.0 on some of them?
Thank you
In such case, you can use a Shared Project. Add a Shared Project (case-sensitive) to your solution and reference that project from other pojects. Then you can access the code inside the Shared Project from other projects as if the code belongs to each of other projects.
Shared Project is often explained in the context of sharing the codes among different platforms but it could be useful for other purpose as well.

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.

VS 2019 C# intellisense not suggesting references from within solution

I'm new to programming so I might not be using some of the correct terminology. I'm running into an issue with InteliSense when calling a C# class from another project within the same solution. It's not suggesting a using statement and is instead trying to get me to create a new class inside of the current project which is not what I want. I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
I looked at some of the documentation online and nothing has helped so far. InteliSense appears to configured correctly to suggest using statements. It provide suggestions just fine. I've been able to create lists and then use it to add the proper using statement along with some other things. Just doesn't want to work with anything inside the solution. I've been following a couple of different tutorials including, .net core 2.1 and 3.1, inside MVC and Razor page projects along with a couple just straight C# console apps. It doesn't work in any of them when I start adding multiple projects to the solution and try using classes from outside the current project.
I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
That is the correct behavior. In order for ProjectB to use classes defined in ProjectA, you must first add a reference to ProjectA. Just having the projects in the same solution is not sufficient.
The purpose of having multiple projects in the same solution is simply for grouping related code. The projects may or may not actually depend on each other. For example, a web application may have a separate projects for the actual web UI (the pages themselves), a data access layer, unit tests, maybe some class libraries for shared code used by multiple projects, and maybe even console applications (or some other project type) for performing backend administrative tasks. In this scenario, the web UI and console applications may have references to the data access layer project and/or the class libraries. The unit test project will have a reference to the web UI project, and so on. The dependencies are one-way - you may not have circular references (the unit test project has the web UI project as a dependency, but not the other way).

Is it possible to import class file without converting it to a dll in c#?

There are a lot of variables and methods in my program and I want to seperate some of them in other class files. But as the program grows the methods and functions can change.
I searched on the net but many people generally speaking for dll files. Without making a dll file, how can I arrange my code and split into small class files?
Yes, just split it out in to a separate file in a new class but still inside the same project. The term for what you are doing is called Code Refactoring. There are some tools built in to Visual Studio to make it easier to do, and there are some 3rd party tools that add even more features to make it easier to do.
But all it boils down to is just making new classes in the same project and referencing those new classes from where you took the code out from.
You can add folders to your solution. Classes are by default a namespaceprovider, so that classes in this folder have a different namespace.
For example if your default-namespace is MyNameSpace and you create a folder called Entity then all classes in this folder have the namespace MyNameSpace.Entity
And all Items in a project are compiled to one single dll or exe
Just add more classes to the project and put the data and behavior (methods) into the appropriate classes. The project will still build into a single exe or dll.
Generally, it's better to add a second project under the same solution call it "CommonLib" or something like that. Then you add it as a reference to the main application and set up the project so that the applications build depends on the libraries build. Add a using statement for the common lib where ever you want to use those objects. This is definitely better for large scale or enterprise applications. There's a pretty decent chance that somewhere down the line you'll want to reuse some of this code, if everything builds into a single exe that won't be an option.

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).

Categories