vbc.rsp, coming in VB 2005!

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.

2 thoughts on “vbc.rsp, coming in VB 2005!”

  1. One of the greatest things about VB.NET vs. VB6 IMO is that VB.NET stores (almost) everything in code instead like the VB6 IDE which you had to use to create forms, etc. One benefit is when you "publish" code it can contain everything whereas in VB6 you couldn’t publish certain aspects.

    References, though stored in the .VBPROJ file, feel that way to me. Why? I can’t cut and paste references like I can cut and paste "import" statements while in the VB.NET IDE.

    Why not add a "references" statement and let me store them in a .VB file associated with the project?

    1. In general, we try to leave project-level stuff out of the source files although there are some exceptions (assembly-level attributes), just because there tends to be so much of it and it tends to change between releases. Baking it into the code locks down the ability to change it, but we also are wary of putting *too* much into the code. Definitely an issue of trying to find the right balance.

Leave a Reply