Tuesday, July 25, 2006

Why do ASP.NET WebService and ASP.NET WebApplication look alike on the Application Designer?

Bill Gibson had this great response to a inquiry raised by a customer. I thought I'd post it for the greater good of the community.

When creating an Application Diagram: if you drag an ASP.NET WebService onto the design surface, you get the same shape and defaults as when you drag an ASP.NET WebApplication. (Although this may be TECHNICALLY correct, it is very confusing to have two different items to drag over that have nearly identical graphical images). When implemening, the only selections are based on Web Sites, however the do correctly implement into a Web Service.

This is not only technically correct, it is by design.

Regardless of which of the two ASP.NET prototypes the user chooses on implementation the same kind of application is created – an ASP.NET application. For an equivalent situation in VS consider this - if the user creates a web site in VS the user is presented with a choice of templates each of which has a different icon in the new web site dialog.

However, regardless of their choice a web site project is created which in the Solution Explorer is represented by the same icon – the same icon because the project is of the same type in each case. The difference between the resulting projects is the content that is created by default within each project. Once created the user has free reign over these web sites/projects and can choose to add to or remove any content that was created by default. They can go so far as to render a project created from one template indistinguishable from a project created by another.
Returning to the AD, and considering the ASP.NETWebApplication and ASP.NETWebService prototypes. These both create ASP.NET applications which participate in hosting and other relationships identically, regardless of the prototype used for creation. The prototypes differ in that one creates an ASP.NET application with a default web service endpoint and uses one template, the other has a default web content endpoint and uses a different default template.

Once created, a user could add a web content endpoint to the application created from the web service prototype and remove its web service endpoint. This would not change what kind of application it is or what kind of hosting relationships it participates in. It’s still an ASP.NET application, of course. Similarly, when reverse engineering applications from code, we have no idea what prototype might have been used to create the app, if any at all (none would have been used if the web site was created via VS). All we know is that it is an ASP.NET application with certain facets – such as the presence of one or more web service endpoints.

Furthermore a user can create any number of additional prototypes on the toolbox that can combine and alter the default characteristics of the prototypes that are supplied, and they can even remove the prototypes we supply. For example a user might quite reasonably create a prototype with both web content and web service endpoints and with their own custom template and a different default language. The user can then choose any icon they like for this prototype – they might well wish to use one that reminds them that this is still an ASP.NET application, because that is what it will create. Notice how the web site template icons have a family similarity. The same approach is used with our application prototype icons.
It is perhaps only a little unfortunate that the prototype name used for one of the prototypes is the same as the application type name, but there was no other obvious candidate. Once users start to use the tool they will develop the correct mental model. It is important that as we demonstrate the tool we correctly describe what the toolbox contains – it contains prototypes, pre-defined configurations of specific application types. As demonstrated, multiple prototypes may exist that create variations of the same application type. Usefully we will ship with an example of this to reinforce what is going on.

I hope this helps straighten out any confusion over the issue. We are ensuring this is well described in the UE. I think while this may be initially confusing user’s will soon build the correct mental model. Any attempt to mask this will only cause much deeper confusion once the get past their first encounter. This is most certainly not a bug and not something we plan to change.

Wednesday, July 12, 2006

Using the Visual Studio Team System Profiler: Summary View

Included with Visual Studio Team System Developer (and Suite) edition is a powerful new profiler for finding performance issues in your native, managed or ASP.NET applications. The profiler can run in both sampling mode (which looks at program state in some periodic cycle) and instrumentation mode (which looks at every function exit and entry point). The performance sessions that the profiler generates have several different views to help you to diagnose performance issues. This TechNote by Ian Huff, Software Design Engineer, Microsoft Corporation will take a look at the information that you can glean from the summary view of the performance report.

http://msdn2.microsoft.com/en-us/teamsystem/aa718874.aspx

Sunday, July 09, 2006

VSTS for Database Professionals CTP4

This release features a new project system with a separate project and schema view. You should see greatly enhanced performance when you reverse engineer a database. It also has a large number of bug fixes.

It is now available for download from http://download.microsoft.com/download/6/8/1/681f2f35-365c-4b47-a1ac-044f9801efb0/TeamDataCTP4.exe