http://www.asp.net/whidbey/ now has a lot of whitepapers and screen-shots of ASP.NET and Visual Studio Whidbey.
This article in particular has a lot of great content and screenshots about visual studio (including screenshots of new beta1 functionality that you can't see with today's bits): http://www.asp.net/whidbey/whitepapers/VSWhidbeyOverview.aspx?tabindex=0&tabid=1
P.S. We'll be posting updated content on Whidbey throughout the week as the PDC continues.
Kevin Dente asked a few good Whidbey related questions (http://weblogs.asp.net/kdente/archive/2003/10/24/33370.aspx). Some answers inline below::
Although I sadly won't be attending the PDC, I do have a few specific questions about Whidbey - mostly around limitations or annoyances that I've encountered in the current framework, and whether they'll be fixed in 2.0. If any good-hearted soul runs across the answers to these questions and has time to post them, I would be most appreciative. Hopefully that answer to these questions isn't “you can already do that, dufus“. On the other hand, maybe that would be a good answer after all (except for the dufus part).
So here are the questions:
ASP.NET Server Controls:
- Is there better support for using style sheets in server controls? E.g. an easy way to register a stylesheet link, design-time support, support for stylesheets embedded in an assembly, etc.
ScottGu >> Yep. You can now programmatically register style-sheet links inside your server control (as well as control everything in the head tag on the page). You can also store your stylesheets as a resource embedded within an assembly -- ASP.NET now has built-in support for extracting these resources at both runtime and design-time.
- Is it possible to build more self-contained server controls? I dislike the whole “copy this directory of icons to your web server“ model that seems to be the standard. I'd like my entire control, with all of it's dependent elements, stored in one DLL.
Scottgu >> Yep. You can now store images as well as resourcs embedded in your assembly. We have a “WebResources.axd“ handler and control framework APIs that then allow you to make callbacks for these resources on a page. These APIs also work at design-time -- letting you display images within your control on a design surface like VS.
- Out-of-the-box support for linking to resources embedded in assemblies might be one solution to this problem. Any support for that in Whidbey?
ScottGu >> Yep. See Above -- this is exactly what we do.
- Using a custom http handler, you can write a control that generates dynamic images. However, as far as I know there's no good way to provide design-time support for this. Any improvements in that area? Scott Guthrie described a DynamicImage control in his blog posting - that sounds promising.
ScottGu >> Yep. We now have support for generating dynamic images both through http handlers (we now have an image generation base class that you can use -- and a custom file extension “.asix“ pre-registered for image generation). We also have a asp:DynamicImage server control that uses this service to enable you to create images within a page more easily (and not have to write an http handler).
- Any support for visual composition of server controls?
ScottGu >> Not entirely sure what you mean by this one -- although we will have much better support for User Controls. You'll get full WYSIWYG editing support in Visual Studio (unlike today). We'll also provide full tag intellisense, code intellisense and probably property grid editing for controls. Lastly, we've also added support for templates in user controls which makes them even more powerful.
ASMX Web Services
- Any improvements to the COM interop threading model for web services? Although ASP.NET web pages can be flagged as ASPCOMPAT to ensure apartment threading, ASMX web services don't currently support this attribute. Since large chunks of legacy code out there are written as VB6 COM objects, this limitation greatly hinders the application of the Web Service Facade pattern that Microsoft discusses here. Microsoft's recommended workaround of running the COM object as a COM+ library application is problematic - many COM objects don't play nice under COM+.
ScottGu >> I just pinged someone about this one. I don't think it was planned, but we'll try and get it on the schedule. Definitely agree we should do it.
- Any support in WSDL.EXE for generating properties rather than fields in web service proxies? Or, conversely, any support for databinding to fields in addition to properties?
This one drives me bonkers - it's a major impedance mismatch between these two parts of the framework. It annoyed me enough that I actually wrote a drop-in replacement for the MSDisco code generator (which I've been meaning to get around to posting) that generates properties. But I'm hoping Whidbey supports this out of the box.
ScottGu >> Yep, we'll generate properties by default now for .WSDL proxy generators. Not sure we do this yet in the Alpha -- but I know it is definitely planned by Beta.
OK, that's all I can think of for the moment. I'm sure I'll think of more immediately after I hit the “post“ button.
Paschal had some good questions/comments about web deployment today in Visual Studio (http://weblogs.asp.net/pleloup/posts/32950.aspx):
Because it's PDC time, I like to ask some questions about the future.
Guys, in Whidbey can we expect a better Web deployment system ?
I would like for example to be able to upload to my server a set of files, without deploying all my site.
Actually I can use right click on the files I don't want to deploy and ask Exclude from the project, but this create some issues.
I would like to have a FTP kind of features embedded in Visual Studio. I am sure it's not big deal to do so ;-)
I would like also that when I am opening a web project directly from my server, I can lock some files. So next time I deploy the site Visual Studio will be smart enough to not overwrite the locked files.
It will surely improve the deployment speed.
Currently I experienced quite often a timeout problem with deployment, and I am working on a 2 Mb line !
It's quite frustrating to have this Timeout error box coming just before the end of a long deployment.
The good news is that the story in Whidbey gets much, much better. Here is a sneak peak screenshot of it in action (note that it is a big screenshot -- so you want to open the picture separately to avoid the browser shrinking the picture and making it unreadable).
Some specifics about our story in Whidbey:
There is a new “Publish Web” tool within Visual Studio that makes it much, much easier to transfer/deploy a website onto a server (that is what the above picture is of). Specifically, it allows you to connect over standard FTP, Frontpage Server Extensions or just a file share. You can then select which files you want to copy over from your web project, and then click the “->“ (right arrow) button to copy them to the remote server.
You can apply and define custom filters to control what content is copied, or just manually shift select those files you want to move. The tool will keep track of where the latest files live (example: maybe the server has more recent files) and identify each file that is newer than the target with an arrow, making it easier to see where the latest files live (for example: in the screenshot above notice the “new“ files on the left like app.sitemap where the tool has put an arrow highlighting them). You can bring files from the server back to your local copy by hitting the “<-“ button (left arrow). You can also hit the sync button “<->“ which will automatically copy files back and forth to make sure that the latest files existing in both locations (note: it automatically handles timestamps across time-zones for you).
A detailed log file is also kept for each transfer - making it easy to go back in time to figure out what you did or didn't move over the course of a day or week.
Because the “Publish Web” tool is implemented as a tool window inside Visual Studio, you can keep it open while you are working and just tab into it (or just bring it up when you want to), and then hit the publish button to synchronize your content again. Makes moving things easy -- you never even have to leave the IDE.
Visual Studio “Whidbey” also now supports doing live edits on remote servers over FTP as well -- which makes it possible to make a “quick edit” on a single file on your site without having to either connect with FPSE, recompile and build the site, or explictly publish again. Note that our publish web tool uses timestamps to avoid overriding more recent files, so you don't need to resort to locking to preventing overriding newer files.
Hope this helps.
I was a bad person and just started working on my Cool Tips and Tricks talk for the PDC this week. My official reason for waiting was that I was holding off working on content until the other 18 ASP.NET Whidbey talks were done -- so that I could make sure to avoid any duplication of content. For those who have never been to one of my tips and tricks talks before, the basic structure I use is a slide/demo/slide/demo format. The emphasis is on cool stuff that can you can easily put into most applications.
Origionally I was a little worried that I wouldn't have enough content for the talk -- given that so much cool stuff is covered in-depth elsewhere. Thankfully after about 30 minutes more of thinking, though, I was able to dig up a number of goodies to share. Below are some of the things I'll be showing in my 60 minutes (note: I'm deliberately not showing any of the stuff covered elsewhere in the other 18 talks):
-- Cross Page Postback between pages. Yup -- you can now do it. And it is easy.
-- Using ValidationGroups. You can now have validator controls optionally validate depending on which button on the page is pushed. You can group validation rules into “groups“ so that all controls within that group fire or don't fire.
-- Building workflow on a page using the new asp:Wizard control. Handle next/back, step1->n workflows easily now (no funky state management tricks for controls required).
-- Using the new Image Generation Service and asp:DynamicImage server control. Show databinding a photo-album where all images are stored in the database, and bound to the asp:DynamicImage control within a asp:DataList template. No code required.
-- Url Rewriting using the new UrlMapping Service. Build vanity urls on your site (/products/shoes.aspx is re-written to really be processed by /products/productcatalog.aspx?id=shoes -- but the customer never knows it). Talk about how this makes http.sys kernel level caching possible for dynamic pages.
-- Using the new SiteCounter service to efficiently log and record usage patterns on a site (page views, clicks on important links, ad banner click and impressions tracking). Build some reports that show off how to look at the data.
-- Building a simple content management system with the FileSystemProvider. Show how you can store your .aspx pages inside your own custom database now (complete with code and code-behind) -- and how you can configure ASP.NET to pull and execute the content (and still dynamically compile it if appropriate) from places other than the file-system.
-- “No Compile” Pages. Enable administrators to lock down what code is allowed (or not) for portions of a site. Talk about scenarios with tens of thousands of content pages (but still with server controls + master pages -- just no code allowed) -- and how these can also all now be served without dynamic compiling each one at runtime (avoiding a perf hit on the first request -- as well as reducing memory usage on the server.
-- Using the ASP.NET Forms Authentication architecture and the new Membership and Role Management system to provide security authentication/authorization to non-ASP.NET pages/resources. My plan is to show a classic ASP site where we add login/role management support using ASP.NET. I'm also going to probably show PHP or JSP protected using ASP.NET as well.
-- Client-script goodies. Basically eliminate the need for the Black-Belt Web Forms talk that I currently give occasionally on Everett. Show automatically maintaining scroll postions during postback, controling default buttons and focus, programmatically setting focus on controls on the server, and easily handling client-side click events using server control buttons.
-- Build-Providers. Talk about the ability to add declarative types into your “code” directory and have them automatically compiled as part of your website (with full intellisense inside Visual Studio). Talk briefly about the extensibility model on how to add your own files (example: a .pdf file could become a strongly typed object that you could program against), and about the cool model this enables when used with partial types for end-user extensibility. Show using a .wsdl file I got from Google.com to integrate Google searching into a site as a web-service bound to an ASP.NET data control.
-- RSS Blog Reader. Show how to build a simple RSS Blog Reader from scratch using the new asp:XmlDatasource control, the asp:DataList server control, and our new XPath binding support for hierarchical data structures. Close the talk with a new ASP.NET reader working off of this blog.
Note: I'm still fine-tweaking what I'm going to show (and might need to cut one or two things if time gets tight), but hopefully there will be enough interesting and otherwise hidden things above to have people leave happy. Obviously the coolest features will be the ones in the 18 dedicated talks -- but this talk should hopefully be a nice near the end of the conference talk which shows some remaining loose end features that are fun.
Nikhil and Andrew Lin have been working on some cool new Blogging controls for Whidbey in preparation for Nikhil's Building ASP.NET Server Controls talks at the PDC (WSV 401 and WSV 402). Specifically, they are building a BlogDataSource control that demonstrates how to write a new ASP.NET Whidbey DataSource control (which will mean that any standard ASP.NET control will be able to declaratively databind against it -- no code required), as well as a BlogEntryView control that enables easy creation and editing of blog entries (including a cool out of band server callback scenario for spell checking).
The talks will use these controls (and a text editor control that will be built in the first talk -- and then used to build the BlogEntry control in the second) to explain and walkthrough some of the cool ASP.NET Control runtime and design-time features new in Whidbey. Should be a fun set of talks -- and a must for any control developers out there.
Several folks have pinged me asking for screenshots of my keynote demo (http://weblogs.asp.net/scottgu/posts/32007.aspx) to see what the final output looked like. Below is a quick walkthrough of the various steps. Apologies for the weird screen-color on a few of them (apparently alt-print screen and MS Paint doesn't always handle the pallete correctly!). Click each image to see a full-size version.
The default page for the website when an un-authenticated user (someone who hasn't logged in yet) hits it. Note the treeview navigation control on the left of the screen, and the login button at the top. The welcome message is generic and non-customized.
Basic login page for the site, built using the asp:login
control. Note that I haven't customized the control's look and feel at all (hence it's rather boring staid look). It fully supports template customization, though, so you can make it look however you want. Note also the new asp:sitemappath (aka the breadcrumb control) on the top right of the screen. It -- like the TreeView -- is driven off of the new ASP.NET site navigation system.
After logging into the site, we are sent back to the main page. The screen is now customized with a template (the loggedintemplate) from the asp:loginview
control. It basically just just outputs a simple message for the authenticated user. Note that there is also a custom message on the top right of the screen. The previous “login“ link (top right) is also now toggled to “logout“.
The datapage. I've put a drop-down (just a asp:dropdownlist)
on the page and wired it up to filter the datagrid control.
The datapage has updated the grid now that I've selected “wa“ for the filter. Note the treeview (I forgot to expand it in the last screenshot). We'll have a menu
Screen 6 and 7:
Just showing sorting support. Clicking on the “au_lname“ column automatically sorts the data by last name.
Clicking the edit button to edit the values in the grid. Clicking “update“ sends them back to either the database or the business object tier that the grid is bound to.
What the master page looks like in Visual Studio at design-time. All pages in the site use the Site.Master template to drive their look and feel. There is an content placeholder control on the master page called “MainContent“ which enables sub-pages to fill in their specific content to the page. I can put any html, controls or code I want on the master to customize it. I can also have multiple content placeholders if I want multiple regions to be overridable. Note that we have a minor bug in the alpha with the treeview (which sometimes has a problem rendering in design-time when bound to the site navigation system -- this will be fixed in the beta).
This is what the DataPage.aspx file looks like at design-time inside Visual Studio. Note that the master page's content is automatically grayed out (you can't edit it at all from the DataPage.aspx). You can only add content and edit stuff in the replacable regions defined by the master.
Hope this gives a good flavor of what the experience will look like. Note that none of the scenarios shown in the screenshots (data, navigation, security, master pages) required any code out of the box. Nor was any code generated by Visual Studio. All of the controls and scenarios, however, have a very rich object model and set of events which enables rich code based customization if you have a scenario that needs it.
I built all of the functionality in the screenshots on stage in my 25 minute demo (in addition to the SQL based output caching page which I didn't show here). At the end I swapped out the master template with a slightly prettier html version (which is what is shown in the screen-shots) just to spiff it up a little. The master template, though, has no code on it -- and contained the same controls I had before in the one I built quickly in my 25 minute demo.
We have a 90 minute ASP.NET panel on Thursday at the PDC. Full details at: http://pdcbloggers.net/Question_and_Answer/PNL09.category
The link above has a mechanism to submit questions that you are interested in asking -- we'll then post a transcript of the final panel on our website once the conference is over so that everyone can read.
I'll be doing a presentation on ASP.NET Whidbey in Southern California (right after the PDC) on October 30th. Should be lots of fun content and demos. Anyone can attend.
More details can be found at: http://www.pdsa.com/RegionalUG/RegionalInvite.htm
It was a busy last 24 hours at ASP.NET Connections -- 5 breakout talks, 1 night-time panel, and the keynote this morning. I just flew back to Seattle a few hours ago and am totally beat.
The keynote was a lot of fun though -- and a great chance to show off some of the new ASP.NET Whidbey features to a public audience. I did a cool demo as part of my talk. The outline of the demo went like this:
1) Create a blank file-system based website using Visual Studio Whidbey (no Frontpage Server Extensions required)
2) Create an ASP.NET Page for data editing. Drag and drop the new datagrid onto the page and databind it against a database (no code required). Configure it todo sorting and paging (no code required either)
3) Add a drop-down list and use it to filter the DataGrid dynamically
4) Add editing support to the DataGrid (enabling updates of the data, in addition to filtering, sorting and paging)
5) Create a new ASP.NET Page. Build another datagrid against the database, and enable output caching for the page.
6) Enable the new SQL Cache Invalidation - so that the page's output cache is automatically invalidated when the data in the database changes.
7) Update the data and show that the page is immediately updated.
8) Create a new ASP.NET Master Page template for the website. Define some html tables in it to create a consistent page header (with logo), and layout tables for the content (with space on the left side for a navigation menu). Add a contentplaceholder control on the master template to enable pages on the site to inherit its UI, but override the content where appropriate.
9) Build a home page based on the Master template (using the WYSIWYG VS Whidbey editing support)
10) Go back and update the data editing page to also be based on the master template (showing how easy it is to covert against asp.net pages to be based on master templates).
11) Edit the master page again and add the new treeview control on the left hand side of the page, and databind it against the new site navigation system (no code required). Run the site and show how all the pages now have a consistent look and feel, and the navigation system+treeview makes moving around the site in a hierarchical way easy (as well as updates to the site structure simple).
12) Build a forms authentication system for the website. Use the new membership system, and the rich new login controls on top of it to enable forms based login and password recovery. Have the login.aspx page also be based on the master template so that there is a consistent UI for the entire site. Add a loginstatus toggle control to the top right hand section of the master template to enable users to automatically be prompted to login (in which case they are directed to the login.aspx page we built) or logout of the site (in which case the control logs them out of the membership system).
13) Use the new loginview control to customize the UI of the homepage, and generate custom UI based on whether the user is logged in or not. In the
of the control configure a “Welcome to my Site!“ message. In the of the control configure a “Welcome [UserName]“ message. Use the new loginname server control to even eliminate the need to write code to set the username in the template. Talk about how I could have also defined custom roles for the application (using the new role storage engine) and varied the output based on rolegroup templates in the LoginView control as well.
14) Run the application end-to-end for everyone. From scratch we've built a completely new site, that does data editing and reporting (using database invalidated output caching) against a database; is protected with a secure forms-based authentication system backed against a secure membership store with optional user lockout, password recovery, and site usage statistics; uses a site navigation system to encapsulate and control all link/navigation relationships from a site navigation XML file (allowing easy updates); and whose pages are all driven off of a common master template -- changes to which will automatically update all pages on the site.
15) Lastly, show dragging a new master page template into the project directory, overwriting the one we built on stage. It has the same rough structure as the one I built from scratch -- except that a designer has gone in and prettied up the HTML. No code changes are required in my site -- I can just his refresh to see the new look and feel (and it looks very, very good). Talk about the nice code/content separation enabled, and how Whidbey makes it even easier to have coders and designers work together.
I did all of the steps above on stage in front of the 400 person keynote audience. No copy/paste of code (except for the final step of copying a new master template over the one I built -- although it contained no code, just html markup and server controls). Instead I built the entire end-to-end application from scratch.
The whole demo took about 25 minutes from “new blank project“ to the final version. Based on the feedback from people, I think the audience was impressed. It was a lot of fun seeing and hearing the reactions.... :-)
P.S. The only thing I think I'll change for next time, is to show how we could have done the databinding and editing via an business object layer as opposed to working directly against the database (still requiring no code in the page itself -- all of the bindings can now be done declaratively to the business object layer with no page code required). I was worried about time in this morning's demo which was why I cut this part out -- I'm going to make sure I include it for the version I show at the PDC.
One of the things we are planning on doing from the ASP.NET + Visual Studio Web Development side it to post all of our PDC talks+demo code, along with our Hands On Labs, and two Whidbey whitepapers on the http://www.asp.net website.
This will enable people who can't make the PDC to still get a pretty in-depth taste of Whidbey (not as good as attending the talks themselves -- but still pretty deep). The exact url of the content is still TBD (we won't launch it until the week of the PDC) -- but I'll post it here so that folks will be able to easily find it.
There are times when I have to admit that I'm glad the PDC isn't every year -- because frankly getting ready for it is exhausting work. ;-)
I've spent most of this week doing prep work for the event, and just drove home after finishing a near-final review/edit of the Hands on Labs (HOL) for the Whidbey versions of ASP.NET and Visual Studio -- they are really starting to look great (kudos to Thomas Lewis for driving this).
We've come up with 9 separate ASP.NET labs -- varying from 30 minutes to 2.5 hours in length -- that each focus on a select number of new ASP.NET V2 features. These include: Master Pages, the new Site Navigation system and Navigation controls, Skins/Themes, Personalization, Web Parts, Data Access Controls, MMC Admin Tool and the new Config APIs, Membership + Role Management APIs and Login Controls, and many, many more. We'll have 100 dedicated ASP.NET Whidbey hands on lab machines setup at the PDC, with full time proctors monitoring them to provide help.
Each lab has a word document with 20-50 pages of detailed steps and screenshots to walk attendees through how they can build sites/samples with the new features. I think they'll be a great way to provide a chance for folks to quickly get their hands dirty and play with the new stuff.
The process for running the machines themselves is fairly cool. Basically we'll finish a final image of a single lab machine tomorrow. The technical support group will then save the image, and bring it down to LA. The 100 machines will be setup in LA for attendees to play with -- once they finish and walk away from a lab machine, we'll re-image the machine to bring it back to a pristine state (takes about 5 minutes start to finish), and make it ready for the next participant. The labs will be available until (I think) midnight each night of the conference -- so should hopefully hit lots of people.
In a few (5) hours, I get to head back to the office for my next round of PDC work -- which will be to review the slides for all the talks given by folks on my team. We have 18 ASP.NET Whidbey breakout talks at the conference, and I have 30 minute timeslots setup to review each tomorrow. Folks were still furiously working on the slides when I left about an hour ago -- I suspect several won't make it home until after the review tomorrow morning and afternoon.
In my spare time I am also helping to drive/define one of the big keynote demos (we just hired a graphics designer late tonight who is going todo a rush job on the graphics), as well as providing input on some of the cross-company architectural diagrams that we'll be unveiling during the week.
All in all it is keeping me busy. I am looking forward to flying down Sunday night to the ASP.NET Connections conference. The 5 back-to-back talks I'm giving there Monday will be a welcome break from PDC work... :-) I'll then fly back on Tuesday morning (after my keynote at the conference 9am Tues), and into my next set of PDC work items that will start in a series of meetings and reviews I'll have that evening.
What will hopefully make all this effort worthwhile will be the actual event itself. The amount of content that is going to be delivered there will be simply stunning. The big-picture roadmap of all the technologies coming down the pipe from Microsoft, and both the breadth and depth of the aspirations (Whidbey + Yukon + Longhorn), will frankly be a little eye popping. It is going to be fun to watch and experience.
Carl and Mark just posted my interview for .NET Rocks. You can listen to it at: http://www.franklins.net/dotnetrocks.asp#thisweek
The interview is about 68 minutes long, and almost all of it is spent talking about the next version of ASP.NET -- codename “Whidbey“. Hopefully some interesting data in there.
ASP.NET Connections is rapidly approaching (October 12th-15th). I'm doing both a keynote and 5 breakout talks. Two of my breakout talks are currently titled “Special Top Secret ASP.NET Team Sessions”.
I've held off on telling folks what they are until now -- but can now share that they will be a Part 1 and Part 2 session on the next version of ASP.NET and Visual Studio (aka Whidbey). The sessions will be about 60% demos and follow my standard slide, demo, slide, demo, slide, demo format. They'll be a lot of fun.
More details on ASP.NET Connections at: http://www.asp-connections.com/
Carl Franklin and Mark Dunn called me for a phone interview for their .NET Rocks series today. We ended up spending the whole time talking about ASP.NET Whidbey (our V2.0 release), during which I gave a few previews of some of the things we are doing. I only spilled the beans on about 2% of the overall feature set, but hopefully enough to be interesting and tantalizing....
They are editing the WAV file now and will post it on their website Monday. I'm hoping I don't sound too much like a doofus.
I'll post a link to it on my blog once it comes out.
Update: Here is the link to the interview: http://www.franklins.net/dotnetrocks.asp#thisweek