Michael Teper

I couldn't find a way to add an external project reference to my Whidbey web project, so I googled for answers. Instead, I found that Matt Hawley, among others was having the same problem. Well, Matt hasn't looked hard enough! :-)

The answer is right there in the Readme:

13.19. The Add Reference button in property pages dialog boxes does not work
 

Steps to reproduce:

Start Visual Studio 2005.
Create a new Web site.
Right-click the Web project in Solution Explorer and click Property Pages on the shortcut menu.
Click Add Reference.
Nothing happens.

To resolve this issue

To add a reference to a managed assembly: Create a /Bin folder and add the assembly to /Bin by using the Add existing item shortcut menu To add a reference to an unmanaged COM component: Use TlbImp.exe to create an interop assembly and add that assembly to /Bin by using the steps above There currently is no workaround for adding a project reference.

Enjoy!

I started looking closer at the upcoming provider model in ASP.NET 2.0 and found some troubling patterns in current incarnation of the API (as of the May 2004 CTP). One example is MembershipProvider.ChangePassword method with the following signature:

public abstract bool ChangePassword(
 string name,
 string oldPassword,
 string newPassword
);

Can anyone spot a problem? I'll give you a hint, look at the return type. Now, without looking at the docs, can you tell me without a shadow of a doubt what that boolean value indicates? I didn't think so.

In this case, the API follows the old C convention of returning a boolean value to indicate whether the operation succeeded. This convention always felt incomplete to me, and it truly has no place in the world that has structured exception handling, and ESPECIALLY, for a method that should not, under normal circumstances, be a performance bottleneck.

In my opinion, the return type should be void and one should be able to safely assume that under normal conditions the operation will always succeed. Any failure to do so is an exception, and should be handled through the exception mechanism.

Wesner responded to my previous comment and pointed to an article describing SCID, Source Code As Database concept. I've also taken a look at the old Lutz Roeder presentation (MS PowerPoint) where he is toying with similar ideas. In the end, I think we are agreeing more than we are disagreeing. That is to say, that having the IDE become intimately aware of the code that is being created within it is a great thing. However, and this is a biggie for me and I think is the point where Wesner and I part ways: I want the IDE to use this intelligence to help me and make me more productive at writing code. I don't, however, want the IDE to constrain me.

Squiggly lines, dynamic icons and other decorative graphic elements that give me information about the code I am writing are great. Tools for visualizing the code post-factum (like Reflector) are also great. So is IntelliSense and code formatting intelligence. There may even be cases where interrupting text flow with graphical elements (like a Color picker) may be acceptable, though I am not sure about that one. BUT! There is a very fine line that must not be crossed here and it is far better to err on the side of not doing as much than doing too much. For example, the May 2004 build of VS Whidbey gives the developer a pretty rich way to describe code formatting preferences. Great, except, here's an example of the IDE going too far: if when declaring a variable, I separate the type from the name with tabs because I want to align successive declarations, the IDE reformats the code and replaces the tabs with a single space. To me, this is annoying as all hell. (whether this is intentional behavior or an alpha bug, its a perfect example to illustrate my point)

Wesner thinks this stuff is irrelevant and code formatting is a waste of time to begin with. I disagree. I think that's much like saying that Esperanto is a plenty expressive language, so why not just have everyone convert to it. In practice, familiar code formatting is key to readability of code; and that would not change in a SCID-like world either. Different people are used to different formatting styles, and those styles affect their ability to read and write code productively. But this is, of course, going off on a tangent...

I do understand where Wesner wants to take us though. It does feel like coding in simple text is just so 1980. Surely, today we could do better. But I think the limiting factor is not the display representation of code but rather the input method. Keyboard + Mouse can only take us so far and anything that forces one to jump frequently from one to another is only going to adversely impact productivity. We need to make the next big jump in HCI, but realistically, I dont think it will happen for quite some time yet, probably not this decade.