CODEWITHSUNDEEP
.netvisual-studio
sab669
sab669

Reputation: 4104

What is the difference between these two references?

We have a few solutions with multiple projects in them. It's honestly laid out pretty poorly, and sometimes when we check in certain files some projects need to be re-built and others do not. Anyways, if I look at the actual project file in a text editor I see this:

<ProjectReference Include="..\admin.data\Admin.Data.vbproj">
  <Project>{some-random-numbers-and-letters}</Project>
  <Name>Admin.Data</Name>
</ProjectReference>

In other projects, I see references like this:

<Reference Include="company.someProject">
  <Name>company.someProject</Name>
  <HintPath>bin\company.someProject.dll</HintPath>
</Reference>

Can someone explain what the functional difference is between these two "styles" of references and how they're created? Any time I add a reference, I've always just right clicked the References folder, Add, Browse, and go and locate the DLL. I wasn't sure if using the Project tab in the Add Reference popup made a difference, or what...?

If it makes a difference, those two snippets are from .vbproj files but I assume a .csproj would look the same.

Upvotes: 1

Views: 69

Answers (2)

Hans Passant
Hans Passant

Reputation: 941317

There is never any point in picking the DLL with the Browse button if the project is included in the solution. The IDE works all-around better when it knows about the project. Off the top of my head:

  • Build > Clean will work properly, actually cleaning the referenced project
  • Building is smarter, knowing in which order to build and being able to the use the parallel-build feature
  • Edit + Continue can work when you change code in the referenced project
  • Debugging will work much better, it looks like you referenced the Release build of the project. Well, hopefully you did
  • The "Find All References" command can take you to the actual source code line that contains the reference
  • The "Go to Definition" command takes you to the actual source line.
  • A wholeheckofalot less trouble getting the solution to build three years from now when the origin of the DLLs start to get muddy and source control turned out not to have the required binaries.

A good reason to intentionally remove a project from the solution and replace it with a file reference is when the project should not change anymore. Usually because it is a "foundation" project where minor changes can ripple throughout the entire solution and destabilize existing code. Or when the solution just has too many projects and takes too long to load and/or build.

Upvotes: 2

Brad Christie
Brad Christie

Reputation: 101604

One referenced the compiled binary (latter), the other references another source project in the solution (former with guid).

And yes, how you included the reference made the difference.

Upvotes: 1

Related Questions