About a month ago I talked about the problems people have when trying to use Visual C# in conjunction with an external project system, as opposed to the project system built into Visual Studio.  Currently when you try to use C# files outside of a project we give you a pretty bad experience; intellisense tends to fall flat on it's face and unless you're using something defined in mscorlib.dll we won't really be able to help you.  I'm pretty biased on this issue and I'd prefer if everyone used the project system, but I realize that that won't always be the case.  There are certainly those that use any number of other excellent editors to get work done, and VS should be a tool that integrates well into whatever system you currently have working for you instead of forcing you to re-architutre your processes.

However, the issue isn't completely simple.  Without a project we feel that (at least for VS2005) there is no way to have behavior that solves everyone's needs.  For example, if you open up a .cs file outside of a project and try to reference a type that we don't know about, what should we do about it? We could search through metadata for it, but what if we found the wrong type?  If you have a type Foo that references Bar and you have two files open that define Bar which do we resolve to? (that case is more common when you're viewing different versions of a file from source control).  If you ask to build what should happen? etc. etc.

I'm bringing this up because it's something we're interested in improving and I've been thinking about ways to do it (while taking into account the time left before we ship).  One way is to simply parse and try to understand the file you have open in the context of all the other files you have open.  So if you have a file Foo.cs open that has a type Foo that references Bar, we won't understand Bar unless you open Bar.cs.  As for references, we might use just mscorlib.dll, the set of references you have in the current solution you have open, or maybe some default list that's defined elsewhere (and available for you to modify).  You probably wouldn't be able to build (as I'm not sure what that would mean), but most other things would work.

Is this a scenario that you run into often enough that you would like it to be handled better?  Or is the current Visual Studio based project system working?

From the last post:

“There's a lot of information about MSBuild out there, so I won't repeat it.  However, there is one really nice thing about it's integration in VS2005.  Specifically, when you do a build from within the IDE you get the same build system as when you run MSBuild externally on the project file.  So we have a system now that will allow you to build internally and run from your existing build system without any changes, and which will produce the exact same results.

So what do you think?  Is it worth adding that feature that will allow C# to work outside of a project?  In your own organizations (or on your own) do you find yourself wishing for this feature?  Or are you ok with the support we currently have.  If you're not ok, would the new MSBuild system solve your problems, or do you need support that goes far beyond that.  Do you think that this is just an MS issue and that we should fix our internal processes rather than adding more complexity to an already complex tool?”

Feedback is much appreciated here.