Is it slower to reference projects rather than DLLs for open-source projects, in Visual Studio?

Question

Is it slower? Sometimes there are exceptions or issues triggered by open-source projects, where having direct access to the code can give you much more insight on what you're doing wrong. Does it slow down the project, and especially does it increase compilation time? Assuming no changes are done to the project - I don't think it needs to be rebuilt everytime?

Answer 1

Assuming no changes are done to the project - I don't think it needs to be rebuilt everytime?

By default, If you choose Build, visual studio only considers the changed code. If you select Re-Build option then everything will be considered for compilation.

Does it slow down the project, and especially does it increase compilation time?

If by slow you mean application execution performance, then NO, there shouldn't be any difference, and for Compilation time, yes it will increase a bit (if no changes are made to the reference project). If the project is referenced in multiple locations and changes has been made to the project, then everything should go through the compilation process to make sure that everything is working fine.

Answer 2

I personally prefer to have the project itself open (at least to start with). As long as you don't Clean/Build often, builds should only compile projects with changed code so there's only a minor difference in compilation speed.

run-time, there should be no real difference in speed assuming the version you have open is identical to the version in the DLL and that you do a Release build

That said, after I understand what's going on, I usually switch to DLLs to avoid clutter in the Solution Explorer and the additional memory usage in VS

Answer 3

If you are not going to change anything in the open source libraries. then it is an overhead. Because it will compile every time your are compiling your project.

Answer 4

Generally speaking you should use Project references when possible. This is from an old article, but I believe it still applies:

The advantages of using project references are:

• They work on all development workstations where the solution and project set are loaded. This is because a project Globally Unique Identifier (GUID) is placed in the project file, which uniquely identifies the referenced project in the context of the current solution.
• They enable the Visual Studio .NET build system to track project dependencies and determine the correct project build orders.
• They avoid the potential for referenced assemblies to be missing on a particular computer.
• They automatically track project configuration changes. For example, when you build using a debug configuration, any project references refer to debug assemblies generated by the referenced projects, while they refer to release assemblies in a release configuration. This means that you can automatically switch from debug to release builds across projects without having to reset references.
• They enable Visual Studio .NET to detect and prevent circular dependencies.

Taken from:

http://msdn.microsoft.com/en-us/library/Ee817675%28pandp.10%29.aspx