We Keep Coding

C#: Controllers in a re-usable library with the .net core framework

I've written all the classes and controllers for a web api to interact with a very large database (dozens of tables and controllers). I need to write a lot of small apps for specific tasks, as such, it would be idea if the controllers could also be a library file.
I've seen some old tutorials that suggest this is possible, but they no longer seem to work.
Could anyone please point me to somewhere that explains how this can be achieved; or, if there's a better best practices approach I should be taking.
Have all the object classes in their own library, and a working web app that interacts with the database. Want to extra the controllers into a library or include them in the existing object classes library.

By placing controllers in the library, do you mean having generic controllers so you can reuse them whenever you want for whatever model you need? Of so, you can check my library https://github.com/Ryukote/CoreGenerics which is also available on Nuget so you can add it to your project and use it as is.

Sharing controller and views between projects

I am trying to create a good infrastructure for my web framework I am developing I have the following structure so far
solitude.admin web project to keep the controlers and views in how do I create this one I created a class libary but see you cannot have a web.config there
solitude.core will contain all my utililties and models
solitude.framework will be the core and meat of the cms platform my quesiton is how does one create a class libary project for asp.net mvc 4.6 to allow controllers and views to be shared i addded razor to a dll but i dont think that is correct approach
solitude.mvc this will contain the front end of the site i tried the below changing project guids to allow the sharing but its not working
I also changed the project type guids as suggested on aricltes on so but no joy I am trying to mimic our other platforms already work to futher my understanding.
<ProjectGuid>{152C761A-DD2E-4C1F-AF89-DFB2547A3BCA}</ProjectGuid>
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>solitude.admin</RootNamespace>
<AssemblyName>solitude.admin</AssemblyName>
<TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
Another point is if I was two have two sep projects admin and web how would one tell it to go to admin if user types www.domain.com/admin but yet be two independent web projects?.

I totally understand you. I'm in the same situation. I suggest you take a look at AREAS. I'm still learning it, but for what I've googled, it is the proper way to share views and controllers between projects.
This is one good link

I see good the separation of concerns. But have some questions:
1.- Why not making "solitude.admin" another web app project?
2.- Why aren't you using the expected naming conventions? That is a lot of lowercases you got there.
3.- Why would you like/need to share Controllers? Basically, there must be a
return View();
inside them.
For views, you could create some components based on parameters (which mostly, it comes to print out some HTML). You already have Shared Views but for the same project.

Is this an appropriate way to start sharing code across mutliple mvc apps?

We are developing multiple applications for the same company.
The applications are distinct (so not suitable for a multi-tennant app) but there will be lots of shared models, a couple of shared controllers and ideally some shared views.
It is the first time I have had to do this, and wonder if I am approaching it correctly. Here is my plan:
Create a DB for the shared stuff, and another (per application) for application specific stuff
Each application will have 2 connections in web config
Create a DLL from the shared models and controllers. Put this in the /bin directory and reference it in the project. I want this to approximate the way a nuget package might work, and reference the
For each app create a SharedApplicationDBContext and a LocalApplicationDBContext, each accessing the respective DB.
Questions
Are the above steps the right ones to be taking?
Is there any way to include cshtml Views in a DLL?
Is it ok to include the Users controller / models in the DLL?
Are there any gotchas I should be aware of when sharing code like this over mutliple apps?
I know SO likes specific questions, and this is a bit vague, but I'm a bit out of my depth here and looking for some general guidance as to the right approach to take.

You've got the general idea, but it needs some tweaking:
Don't fool around with DLLs. If the projects exist in the same solution, then you might as well keep your class library there as well. In which case, you can just do a straight project reference. If you're dealing with multiple solutions then you package your class library as a nuget package and actually install it in each project. Creating a nuget package is easy enough, and you can either install from a local/network path or you can set up your own private nuget repo. This makes it stupidly easy to share resources, and you get the ability to publish updates and see at a glance which projects are running which versions of your class library.
Each app should only have the context that relates to its individual database. The shared database can also use a shared context, which would be contained in your class library. You should also house all your migrations related to this shared context in the same class library.
You can include views in a class library, but not as cshtml. They have to be compiled into the class library. You'll need RazorGenerator to accomplish this.
It's 100% okay to include the models related to users in your shared library. However, the controller is trickier. Unless you set up an SSO server that will alone be responsible for handling all authentication (a non-trivial task to say the least), each application will need it's own controller for authentication tasks. If all of the sites will reside on the same domain or subdomains thereof, you can easily share the auth cookie between them. However, if they will reside on entirely different domains, you can still share the same "users", by virtue of using the same database for each, but each site will require a separate login process (logging in at one does not log you in at another, even though the same credentials would work for both). The only way around that is, again, SSO.

For what concerns the views, you can include them in a DLL, please read here
For the models it's ok to have them in a different project.
For the controllers you can do it but you must let MVC know where the controllers will be located and you can do it by writing a custom ControllerFactory, please read more here.

Not all namespaces coming across over WCF reference

I have 3 projects in my solution.
A common class library named ReportBuilderLib
A WPF application named ReportClient that contains a service reference to a 3rd project -
A WCF web service which contains web methods for my application to call upon.
Initially when setting up both the service and the application i added the common library to references on both projects so that i could use the classes i needed to in both.
It quickly cam clear that in the process of generating the code to use the web methods in my client application, it was automatically importing certain namespaces that i had used in service application.
This was throwing me conflicting reference warnings as they were effectively being imported from two separate resources.
I then removed the reference to the library in my report client, i could see that VS was only importing one out of the two namespaces my client requires. Both of which are returned by methods in my ServiceContract!
Having looked at the generated code for the client, it seems to be re-creating the classes i have included in the library and providing only the public properties for access.
Is it possible to use librarys like i am trying to with WCF. Or should i scrap the common library idea and simply create some data transfer classes on the service end?

You should be able to reference the common library on both ends, but it may be useful and less of a headache to implement data transfer classes like you suggested. Using special classes (or serialization like JSON) to send and receive data from the service would make it easier for you to re-use the service for multiple client projects.
Any time you decrease the coupling between layers of an application you make it easier to implement changes/upgrades in the future :)

Best Project Template to use for Classic Web Service

I'm going to create a new PayPal project. Should I just create a regular Class Library project then add the reference to the WSDL? We are not using WCF. I just want to know what the best project type / template I should use if I'm going to share this project with lets say another WAP web project. I simply want to create wrappers for some of the WSDL that we'll be using in part of the PayPal API.

Yes a class library project seems the right thing to use if you're wrapping the code that consumes a web service.
Unless it's going to be tiny (say, just one class) in which case you might want to include it in an existing common project that is already used by both of your consuming projects, just to keep everything a little simpler.