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.

Surprise frontend requirement after splitting backend into 2 projects

I had 2 projects in my solution. One WPF frontend and one C# library backend. This worked fine for month, but now I decided that a part of the backend has become complicated enough that I would split it off into it's own, third project.
So now I have 3 projects: 1 with most of the backend code that depends on nothing, 1 other backend code that depends on the first for interfaces, and 1 frontend that depends on the other 2 projects.
There were some namespace changes that I had to fix throughout the code, but else it's a straight forward change. Or so I would think. Because now my frontend suddenly has a requirement for Microsoft.Xaml.Behaviors that was not there before I split the projects (the error tells me it's required for the Xaml triggers that worked fine before).
I tried around adding references to the backend projects thinking that they may be required for some inheritance reason, but that didn't change anything. Only when I imported the Microsoft.Xaml.Behavior.WPF Nuget package to the frontend was the reference resolved.
The weird thing is that I have 0 frontend changes. I can check out the previous commit and the requirement is gone. All that is changes for the frontend are some namespaces and the added reference to the new project.
Where does the requirement suddenly come from?

Microsoft dropped support for System.Windows.Interactivity & Microsoft.Expression.Interactions in .NET 4.8. The functionality in these assemblies was replaced with a NuGet package: Microsoft.Xaml.Behaviors.Wpf.
Most likely, you recently moved to .NET 4.8.
Referencing the NuGet package: Microsoft.Xaml.Behaviors.Wpf was the right course of action.
Here's a blog post that talks about the issue:
https://devblogs.microsoft.com/dotnet/open-sourcing-xaml-behaviors-for-wpf/

ASP.Net Core - Where to find the Nuget packages installed list in the project

I have an ASP.Net Core 2.2 application.
MyApp.Sln
MyApp.API (ASP.Net Core 2.2 API Based project)
MyApp.Services (CL-Class Library)
MyApp.Contracts - (CL-Class Library)
My.Services.Tests - (CL-Class Library)
The above projects have different libraries(NuGet packages) installed
In .Net framework we used to have packages.config thats lists the nuget packages with the version details.
Where I can find the same details in .Net Core 2.2 ?
Because different project in one sln should not have different version of NuGet.
Thanks!

You can right Click in Your project in Solution explorer and Edit(For example MyApp.Services.csproj) in this file you will See Packages

You can follow this link to see options
Default command
Running in the project folder - Shows all packages, by default
dotnet list package <optional project path or solution path>

I don't believe there is anything equal to packages.config in .Net Core (possible reason - it aims to be more modular). You will have to make a little bit of work to solve your issue.
The quickest way to get dependecy graph is to run
dotnet msbuild YourProject.sln /t:GenerateRestoreGraphFile /p:RestoreGraphOutputPath=graph.dg
from terminal. Then you can open it with any editor and view all your dependencies in one file.
If this file isn't enough for you, you will (unfortunately) have to do a little bit of dirty work. See this answer View nuget package dependency hierarchy for some really good solutions, like how to write your own application to print dependencies, or how to use NPM.

Versioning Issue With Local NuGet Server Packages

Some background:
At my company, I have been working the last few months with converting our C# libraries to function on .dll references instead of project to project references. To do this, we have created a local NuGet server which contains NuGet packages for all of our libraries projects. We have Jenkins jobs set up for every project which build new NuGet packages and add them to the server every time a change is made to one of them.
For working on a single project, this system works great. You only have to worry about updating your packages folder through Visual Studio's NuGet manager, and then the rest is just writing code and building.
The issue:
When you add a new reference, or update your packages through NuGet, NuGet automatically specifies that specific version of the project that you selected in NuGet. With the current system I have setup, rebuilding a project locally will then replace it's .dll in the packages folder so that all projects that reference it can see these new changes you're testing. However, the issue come in that locally built projects have a different version than our Jenkins built packages. Our local builds use a different versioning system from our Jenkins builds so that you can easily tell whether something was built using Jenkins, or if some of the .dlls came from a developer's build. Because of this different versioning scheme, the reference of projects to the project breaks, because the new .dll that was built locally has a different version than the .dll that was retrieved from the NuGet server.
Current Solution:
For the moment, I have resolved this through the addition of a pre-build step. Before every project builds, the project calls one of my PowerShell scripts, which goes through and adds <SpecificVersion>False</SpecificVersion> to every project reference in the project being built's .csproj file. This resolves the issue, but only in the sense of putting a bandaid on it. Instead of dealing with the consequences of the system, I wanted to prevent them ahead of time so that this isn't needed every time a project builds. I have tried researching a lot about NuGet packages specific versioning issues, but have not been able to find anything online even remotely close to what I am asking. This makes me think that I'm going about this wrong.
The question:
What can I do to solve this issue? Or am I doing something very wrong and dumb that could be easily avoided by using another system? Any suggestions or tips would be greatly appreciated

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]