Dll reference recommendation

I have 22 projects in my solution. And I added links to several projects, creating these projects and selecting the created dll. Is this the best practice or should I use the project link instead of the dll?

Regards, Vix.

+4
source share
5 answers

Well, I don't know about best practices, but some points to consider at least.

Benefits of project links:

  • Easier to read code
  • Easier to debug
  • Easier to make changes

Benefits of dll links:

  • Quick builds
  • Less risk of accidental changes for common components

NOTE. You probably shouldn't support the projects referenced by the dll in the same solution, as this will lead to some confusion about what happens when you create it.

+1
source

I would suggest that you use project links. If I'm not mistaken, in this case you will always have the actual (not deprecated) assemblies referenced.

+3
source

In addition to @platon's post, I would say not just always , but in most cases.

Examples:

  • If your project uses many libraries written many years ago by X developers of your company and something has changed there once in a couple of years, and if you have 150 projects in your solution, adding DLL links to these libraries and NOT project links may be a very good decision, if not on every compiler you go play soccer on PS and return in 10 minutes.

  • Your project uses C ++ libraries, and you also want to create your own solution in the VS Express edition (you also work at home, you must transfer your code to someone who does not already have VS, it costs a lot ... and so on) . Add a DLL, not a project link

and so on... .... .

I mean what @platon says is absolutely correct, but not always true.

Sincerely.

+1
source

I would agree with plato to use links to projects. Most likely you need a lot of time to compile. Some things we did in our project:

  • Reduce the number of projects in the solution
  • Get the best PCs for developers, especially PCs with SSDs.
  • Create dependent projects in the External Assemblies folder, which is part of the solution and validated in the source control.
0
source

Using links to projects will allow you to easily read the code, step by step and debug / edit these projects if necessary. In my opinion, this is priceless, and you should not do it.

However, if you find that your build time is suffering due to a large number of projects, you can use several different approaches. Here are a few:

  • Go to the solution configuration manager and disable the "Build" setting for some projects in the Debug configuration. Please note that this will have a side effect of having to manually create these projects when making changes, and that when the solution is loaded from the original control, you will have to manually create these projects. This approach is good for "stable but in development" projects.

  • Precompile the projects (in the Release configuration) and create them all in the specified folder in the root of the solution (something like "ExternalAssemblies" or "Links"). Then you must delete these projects and re-add all the links to them by going to the compilation folder and adding links from there. This approach is good for "stable" projects that you can hardly edit.

  • Leave the projects as they are and get the best PCs. Faster disks and more RAM are never confused on the developer's machine ... The merits of the approach should be fairly obvious.

0
source

All Articles