Monday, 18 January 2010
05:21 PM
Visual Web Developer has long had a blank-sheet-of-paper issue when you create a new Web site project or Web application project in Visual Studio. As in, you create the project and then you, developer person, get to start adding your own layout (master pages, css), content, and optionally, authentication. Among other things.
 In the 2.0 release, we had what were referred to as Starter Kits, which were prebuilt apps for what were perceived to be common tasks -- "personal Web site" (which included a photo album -- this was before Flickr), time tracker, club site, stuff like that. But Starter Kits were, at best, a kind of add-on, and of course assumed that your goal was one of the types of Web sites for which a Starter Kit was available.
For ASP.NET 4, they've decided that pretty much all apps needed a certain core set of functionality. So for ASP.NET 4, when you create a Web project, you get certain functionality out of the box. The exception is if you explicitly choose to create an empty Web site (thusly named), which is about as empty as you can get. (You get a skeleton Web.config file and that's it.)
What you get
Here's what Visual Studio 2010 builds for you when you create a new Web site/application project: - Web site folder structure.
- A master page.
- A Menu control (tabs) on master page that link to individual content pages.
- A CSS file (Styles folder).
- 2 free-form content pages (Default, About).
- jQuery (Scripts folder).
- Routing (which is basically just enabled by default).
- A Web.config file.
- A Global.asax file.
- forms authentication, which includes:
- A Login link on the master page
- A LoginView control on master page (shows “Hello, <you>” when you’re logged in)
- An Account folder that includes the following pages:
- Registration page (content page + CreateUserWizard control)
- Login page
- Change-password page
- Change-password success page
What you don’t get
Certain functionality was left out by design: - Roles. This is explicitly disabled in the Web.config file.
- For forms authentication:
- A link to the change-password page.
- Reset password capability. (Because we don’t know what settings you might end up with for the membership provider, we don’t know whether we can (e.g.) send you your password.)
- SMTP configuration. You would need this to support change-password functionality.
What you would typically do
The preceding is what's built (or not built) for you. You can actually press CTRL+F5 and see pages with content and some measure of design appear immediately after you create the site, which is quite a step up from the old days, where you'd just see a blank Default.aspx page.
If you want to restrict content to "members", you can do that by creating a folder, adding content, and then creating an authorization rule (either manually or using the Web Site Administration Tool) for that content. Note that you can do this all using declarative syntax; no code required for these various tasks.
What you'd typically do is along the lines of the following: - Add content pages.
- Add menu items (tabs) to the master page for any new content you create.
- (Optional) Tweak the layout of the master page.
- (Optional) Tweak the CSS file.
- (Optional) Define routes if you want to use routing.
- For forms authentication:
- Add a link somewhere to the ChangePassword.aspx page. (A good place might be on the Login page.)
- Create a folder for restricted content.
- Add content pages to the restricted folder.
- Configure authorization for the restricted content. Simplest case: deny access to anonymous users.
- (Optional) Configure the membership provider to specify how passwords are stored. You can do this using the Web Site Administration Tool.
- (Optional) Create a way for users to recover passwords. (Depends on how password encryption is configured, and this might require SMTP configuration.)
- (Optional) Configure SMTP, if you want to support recover-password scenarios.
- For roles/authorization (all optional):
- Enable roles.
- Create roles.
- (Manually) add users to roles. The default registration page does not a way to specify roles for users added at run time.
- Configure restricted content to allow access by role.
Notes
On the master page, the link to the login page is a hyperlink, not a LoginStatus control. This was a deliberate decision so that pages that are rendered for anonymous users are lightweight – no view-state goo, no postback-link goo, etc. If you run the default page and look at the source, it’s very clean HTML.
The default page in the template contains this link: “You can also find documentation on ASP.NET at MSDN.” This links (will link) to some documentation on how to proceed from where you are.
By default, there is no link to the change-password page. Not all site necessarily want or need this functionality, and it's easy enough to change.
The login controls in the Account folder are all fully templated. (Templates are optional for these controls.) This makes it easier to tweak the layout and CSS for those controls.
The membership database and deployment
There are a couple of issues with the membership database. First, if SQL Server Express is installed, the database is created automatically in App_Data by the membership provider the first time a user is registered. (Some consider it a bad practice to allow the database to be autocreated like this.) If you’re using the Visual Studio Development Server (a.k.a. Cassini) -- that is, you have created a file-system project -- this all works great. However, if you are using a) an IIS project and b) IIS 7 or above, the app pool uses an identity that does not have permission to write to the App_Data folder. There’s a KnowledgeBase article that describes how to fix this. If you don't, you see an error message when ASP.NET tries to write to the membership database. (The error does, however, link to the article, nice.)
A second issue is deployment. In general, you don’t want to deploy an .mdf file in the App_Data folder; most hosters won’t accept this. Instead, they give you a connection string to your piece of their SQL Server. Therefore, if you have an ASPNETDB.MDF file, during deployment you either have to migrate your local database or (probably more common) re-create it. For novice users, deploying the database isn’t necessarily a trivial task, so it's either re-create, as noted, or some drill-down to figure out how to do this.
In conclusion ...
This is just a quick summary of what's going on with the new template. Interestingly, for those of us on the ASP.NET documentation team, the template means that we need to go revisit some of our docs and tweak them. For example, a lot of our walkthroughs (tutorials) were written with the assumption that you'd have to create these pages -- master page, CSS, login -- by hand as part of the tutorial. Not any more! Plus of course we need some documentation that guides users toward what to do next after they've created a Web site. But we can't really complain, since the change overall should make it easier for users (novices and experienced users, we hope) to get going with new Web sites.
[categories]
aspnet
|
link
|