Default references list in the VS IDE


When you install VS (or rather the .NET Redist), you get a C# compiler (csc.exe + cscomp.dll), which comes with a csc.rsp.  Gus blogs about how it affects how you build.


However, this response file ony affects command line builds, not building with the VS IDE.  When you build with a VS project, you only get the assemblies you reference explicitly. 


When you create a new C# project in VS, you only get a few DLLs referenced by default.  mscorlib.dll and System.dll, of course.  Sometimes System.Data.dll or System.Windows.Forms.dll.  Sometimes others.


There are two kinds of problems users have as a result of this behavior:



  1. Compiling from the command line (with csc.exe) and from within the IDE have different default behaviors.  (Different referenced assemblies)

  2. Sometimes you know the name of the type you want, but you have to first add the reference and then add the ‘using’ directive, before the type appears in your completion list.

I’ve proposed that we make the default reference list match exactly the default the compiler command line, as a way to help with both of these problems.  The references list would be the same by default. 


Most of the types you’re looking for will already be referenced.  With the Unbound Type Smart Tag, it’s easy to get the ‘using’ right.  They go well together.


There are still some gotchas:



  • If you edit csc.rsp, they will no longer match. 

  • Having this many references may have a small performance impact.  We’re still exploring this, and maybe we’ll be able to optimize it away before we ship Whidbey.

What do you think?  Is expanding the default references list for VS projects the right way to go?

Comments (7)

  1. milbertus says:

    I didn’t know about csc.rsp until I read Gus’s post a few days ago. That said, I do think that it’s a good idea for the two sets of defaults to match so that people who use both (I don’t know if this is a large group or not) will have a consistent set of defaults. Of course, for those people like me who only compile via VS, there will be new sets of defaults to get used to, but that’s no big deal, imo.

    As for the defaults being out of sync, is ther anything stopping VS from reading in the contents of csc.rsp when a new project is created, and add the references then?

  2. I think the references list within a project, much like the list of using declerations in a code file, is a fundamental way of communicating to other programers "these are the pieces from which this program is built".

    Having a larger list than what is necessary is "safe", but not very precise. Although it might not effect the constructed executable, it does effect any people reading the code. In that regard I advocate keeping the references list in the IDE as small as possible.

    However, I think that when using a command line, having to add too many "include this library options" is irritating, and needing to write a response file for a small project seems like should be unecessary.

    I also think that transparent IDE – Command line interoperability is a good thing. This is particularly true in complex SCM enviornments.

    A good comprimise might be to have Visual Studio use the union of the references list in the project and the default references list of the command line. The "complete references list" could then be viewed using a context menu on the references list node in the solution explorer that said "view implicit references" and "hide implicit references" depending on wether or not the implict references are shown or not.

    The implicit references could then be "made translusent" in the way that files not included in a project are when "view all files" is chosen.

    Thats my $0.02….

  3. Ron says:

    >Having this many references may have a small performance impact. We’re still exploring this, and maybe we’ll be able to optimize it away before we ship Whidbey.

    Could you elaborate? Gus (in this blog entry: http://blogs.msdn.com/gusperez/archive/2004/03/18/92514.aspx) states the reference doesn’t stick around in the compiled assembly. Admittendly, he doesn’t state the absense of a performance impact for an unused reference. Or am I incorrectly understanding your intent (perhaps you mean compiler performance instead)?

    As for keeping them in sync, as already mentioned, wouldn’t using the list in csc.rsp eliminate this concern? I agree with Scott, a filter for currently active references would be excellent for development (new and maintenace).

  4. jaybaz [MS] says:

    Ron: The perf concerns aren’t just at runtime of the app. I’m also looking at project load time, debugger performance, build time, VS memory usage, and intellisense responsiveness. Each could potentially be impacted. We still have to do some detailed investigation in each area to be sure we’re not going to cause you problems.

    We’ll think about using csc.rsp as the "master list".

  5. Another feature and some musings.

  6. Another feature and some musings.

  7. I prefer the references list to include ONLY the assemblies I actually need referenced. I would rather see a feature that would detect the fact I am adding an unknown object in code, scan through the GAC and maybe an options-defined list of additional assemblies and offer me a way to add a reference + "using" via a smarttag.