I have a "base" project in C # MVC (login, access control and related), to replicate in other projects, which is to copy the fonts and sometimes rename the project.
Do I have to change the GUID of the assembly? What is it for? Are there any problems with having 2 projects with the same GUID?
If you copy the project to another solution, that's fine. Visual Studio uses these GUIDs to manage referrals / dependencies between projects. Here is an example of the GUID:
<ProjectGuid>{0186C50F-7FBA-43D1-B403-D8BE75193671}</ProjectGuid>
If you try to add (instead of copying) a project with a repeated GUID into a solution, Visual Studio will automatically generate a new GUID for that project.
The same thing happens if you try to make an unload of the project (by Visual Studio), edit the .csproj and try to change the GUID of the project by placing a duplicate (in the solution). When doing reload, Visual Studio will get the GUID that the solution (.sln) has for the project, and will override.
If you try to edit own .sln by trying to force multiple projects to have the same GUID, when opening Visual Studio, it will automatically generate new GUIDs for duplicates.
This can be a problem if you use the same project in different solutions, because if for some reason above Visual Studio generates a new GUID for a project, opening it in another solution can give reference / dependency problems .
One way to solve this is to have both solutions use the same GUID for the shared project, so they will not overlap the GUID of the other in the .csproj . But this is a matter of preference, I understand that each form has pros and cons, it is necessary to analyze how you or your team prefers to work.
This is explained here .
Some projects also contain the GUID below:
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
As is the case with WebApplication , it simply causes Visual Studio to open different menu options for the project.
I've particularly tried to use shared projects in different solutions, but I ended up opting for something different. When I have a project that I would like to have the source shared with other solutions, I create a Nuget package and publish it to an internal package, and install it on projects where I need to use it.