What is the recommendation for adding a link to a library in a project?

When I need to add a link to the library, I was always told to use the "add an existing project" method and refer to the project itself inside my solution.

But here, in my new company, a different method is used. They have a server on which compiled dlls are stored and versions are stored, so they can refer to older versions when the change is too important for the reorganization of old applications.

While I find this system very complex (I think there is a lot of work if the program specifying an older version of the dll is updated and needs some changes in this DLL), they seem to find it quite convenient.

What are the best methods for doing this? Direct link to dll? Linking a project? And why? Any information is welcome!

Thanks in advance!

+4
source share
5 answers

Usually I take a copy of the compiled dll (if the source project is not available or I don’t need the source) and put it in a folder inside my solution, and then refer to it. I check it for initial control along with my project.

I am of the opinion that you should be able to verify the project and build it directly from the source control without having to run the dll, etc.

+4
source

The Add existing project method is useful if you want to reference a library project that is being developed side by side, and you want test/use its types and methods , and this method ( Add existing project ) will not be used to add a link to pre-compiled files ( dll ).

Read the Project Link (MSDN) article.

+3
source

You would include it as a project when you want to work with the library at the same time. And this will happen mainly for small (ish) libs that will be distributed with your program (bin folder).

When the assembly (will be) installed in the GAC and, therefore, has its own release cycle, it makes sense to refer only to binary code.

Several combinations of the foregoing are also possible.

+2
source

Adding compiled DLLs is mainly when the code is more or less blocked (architecture level code), which you almost never change, for example,

1) communication level (remote / wcf)

2) General Gui layer (Wizards / Dialogs)

3) Security level (azman material)

you only need to change when your product goes in another direction, let's say that it uses to use .net as a connection, now it will use WCF

Using projects as links when you frequently change project links In addition, Visual Studio works great on creating projects.

+1
source

Although your company's approach is probably not very common among Microsoft developers, it has been used quite successfully in the Java world. In the long run, this is probably better controlled than any alternative, but without enough scripts / support programs (which, for example, automatically update projects / solutions when necessary), it can easily become unmanageable. In the Java world, it is directly supported by tools such as Maven .

+1
source

All Articles