What is the proposed way to define references in .NET?

What is the proposed way to define references in .NET?

• MarcBey

  > binaries.  I personally create an "Assemblies"
  > directory under my solution and any referenced
  > assemblies go there.  They may or may not be in CM
  > depending on whether they come from an installed
  > product or not.  Finally note that referencing
  > assemblies from a network drive should work.  I don't
  > know any reason why it wouldn't.
  
  I personally also prefer the assembly reference pattern, because I need not to have everything in my solution, and solutions can be big.
  
  The missing point for me is to specify more than one location for a already-but-not-by-me-built-assembly. I would like to give at least two locations for such an assembly. One one the network drive and one on my local drive. Because this would enable me to continue my sandbox pattern:
  
  There is a nightly build, which compiles the whole source tree, even the base components, and shares the compiled source under a share. Fine. Everybody can access it.
  
  Furthermore there is the 'sandbox' source of a developer on a local computer, which is only a subset of the whole source tree. So the developer does changes to components on his local source base,  compiles, and to successfully compile needs a so called base-lib, because his components have a assembly reference to this base-lib. Unfortunatley she does not have the base-lib not on the local disk so the compilation would fail. If we now had a mechanism,  which runs through the possible locations for a base-lib, it would find the needed assembly at least on the network drive ( because we sepcified so ) But it could also be found on the local drive, if the developer copied the base-lib manually from the somewhere to his own Assembly folder.
  
  This is the thing we really miss, and I would love to see in 8.1, if you ask me for a solution proposal.
  
  Maybe I can have comma seperated list in
  <HintPath>..\Ref.Net\B.dll</HintPath> the .csproj, but it is cumbersome to manually add entries here. The IDE should support so called 'alternativ assembly reference locations'
  ( sounds not so bad ;-)
  
  If you have questions to my proposal you can mail me at hermann dot schinagl at avl dot com
  
        Kind regards Hermann
  
  
  
  

• klva1

  Our solution contains over 40 project, so I prefer pre-building the assemblies once and using the assembly reference to reference the dll's. The problem is Find Reference (or Find Usage) only works for the current project now, and not for the whole solution. Even if the project of the referenced assembly is in the solution. This is really a problem when refactoring. Debugging and breakpoints on the other hand works just fine...
  
  Anyone an idea how to solve this problem
  
  Stefaan Smekens
  
  

• AshClarke

  Thanks for the info. I had read about "bin/$(Configuration)" part and it works fine. My concerns were about the assembly referencing that locks the file if Visual Studio is opened and about working with, for exemple, a GUI that references a business library and you need to work on both in the same day.

  Do you use local assembly referencing or a network share The issue that I see with local assemblies is that another developer needs to get them as well, although this can somewhat be done with the source control. However, you need something to copy the file locally from your BIN to your "reference assembly" folder.

  If you use a network share, you then have the issue that a build will fail if someone has his Visual Studio opened, and it also means it's not so easy to work with both the business component and the GUI that uses this library (for example).

  As for the question about multiple solutions with the same project, yes the project has a reference to a solution, however, if you open solution (sln) files rather than the project files, there are no problems.

  For example, I used to have 2 web sites (different security schemes, etc.) and a web services that uses the same business components; and because loading web sites was rather long in Visual Studio and that we never worked on more than one at any time, we separated that into 3 solutions with the same projects with the exception of the web site. It works as long as the relative path is the same all the way.

  Maxime Bombardier

  
  

• Hobbit666

  We have a simple set of rules that work for us:
  
  (1) We use VS2005 with Team System source control.
  
  (2) We always use assembly references, not project references (this is for scalablity). We can use our own non-source-controlled wrapper projects for local test development.
  
  (3) We always reference the debug version of assemblies when adding the reference.
  
  (4) Before checking in a project, we hand-edit the .csproj file, changing any "bin/debug" reference paths to "bin/$(Configuration)" (We have a tool that checks this has been done!)
  
  Doing things this way seems to work fine. We can even go to the build configuration dropdown in the IDE and change from debug to release, and see the assembly reference paths change immediately!
  
  
  
  

• usarcarib

  Thanks for the information
  
  

• Draggynsmate

  Can anybody explain this:

  I have a solution with two projects. Project1 builds a DLL, which Project2 uses. I am using Project reference option, because I am frequently debugging and recompiling both projects. So, in Project2 there is a reference to Project1. Why do I have to manually recreate that reference every time I switch between Release and Debug configurations in Project2 If I don't, VS will just copy Release version of Project1 into Debug folder of Project2 (or vice versa), even though in the properties of the reference the path is correct (release for release, debug for debug). Is this a bug or do I not know what I am doing

  Thanks a lot,

  Ilya

  
  

• Marko Tekavc

  Hi Hermann, there is a way for you to do this by modifying the <HintPath> in the project file. For example, In Notepad, open up your .csproj file and edit the following line(s):
        <HintPath>..\<Path>\bin\debug\<AssemblyName>.dll</HintPath>
  to say this instead:
        <HintPath>..\<Path>\bin\$(Configuration)\<AssemblyName>.dll</HintPath>

  This would make sure that the assembly corresponding to the active configuration is being picked up by the reference manager.

  Hope this helps,
  Prasadi de Silva

  VS Core Program Manager

  
  
  

• Yurgen

  Hello,
  
  People at the office are all referencing assemblies located under a network folder. Some people are working in other locations (geographically), but connecting to the same source code repository. They reference the same assemblies (obviously... they are working on the same projects), but the assemblies are under local folders -instead of network folders.
  
  The paths for the references seem to be checked in now in VS2005 That was different in VS2003 where the path for the referenced assemblies was not checked in, so everybody could have their own local path for them. This is a problem for us as we are working on the same projects and referencing the same assemblies, BUT in different paths.
  
  Any idea for dealing with this
  
  Thanks a lot!
  
  Paul
  
  
  

• hostile17

  I've never been able to include a project in multiple solutions to be able to use project references. This is because I use the VS source control integration, and if that is used the project file include a reference to which solution it belongs. So adding the same project to another solution breaks the original solution.

  Since noone in this thread has mentioned this problem I guess there is some simple solution to this problem that I've missed

  
  

• Parv Sangha

  Would like to point out that if you don't use project references, the "Go to definition" command will at best only show meta data for code outside the project where you call go to definition. Which means that when your not debugging, and your using assembly references, there's a lot of extra work finding and opening code files.
  

• Siddhartha Dutta

  Awesome thread! Very helpful information. I have managed to use all the suggestions provided in Visual Studio 2005.
  
  Thanks,
  Murray
  
  Email me here: murraybgordon at gmail dot com
  
  

• cues7a

  Seems this is my private thread...
  Anyway for completeness the results of
  our investigations. Will add this as an enhancement
  request.
  
  
  >  The setting you said was removed in VS 2005 I believe
  >  was moved to References tab in the project settings.
  >  Although I believe this only specifies what paths to
  >  search when using the Add Reference option.  As far as
  >  finding the reference once it is added to the project
  >  it is irrelevant because when you add the reference VS
  >  stored the location of the original reference so it
  >  knows where to find it.
  
  
  We have investigated a little more on the Reference tab in the
  projectsettings, and found out, that you can add pathes
  where the compiler searches for assemblies. Thats fine.
  
  Not at all:
  
  o) The content of the reference tab is not
     configuration dependent, which means, that
     we are once for sure referencing the assemblies
     of the wrong configuration
     
     Assume we have assembly reference path to
     
     t:\assembly\release;t:\assembly\debug;
     ..\..\assembly\release;..\..\assembly\debug
     
     where t:\ is a network drive, and ..\assembly
     is the local sandbox drive. Then we compile
     the release configuration of a component
     with the need to resolve references.. fine
     will work, because t:\assembly\release is
     taken first.
     
     If we compile the debug configuration of a component,
     it will again resolve against t:\assembly\release
     which is wrong.
     
     So there is no way of correctly referencing
     assemblies for both configuration with one
     reference tab path setting
     
     ==> The content of the reference tab path' must
         be configuration dependent.
         
  o) The content of the reference path is not stored
     in the x.csproj but in x.csproj.user which is not
     a good idea, because the content of the reference path
     tab *is* tightly connected to the project!
     
     
        
  
  

• Jing Fan

  I have a simple case where I have too many libraries and code to have a single solution; Intellisense simply eats my machine everytime I add a new line and make me wait a few minutes if I type '<' in Visual Basic.

  Obviously, some of these libraries aren't modified daily so I can easily create a few different solutions. In that case, I have to switch to "Assembly Referencing", and Team Foundation's build server helps creating a shared area to get my references.

  However, assembly referencing locks up the assembly while Visual Studio is still open. If a developer forget to close his solution / visual studio at the end of the day, the nightly build won't work. I could reference the daily folder, but that could be a pain as well, yet it gives me the ability to reference an older version if needed.

  Any suggestion or guidelines on how to effectively use assembly referencing how about when we branch applications

  Thanks,

  Maxime Bombardier

  
  

• Pavan kumar

  There are 3 methods available to reference other code in .NET (VS 2003 and 2005): project references, assembly reference and web references (web services, etc.)  For non-web references you are still limited to project and assembly referencing.  Given your dislike for these 2 methods do you have a proposed method that might work better   Your feedback on this could provide MS yet another mechanism.
  
  Each type has its own usages.  All-in-all project references are the best because they remove any maintenance work needed whenever the referenced assembly changes.  You just see the changes.  Unfortunately, as you mentioned, project references require that the project be included in your solution.  This adds undo compilation (even if the source hasn't changed), increases the size of the solution and requires the source code.  Project references are best used for projects that you'll have to build anyway.
  
  Assembly references are used for third-party components and for projects that you don't build in your solution directly.  This is commonly done for large products that would have hundreds of projects.  There is no benefit in putting them all in a single solution if no one developer would ever be working on them all.  Unfortunately assembly referencing requires that you keep the referenced assembly up-to-date with the builds.  VS won't necessarily recompile your code just because a referenced binary changes.
  
  For assembly referencing however  you can store the assembly in one of three places: GAC, locally in the project or in an arbitrary location on disk.  For signed assemblies you should retrieve them from the GAC.  For third-party components you should store the assemblies in a dedicated directory under your solution so that all projects can reference the same binaries.  I personally create an "Assemblies" directory under my solution and any referenced assemblies go there.  They may or may not be in CM depending on whether they come from an installed product or not.  Finally note that referencing assemblies from a network drive should work.  I don't know any reason why it wouldn't.
  
  Note that assembly referencing is actually a good thing because you can tell VS to target a specific version.  This gives your app the side-by-side versioning support that it needs.  If a third-party component you use ships a newer, buggy version you can just tell VS to use the previously unbuggy version instead.  You can't do this with project references.
  
  The setting you said was removed in VS 2005 I believe was moved to References tab in the project settings.  Although I believe this only specifies what paths to search when using the Add Reference option.  As far as finding the reference once it is added to the project it is irrelevant because when you add the reference VS stored the location of the original reference so it knows where to find it.
  
  So, in a nutshell there are only 2 referencing options: project and assembly.  Prefer project references when you are building the code already in your solution.  It removes the requirement for validating dependencies.  Use assembly referencing in all other cases and use either the GAC, the installation directory for commercial assemblies or a dedicated assembly directory for your own components.  Don't forget to update the references and rebuild whenever the external assembly changes.
  
  Hope this helps,
  Michael Taylor - 10/11/05
  
  
• What is the proposed way to define references in .NET?