At the time of this writing, Beta 2 is not yet legally available on the outside AFAIK, so I hope I'm not jumping the gun here - but the more eyeballs and user feedback you can help us get, the better. So consider this a work in progress that will get updated as time goes on, if you have anything to add please throw it in the comments section and I will update as appropriate!
What's expected to work:
- ASP.NET 2.0 applications and web services running in IIS on the local machine
- File system based ASP.NET projects (meaning running in the Cassini webdev.webserver.exe standalone)
What's not expected to work (sorry):
- Profiling against remote instances of IIS (best you can do is install the profiler on that remote machine)
- Profiling from a non-console session of TS (use mstsc.exe /console if profiling via TS)
- When the site is accessed via FTP (see also #1)
- ASP.NET applications based on Everett and earlier runtime versions
- Beta 2 does not support non-admin IDE profiling of ASP.NET applications
- Can only profile Whidbey ASP.NET 2.0 web applications and web services - Everett ASP.NET is not supported. For example, this means no WSE 2.0 profiling unfortunately at the current time.
- Profiling under a TS session other than session 0 will not work - (use mstsc.exe /CONSOLE and it will work)
- Profiling under VPC has been compared to skating on thin ice for Beta 2 although it is improving at least for instrumentation, still YMMV and feedback is welcome.
- Symbols: The IDE profiler uses the debugger symbol settings (Tools->Options->Debugging->Symbols) - also if you need them, Windows Symbols Packages can be downloaded from the WHDC site. That said, symbol resolution in Beta 2 may be broken in some scenarios even when set through the IDE like this due to some boneheaded mistakes. If the experience isn't good for you let me know, since any feedback I can leverage to improve our symbols story would be greatly appreciated.
We burned the midnight oil getting basic scenarios for ASP.NET profiling going in Beta 2, but alas we are talking beta software here and there are a lot of known bugs that we are working on fixing but didn't make it in before this milestone. These are the main ones I'm driving to get fixed. If you know of any other bugs not listed here, please, please, please let me know (that's the joy of beta, so I'm really interested in hearing from you):
- If you're profiling over remote desktop, it's required that you pass the the /CONSOLE to mstsc.exe - since this is not the default behavior you must explicitly do this.
- You must be an admin user for IDE profiling - in Beta 2 some of the IDE plumbing is still buggy in the parameters that need to be sent to the underlying tools. Fortunately, it's not a core problem with the profiler engine, you can still profile as non-admin from the command line.
- The second time you run sampling from the IDE, you get a "failed to map path" error, but if you continue it will still work and give you results (as long as you don't switch to instrumentation).
- If the second time launching the profiler you switch from sampling to instrumentation or vice versa, you will get a failure message and the system will get in a corrupt state. If you close the performance session or the project, and then re-open it, you can switch to the other mode and do that mode. Yes, this gets terribly annoying for any type of repeated profiling because you close each time and then have to open again, and if you had the pleasure of visiting my office you could see head prints on the glass window near my door where our developer has banged his head in frustration over some of this.
- Profiling is broken when the site being profiled is protected by basic authentication (some internal plumbing that prepares the site for profiling are not capable of passing the required basic auth information)
- Any feedback you can provide about the user experience of working with an ASP.NET project and profiling it while linked into the Team Foundation source control system would be greatly appreciated. This is an integration scenario that I'm comitted to since it has the potential of driving users absolutely bonkers if it isn't done right.
- If you add a launch target to a performance session by specifying the URL (rather than using the wizard to create the performance session), be very careful that you type the URL correctly. Launching against an invalid URL is the equivalent to pulling the trigger of a loaded firearm aimed at your foot.
- Combining unit tests with profiling is an un(der)supported scenario in Beta 2 and YMMV (but while we're on the subject I can't help but veer off the profiler focus and mention that combining unit tests with code coverage is VERY cool and you should definitely give that try if you haven't!)
OK, now that you've seen all the dirty laundry, here's the good news:
HOWTO Profile ASP.NET Applications from within the IDE
Prepare the Performance Session
Open your web application or web service in the IDE, then select:
Tools->Performance Tools->Performance Wizard ...
The wizard makes it easy to create a performance session which has all the information about how you want to profile it (in sampling mode, instrumentation mode, and a multitude of other options you can set in property pages). You can arrive at the same result by choosing
Tools->Performance Tools->New Performance Session
but then you have to add the target project yourself. 6 to one, half a dozen to the other.
Launch The Performance Session
The trick to launching this is to select the Green arrow in the Performance Explorer toolbar, the one that gives you the 'Launch' tooltip when you hover over it. OK, if you must, just right click on the node in and use the context menu instead of using the pretty toolbar icon that a graphic designer made especially for you. However you decide to do it, once you trigger the launch, behind the scenes Visual Studio will set up the environment and IIS with everything it needs to do the type of profiling you are doing. Environment variables in the case of sampling, and some web.config information in the case of instrumentation. Instrumentation is done as part of a post-JIT compile step by ASP.NET, so that's why special web.config information needs to be added there - it gives ASP.NET the information needed to instrument the binaries.
IE will start up and then you will be able to perform any requests (from inside or outside the IE window) while that browser window is still open. When the browser process exits, the IDE will shut down the profiling and start collecting the data.
Note: If you are using Cassini and need Cassini to launch with a pre-specified port number under the profiler (for example running load testing against the site) you can ovveride the default port number used by the profiling tools by finding the registry key under the VS key which contains a string value named “PORT” with the decimal number representing the port # that we will launch cassini with. For example, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\AspNetHelper[PORT=”234”] should launch cassini on port 234.Warning: If you have not set a default start page, IE may launch with an invalid URL that looks like it can't see your application - if this is the case just type in the correct URL of the page (typically appending default.aspx will do the trick) you are profiling and it should still work. Close IE browser, and you will be returned to the IDE and the performance report will be displayed.
View the Results
At this point you can view the performance results similar to any other application that was profiled. The analysis view automatically starts rendering in the IDE.
My experience is that there are things being done without progress indicators between when profiling is finished and when the performance view is displayed, at least in Beta 2 builds. You may think your IDE is unresponsive when it actually is doing something, if so and you're willing to send me a note telling me what point you thought it was unresponsive it will help me put the pressure on to fix those spots.