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:
- Compiling from the command line (with csc.exe) and from within the IDE have different default behaviors. (Different referenced assemblies)
- 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
- Anonymous
May 02, 2004
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? - Anonymous
May 02, 2004
The comment has been removed - Anonymous
May 02, 2004
>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). - Anonymous
May 03, 2004
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". - Anonymous
May 03, 2004
Another feature and some musings. - Anonymous
May 03, 2004
Another feature and some musings. - Anonymous
May 07, 2004
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.