CODEWITHSUNDEEP
c#asp.net-core-mvcasp.net-core-6.0
Vikas
Vikas

Reputation: 334

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.

Upvotes: 1

Views: 330

Answers (1)

ArwynFr
ArwynFr

Reputation: 1712

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.

Upvotes: 2

Related Questions