We Keep Coding

How to create and manage subsites from main site in ASP.NET Core 6 MVC?

We have created multiple application solutions in ASP.NET Core 6 MVC.
I want to use each solution under a single solution so that I can use common menus/submenus in all applications.
Also not sure how will handle session in this case.
Example: we have created 4 separate solution modules for Admin, Employees, Department, Students.
Now I am creating a new Login solution which will have login functionality and menus.
I tried by creating DLL for each solution and referencing in Login solution but it's not working properly also static files are not getting added.

All modules for a single application should rather go in a single solution with multiple projects, if feasible. Each project yields a binary assembly that can be directly referenced in other projects. This prevents code duplication by allowing multiple projects to reference the same code. Using multiple solutions can lead to problems regarding referencing paths. There is also a big drawback of spliting your application into multiple solutions: your application's code cannot be accessed in full in the development environement, making refactoring harder.
Since Visual Studio 2022 is now 64bit, you can have solutions with a large amount of projects with little performance drops.
If you really need to have dependencies across multiple solutions, you should turn towards nuget. Nuget is the package manager for dotnet. After compiling a project, you provide some metadata to create a package. Then you publish the package to the repository. Other solutions can reference the package and the linker will download the binaries from the repository. Nuget packages support semantic versioning and you can reference specific versions of a library.
However, this will require you to write your code like a quality library. It means early design thinking, strong QA, and heavy testing are required so you don't ping-pong updates between your libs and their clients. This is why this strategy is more designed towards sharing libs accross multiple applications.
There are also on premises solutions if you don't want to upload your binaries to the internet. You can create a nuget repository as simply as creating a new directory and adding the path to the list of nuget packages references sources in Visual Studio. Nuget packages can be shared across your intranet using a simple SMB fileshare. If you need better access control, you can install a local copy of NugetGallery.
Details on nuget usage are availble in Microsoft documentation about nuget.

Where can i find NuGet.Clients documentation?

I'm trying to add Nuget package management to my newly developed IDE.
The github repository seems to have UI components here
but i can't find any resources for how to use it.
the only documentation i can find doesn't say anything about UI components

As devNull pointed out, there is a page in the docs saying that certain packages on nuget.org are provided and usable in your project. But this roughly corresponds to the projects under src\NuGet.Core.
The projects under src\NuGet.Clients are tools that we distribute as a product, but are not intended to be a library or reusable. The UI components are extremely tied to Visual Studio, depending on several other components in Visual Studio, so you would have to implement all the dependencies to be able to use the UI. In my opinion you'd be better off using the core packages and build your own UI on top of them.

The Nuget-Client-SDK doc states:
The API is evolving and not yet documented, but examples are available
on Dave Glick's blog.
So it appears that the blog post that you mentioned is the extent of documentation currently available for that library.

Reference error when deploying MVC website on server that imports a .NET standard class with a system.data.sqlclient reference

This is my first question. I have tried really hard to find a solution to my problem, but it seems to be a pretty specific collection of problems and I haven't found anything that works. I think I have narrowed down/identified my problem, but I don't know the solution or how to implement it correctly. I have tried to be detailed, but also concise. I don't have a strong coding theory background, just what I have learned online from MS documentation, Stack overflow, and other tutorial-like websites.
Background
In visual studio I wanted to create a class library that manages tables in a given database. It's part of a generic style API to handle implementations of repetitive database structures across projects. Because I wanted to create a generic class that I could use in various projects utilising various .NET frameworks, I decided to build the class using .NET standard 1.4. Because I needed to connect to MS SQL databases, I imported the System.Data.SqlClient namespace (an System.Data.Common) using NuGet.
I employed the use of a test MVC application in the solution and got some basic functions working in Visual Studio including opening the actual databases. Despite the recommendation not to, I referenced the compiled DLL from the release build rather than importing the reference as a project. I did this to mimic how I would be testing the class in my deploy environment. Everything here worked fine provided I added the reference to System.Data.SqlClient in the test application.
When testing the deployment however, things went awry. I was using an FTP connection to copy the files to the server. The server is running the .NET 4.5.2 framework. I kept getting a persistent error that the System.Data.SqlClient version 4.1 could not be found. I tried importing it into the project using NuGet and still had the problem. I was importing version 4.1, the earliest version (which is what I referenced in the class library). I also tried changing the reference in the class library to 4.4.2, the latest version, and importing that instead. Still had the same problem.
I then copied the code from the C# class from the class library and added it to a new .cs file in the FTP project- it compiled and ran without incident. I didn't need to import the System.Data.SqlClient in order to reference it, suggesting that a version of the namespace is already available on the server.
Problem/Question
This leads me to believe that there is a conflict where I'm trying to reference 2 different versions of System.Data.SqlClient within the FTP project.
As such, this leaves me to try and work out either:
How can I build a .NET standard class library that can use the latest installed version of System.Data.SqlClient in the target project (although, I fell like this is not really achievable given the way DLLs/versioning in general works)?
OR
How can I build a .NET standard class library that can use any of the currently available versions of System.Data.SqlClient (i.e. only use APIs that all current versions implement) and target the one already installed/referenced in the project that references it?
OR
How can I tell visual studio to include the referenced System.Data.SqlClient version used in my standard class library and only reference it for the purposes of running this library, with the rest of the project targeting whatever the other version may be?
OR
The otherwise correct way to manage this reference when it is not in the .NET standard library, but may be present in any given version in the application that references my library DLL.
Basically, I want to avoid having to write a new version of this class for every target framework if I don't have to.
End Note
I hope this question is of a good standard, I feel I have probably gone about something wrong in the implementation and that advice on the proper way to implement such a library would be of great help to myself and others in a similar situation.

Adding reference of another external project in a solution

Using: .net core mvc c#
I have a solution which has a .net mvc core web app & one class library. There is a shared project (class library) that I want to this solution
which is a part of different project (different solution as well).
All of these projects are stored in our local GIT repository.
If I add the external project as project dependency in my existing project then there would be 2 copies of the external project that we have to
maintain. If some developer updates external project how does the change propogates to other projects using it.
And there could be that some developer updates the external project when under its local solution which we want to prevent. Since all are in GIT
is it possible somehow to make dependency related so that any change in external is known to others.
So basically how can we prevent anyone to make local updates to the external project but also make sure any updates to external project are available to
any other project using them.

There are several approaches that you can use to achieve this.
Quick: Reference project in two solutions
The quickest is to reference the shared project from both solutions. This way, you can use it in both projects and the changes are propagated to the other solution because you are basically working on the same files. However, a huge drawback of this approach is that if you make changes in solution A that are not compatible with solution B (e.g. removing a method that is used in solution B), you will only find out when working on solution B.
Easy: Single solution
To fix this, you could merge the solutions into a single one that contains the shared proect and also the other projects from solutions A & B. This way, you still get the convenience of project references in a solution. In addition, you are notified about breaking changes immediately if you build the complete solution. If this approach is viable for you in terms of solution size and team structure, I'd favor this approach. As you already share a single Git repository, I think this approach is well worth considering.
Nuget Package
If you want to keep the solutions strictly separated, you'd need to follow a more complex procedure. You could for instance move the shared project into a solution of its own and create a Nuget package with a clear build and versioning strategy. You can host the Nuget package on a package feed (e.g. on Visual Studio Team Services). Solutions A and B can then reference the Nuget package from the feed and also update it if a new version becomes available.
Here the official documentation to create nuget package with nuspec or csproj
Create .NET Standard 2.0 packages with Visual Studio 2017 [CSPROJ]
Creating NuGet packages [NUSPEC]

Dealing with References & Nuget Packages

I am having a bit of trouble. I have no idea what question title is appropiate in this case, feel free to edit it, if you have something better in mind.
So, basically this is the current situation:
Currently I have four projects (not the real names, but the architecture is identical):
Client (the main client logic)
Server.Main (the main server logic)
Server.Extensions (some functions for the server, e.g. helpers etc. can be used standalone, shouldn't rely on something from Server.Main)
Shared (shared code between client & server)
For each of the projects I create a Nuget-Package and upload it to my online repository. This repository is private for now and only for development purposes.
Here is a summary, what project uses what Nuget-packages:
Client uses the Nuget Package of Shared.
Server.Main uses the Nuget Package of Shared & Server Extensions.
Server.Extensions uses the Nuget Package of Shared.
This works fine for me at the moment... I can easily update my repository for testing purposes and use the freshly updated version of my package.
But here comes the problem:
I would like to share my project with other people now (e.g. the GitHub community). But when they have gotten the projects, they don't have any access to my private repository and the nuget package manager will not find the packages.
Further more there is another problem with my architecture: When they will fix something, e.g. in Shared, they wouldn't be able to test the changes, because the Client & Server would always use the Nuget package from the repository and not the fixed/changed local code.
And I thought about referencing the Shared project directly in all other three projects. Would that mean, that whenever I update Shared, I have update all other three projects aswell?
I think, my whole Nuget architecture is wrong. But I don't know how to do it correctly / in any better way. Does anyone have a better approach for me?

I wouldn't say this is necessarily wrong. If someone is trying to consume and work on your solution, P2P (project to project) references are probably the best since there is minimum overhead and there is a higher probability of catching issues early on during build and subsequent debugging sessions.
You can still easily create NuGet packages for all three during build and consume them in lets say a integration test by either packing them in a post build step or using tools like NuProj.