Help me, help you!
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.
Comments
- Anonymous
July 21, 2004
The comment has been removed - Anonymous
July 21, 2004
The comment has been removed - Anonymous
July 21, 2004
The comment has been removed - Anonymous
July 21, 2004
Nicholas: Thanks for the info. I work with a guy who's worked on subversion, i'm wondering if he's got a suggestion for this :-) - Anonymous
July 21, 2004
The comment has been removed - Anonymous
July 21, 2004
Darren/Kristof:
I can go into more detail as to how we've improved the situation, but here's one big way we did it:
When you make a C# to C# (C2C) project reference it's now no longer the same as a VS2002/2003 C2C project reference. In 2k3 when you had this reference it wasn't a "live" reference, but instead was just a reference to the dll built by the other project. Because of this you might have observed that changes you made in one project weren't observable in another project until you did a recompile (and thus the other project would read in the new metadata from the first project).
Now in 2k5 we've made C2C references "live". So, instead of referencing the output of that project you reference the project itself. This means that when you make a change in one project it's immediately available in the other. It also means that because a C# project no longer references another projects dll, there are far less chances of a locking issue because, well, no one is trying to read the dll produced by another project.
Now, I realize that sounds kind of weak as you might think that that meant that we were "solving" the problem by just trying to avoid it. That's not the case here, lots of work was also done to make sure that we wouldn't lock dlls when you were actually referencing.
Note: it's somewhat of a difficult problem. Imagine we have a reference to a dll. We copy it, release it, read all the metadata out of the copy. We also place a file system watcher on the file so that we're notified if anything changes it. Now imagine that some tool intends to make changes to the file in two steps. On the first step they make a small change to the file, we get notified of that and we try to copy the dll, then while we're copying it, the tool tries to make a second change and sees that we've locked it (even thought we're about to unlock it a few seconds later).
does this information help out at all? - Anonymous
July 21, 2004
"So what do you think? Is it worth adding that feature that will allow C# to work outside of a project? "
I don't see why. If you don't want to use the IDE, just don't use it. - Anonymous
July 21, 2004
"Now in 2k5 we've made C2C references "live"."
Does this liveness have the smarts to work when referencing e.g. MC++ from C#?
(IOW, something to fit the kind of development scenario I described elsewhere) - Anonymous
July 21, 2004
When working on web serivces it would be nice to be able to edit C# source files without needing the entire solution open. Currently the IDE wants to connect to IIS and a virtual directory, and that's a pain if you don't have IIS or a web server on a dev machine. I think it prevents you from opening the project (it's been a while since I've tried it so I don't recall the exact error).
We also have the same problem as Darren and Kristof - VS does not scale well to solutions with large numbers of projects. - Anonymous
July 22, 2004
To Dr. Pizza
If your build system is traditional makefile-based, you do not have a choice. - Anonymous
July 22, 2004
DavidL: YOu should send that feedback to kevin blogs.msdn.com/KevinPilchBisson
He works on the C#+Web Developer integration. - Anonymous
July 22, 2004
Dr.Pizza: C++-to-C#: Right now no. I'd like to have a unified type model in the future so that any language can plug in and get always up to information from any other language about the types, etc, that it has.
I think it would be excellent both for just people using the editors, and for people writing plugins to VS where they want to be able to know about all that information.
It's also a must to be able to support refactoring over large multi-lingual solutions in the future. - Anonymous
July 22, 2004
Mikhail: But as part of a traditional muild system you can certainly call into msbuild which processes c# project files just fine :-)
I thought flexibility was a ncessary part of any build system. :-) - Anonymous
July 22, 2004
"If your build system is traditional makefile-based, you do not have a choice. "
You could use a dumb text editor.
After all, you're already using a dumb build tool, so why not go the whole hog? - Anonymous
June 16, 2009
PingBack from http://topalternativedating.info/story.php?id=11881