Add a link to the project and add a link to the DLL

Question

I am new to .net.Today I created a sample. In this example, I saved the data in a database using the N Tier architecture. If I want to use the BL or DAL method in another project (I mean the BL method in the UI or the DAL method in BL), I found two ways.

The first is . Right-click on the project <Add link <Project tab on the Project tab

The second is . Right-click on the project <Add Link <Select a DLL in the Overview list

Can anyone tell me that there is some difference between both of them, since both work the same way. The DLL path is better than the Project Reference. If so, what are the benefits?

Thanks in advance.

Regards, Mohit Kumar

Answer 1

The right way to do this is to add a link to the project.
One of the most important differences is that the link to the project is automatically updated when the project referenced changes.
eg. If you change your DAL method from GetEmployees() to GetAllEmployees() , then you can use GetAllEmployees() immediately in your BL class without compiling your DAL in the first place.

Answer 2

Usually you use a project link when the link is part of your solution. Thus, the corresponding last code is always used.

You will reference the assembly if it is a third-party component or is not part of your solution. This is somewhat more static since you will use the code in the version provided by the assembly. Therefore, any changes to the assembly will require that you physically rewrite the referenced assembly with the updated dll.

NTN

Answer 3

The differences between 2 have already been answered, but just to add to this, I think the only difference between the two in VS is that if you add a link to the project, it still adds a normal dll link, except for the link to the debug location of the project binaries (e.g. bin \ debug \ project.dll), so essentially you could just add the link in the same way and point directly to the last compiled dll.

Answer 4

I came across a very interesting difference between the two approaches, but in the context of having two projects, one of which is used by several developers and one of them for each developer.

Say the shared project VS is called projectS, and the private project is called projectP

Now, if the goal is to have a central development, and the developer needs to access the source definitions from both projectP and ProjectS, so pressing “F12” or “Go To Definition” in VS will result in a full definition, then we should use the link to the project, not the link to the DLL, otherwise pressing F12 will lead to the definition of the compiled "metadata", excluding all comments of the developer and other relevant data.

When adding links to ProjectS from ProjectP, VS will allow links to files included in projectS and refer to projectP using the source definition in projectS, and not to the "metadata" DLL associated with the specified project (ProjectS.dll). However, projectS.dll will be included in the Links and Development Times folder, and the runtime will be fine.

When adding links to DLLs, VS will resolve links from the "metadata" stored in ProjectS.dll, even if the link project was added to the ProjectP solution as an "existing project". This would allow the runtime to be in order, however, the developer will not be able to press F12 and go to the source definition in projectS, he / she will have to do this manually from the solution search area.