This post originated from an RSS feed registered with .NET Buzz by Paul Vick. Original Post: vbc.rsp, coming in VB 2005! Feed Title: Panopticon Central Feed URL: /error.aspx?aspxerrorpath=/rss.aspx Feed Description: a blog on Visual Basic, .NET and other stuff Latest .NET Buzz Posts Latest .NET Buzz Posts by Paul Vick Latest Posts From Panopticon Central

Jay's blog entry on references and such reminded me of another small feature that we're doing for VB 2005, the default response file for vbc.exe. Basically, this feature makes the VB command-line compiler work in pretty much the same way that the C# command-line compiler works today: there is going to be a file vbc.rsp that sits with the command-line compiler and includes a lot of default settings for compilation, mainly references and imports. If you don't want the default response file, you can specify the /noconfig switch and we won't load the default settings.

Jay's main point, though, is about the difficulty of getting to classes that you know must exist but which you don't have a reference or import for yet. He suggests that projects by default should reference the entire framework but this won't work, at least for VB. I've been doing quite a bit of work looking at how long it takes to create a new WinForms project in Whidbey and it turns out that the Frameworks DLLs are big and getting bigger. Just loading all the symbols out of them so that we can do Intellisense and code model stuff consumes quite a bit of memory. So the thought of referencing even more DLLs makes me shudder - C#'s Intellisense/code model engine might be different, but for VB the “small performance impact” would be very big. Unless, of course, you've got gobs of available memory, which we all have, right?

That said, it seems like there are other ways we could attack the problems of adding references and of adding imports. This is of particular importance to VB because of the fact that the My namespace is intended to aggregate functionality from across the Framework. How do we deal with My.Foobar, if you don't have a reference to System.Foobar.DLL yet? So I think we've still got some work to do on that point.