Help me, help you!

Cyrus Blather Help me help you | alternative dating

Cyrus Blather Help me help you | alternative dating — Wed, 17 Jun 2009 10:35:40 GMT

PingBack from http://topalternativedating.info/story.php?id=11881

re: Help me, help you!

Dr Pizza — Fri, 23 Jul 2004 11:33:00 GMT

"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?

re: Help me, help you!

Cyrus Najmabadi — Fri, 23 Jul 2004 02:04:00 GMT

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. :-)

re: Help me, help you!

Cyrus Najmabadi — Fri, 23 Jul 2004 02:02:00 GMT

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.

re: Help me, help you!

Cyrus Najmabadi — Fri, 23 Jul 2004 02:00:00 GMT

DavidL: YOu should send that feedback to kevin blogs.msdn.com/KevinPilchBisson

He works on the C#+Web Developer integration.

re: Help me, help you!

Mikhail Arkhipov (MSFT) — Fri, 23 Jul 2004 01:55:00 GMT

To Dr. Pizza

If your build system is traditional makefile-based, you do not have a choice.

re: Help me, help you!

DavidL — Thu, 22 Jul 2004 14:00:00 GMT

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.

re: Help me, help you!

Dr Pizza — Thu, 22 Jul 2004 13:20:00 GMT

"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)

re: Help me, help you!

Dr Pizza — Thu, 22 Jul 2004 09:40:00 GMT

"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.

re: Help me, help you!

Cyrus Najmabadi — Thu, 22 Jul 2004 08:28:00 GMT

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?