|
|
|
posted at
05:21 PM
|
trackback
|
|
link
 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
|
Friday, 15 January 2010
|
ASP.NET page life cycle
posted at
09:51 AM
|
trackback
|
|
link
ASP.NET Page Life Cycle Diagram
Here's a little peek (I don't want to steal his thunder, so I won't show the whole thing):
[categories]
aspnet
|
Friday, 30 October 2009
|
Documentation survey!
posted at
02:35 PM
|
trackback
|
|
link
https://www.surveymonkey.com/s.aspx?sm=qQnlYIN2D5gQH7UhLrQyuA_3d_3d
This asks some basic information, like where you get your technical information and how you go about finding it, as well as how best to get your feedback, what type of development you do, etc.
I can assure you that we look at this stuff intently, we really do. I encourage you to go through the survey. It's only 11 questions, and it will help us out.
Thanks!
[categories]
aspnet, technology, writing
|
posted at
10:41 AM
|
trackback
|
|
link
We released Beta 2 of the .NET Framework 4 and Visual Studio 2010 today. As part of the docs push, we managed a change that we've actually been wanting to make for a long time. Since approximately forever, our stuff has been part of the overall Visual Studio documentation, and it's taken some digging to find it:
Whereas all this time we've had this other node in MSDN that seemed like it would make a good home for our docs. And as of today, that's where you'll find our stuff:
The new organization reflects a couple of things. One, obviously, is that if you're scanning the MSDN table of contents (TOC) looking for ASP.NET stuff, a pretty likely place to look is in a node that's about Web development. We wanted to reduce the clicking required to get to the doc, of course. Another change is that because the docs are not tied specifically to versions of Visual Studio, you can see that we can keep ASP.NET 4 and ASP.NET 3.5 documentation close to each other in the TOC.[1]
Notice that we also have the MVC docs nearby. We debated how best to organize the MVC docs w/r/t the main ASP.NET docs. The MVC development team understandably does not want to suggest that there's this thing called ASP.NET, see, and then there's this other thing called MVC. But it's a logistical problem for us, because the MVC team versions their stuff more frequently (more agile-y) than the .NET+VS releases go out. Plus the versions don't necessarily align -- you can use MVC 2.0 on ASP.NET 3.5. In the end, we went with having the MVC docs close to, but not underneath, ASP.NET docs.
Anyway, as part of the B2 release, the folks at MSDN debuted an overhaul of the MSDN site. It's, like, prettier. :-) And it has been reorganized. And -- this is the part I think is way cool -- there are now two alternative views (three total, eh?).
There's "Classic," which is the MSDN we all know (but prettier); there's "ScriptFree" (known as "loband" during its testing phase); and there's now "Lightweight Beta." ScriptFree is intended to be very lo-band indeed. It's amazingly fast for those of us used to MSDN, but I often find that the keyhole TOC a little too sparse. I'm really pleased with Lightweight view, which is fast but retains the structural elements that I've come to rely on. I even like the page design better than in Classic view.
Incidentally, if you go to ScriptFree view, the view-switch UI changes (no script, right?). It's up at the top:
I won't blather more about the MSDN redesign right this second, coz lots of other people have had lots to say about it (e.g. new design, loband). However, there are a couple more things about Lightweight view that I really like that I'll note later.
Let us know what you think, good or bad, about the new location of the docs, about the way we organize the TOC withal, and of course about MSDN!
And speaking of MSDN, maybe I should go do some work now. :-)
[categories]
aspnet, writing
|
Thursday, 15 October 2009
|
Foiled attack
posted at
02:07 PM
|
trackback
|
|
link
<% foreach (var x in ConfigurationManager.ConnectionStrings){%><%= x.ToString() + "<br />" %><% } %>
This is an attempt, obviously, to get connection information about any and all databases that the blog has access to.
In this particular case, the attack was not successful because I encode stuff in comments, so it was just passed through as text. I sure hope that I've anticipated other, relatively straightforward attacks of a similar nature. But as we know, hackers are wily. And I am not particularly so, alas.
It goes to show that no matter how trivial your site, someone is interested in hacking it. Security: It's not just for commercial web sites.
[categories]
blog, aspnet
|
posted at
11:18 AM
|
trackback
|
|
link
In the wake of this, a semi-unserious proposal was made that because most comments are dumb, we should just strip all comments from the example code. Because code examples are not translated, we have to explain the code in the text of a topic anyway.
Hmmm. This type of proposal is useful for goading me into thinking through our policy. Herewith my thots:- Having decent comments in a snippet is useful for the person who copies and pastes an example into their application, even if the code is explained in the topic.
- As with member descriptions, descriptions in orientation topics, UI reference topics, and other such, it takes time and thought to create a comment that is actually useful to the reader. All of these types of text share the characteristic that they are often written as an afterthought, in a hurry, only to fulfill a general requirement, or while the writer's attention is focused elsewhere.
- Comments might could be written by bearing in mind the Alzheimer's Law of Programming: Looking at code you wrote more than two weeks ago is like looking at code you are seeing for the first time.
- James Edwards once suggested "comment-driven development". Bet you'd get better comments that way, eh?
- Lame comments are partly the result of comments being unedited. Opines the editor.
This business also provides what I think is a good response when I hear anyone suggest that a good way to document APIs is "just have the developers comment their code." Sounds good in theory. But see the preceding.
[categories]
writing, aspnet
|
posted at
10:07 PM
|
trackback
|
|
link
Other examples where we've linked to external sites:- The Section 508 site for information about accessibility.
- The IANA site for a reference of MIME types.
- The Mozilla developer site for information about the document object model (DOM) supported in the Gecko browser rendering engine.
- The Unicode site for (duh) information about Unicode.
There are more, but you get the idea. The thought here is that these sites provide information that is not specific to our product but that is useful to our audience. It would be silly for us to copy this info or (god forbid) rewrite it so it could be part of our documentation site.
 You will probably note that sites have certain features in common. They are:- Authoritative. Many of our links are to the sites of standards bodies.
- Commercially neutral, at least for the purposes for which we are linking. For example, the Mozilla site could be thought of as a competitor to, say, Internet Explorer, but from our perspective (server-based Web coding), it's just another client.
- Stable. None of these sites are going away anytime soon, and the content that we link to essentially won't change.
Which brings us to Wikipedia. The fact is, there is a ton of good information on Wikipedia. The ever-expanding nature of the site means that it often has in-depth articles on topics that are of interest to our audience. Here are a few examples of articles that were recently proposed as links:We didn't link to these articles. In fact, we currently have a blanket prohibition (at least, within our group) on linking to Wikipedia. This can be hard for the writers to accept. And you can see why -- rather than us having to describe some general, non-product-specific technology, why not just link to it? And the articles that are listed above are quite good, certainly better than we are apt to produce without considerable trouble on our part. I mean, why spend days and days writing up a description of cross-site script exploits when we can link to a fine article right there?
It's tempting. But if you review the characteristics of the sites that we do link to, Wikipedia comes up short, to wit:
Authority. Wikipedia articles are anonymous. There is an inherent conflict between the wisdom-of-crowds nature of wikis and the authority of a single, recognizable author. Jeff Atwood explored this issue recently. More simply put, a Wikipedia article cannnot answer the question "Oh, yeah? Sez who?"
Moreover, as has been shown repeatedly, not everything in Wikipedia is, in fact, correct. Anyone can change anything, any time, and there's no guarantee that any given change results in accuracy. John McIntyre, who has a dim view of Wikipedia indeed, recounts a recent scandal in which should-know-better journalists picked up a faked citation that was planted on Wikipedia with malice aforethought.
Neutrality. Most information on Wikipedia does not seem particularly controversial, but the site has problems with partisan battles. Politics is an obvious area for this, but there are plenty of people who have heated opinions about, oh, Microsoft. Imagine for a moment that article on cross-site script exploits. A reader who has a particular issue with Microsoft might amend the article to note that Microsoft products are particularly susceptible to this type of exploit. Whether or not this is true, this type of debate is not something we want to be linking to.
Stability. Wikipedia articles change constantly. The paragraph that you have in mind when you link to an article today might not even be there a week from now. Of course, that's not very likely with the types of articles that I listed above. But the point is, we don't know and certainly cannot guarantee it.
Our attitude about linking to Wikipedia might change over time. I imagine that it will change pretty much in step with what the attitude at large is about the reliability of Wikipedia articles. If college professors start letting students cite Wikipedia for research bibliographies, then we'll probably feel comfortable linking to it. And maybe before then, who knows. But as of today, no.
[categories]
writing, aspnet, editing
[tags]
wikipedia, documentation
|
posted at
09:53 PM
|
trackback
|
|
link
A little while ago, AJAX took the Web-development world by storm. So cool! So interactive! You could do so much in the browser by using this JavaScript thing. Now, my memory is so faulty that I distinctly remember that around 1999 or so, JavaScript was the bane of Web development. It was for, you know, Web developers. Scripters. Markup people. Not Professional Programmers. Real programmers used C. (Unbelievable how bad my memory is, don't you agree?)
And you know, speaking of Web development, when AJAX came out, another thing that people were excited about was that you could do everything in the browser! No more of those round trips to the server and that annoying browser "flash" on postback that users all over the world were so up in arms about. (Some were refusing to use the Web at all, I heard, unless this was fixed.) And again, my memory is so wretched that I could have sworn that when ASP.NET 1.0 came out, putting all the processing on the server on a browser-independent platform was considered a big step forward. Obviously, I'm totally remembering that wrong.
Dynamic languages. Typeless variables, interpreters, extensible objects -- so flexible and convenient! This was very confusing to me, because I seemed to remember -- dang, the tricks that the aging brain plays on you -- that there was a time when type safety and compilation and all that OOP stuff were things that we wanted for coding.
And just recently, my mind has again been leading me astray. I've been reading about ASP.NET MVC and all its great features like the advantages of having complete control over your HTML. (By writing it all by hand.) All this time I had thought that the ASP.NET Web Forms model was some pretty hot stuff, and that those control abstractions sure were rendering a whole lotta markup that I didn't have to write. So wrong. In reality, Web Forms suck so much that developers would have been "happier sticking with the classic ASP programming model than using webforms." And speaking of ASP, I could have sworn that people were ecstatic at no longer having to use VBScript and write spaghetti-coded Web pages, but I must be remembering that wrong, too.
Ah, well. To help my defective memory, I should stash away a bunch of articles and editorials and blog posts about how wonderful MVC is, and AJAX, and dynamic languages, and all that stuff. Then in 8 years, when I've lost even more of my memory, I'll be able to refer back to them when I get confused and people are telling me that this new development platform is so much better than that awful MVC stuff ...
[categories]
technology, aspnet
[tags]
javascript, Web development, AJAX, Web Forms, ASP.NET, MVC
|
posted at
01:40 PM
|
trackback
|
|
link
We're looking at maybe updating this, so we'd like to know from you:- Have you used these docs?
- If so, what information did you not find?
- If you tried using them but gave up, what was missing?
Any feedback you might have about this section of the ASP.NET docs would be very welcome.
Thanks!
[categories]
aspnet
[tags]
ASP.NET, custom controls, server controls, documentation
|
posted at
12:07 PM
|
trackback
|
|
link
This is one of those deals where the answer is "No. Yes. Maybe." In response to the internal query, Eilon Lipton explained:
In general, from a very technical perspective, no controls at all are "safe" to use in MVC except for ones that have to do with page structure: Page, UserControl, MasterPage, ContentPlaceHolder, and Content.
Even controls that might appear to be "safe," such as Panel, are not as safe as you think. There are many features of the Panel control that won’t work in MVC view pages. Having said that, almost any control can be used in an MVC ViewPage as long as you constraint yourself with regard to which features of that control you use. The problem is that most Web Forms controls rely on postbacks and on viewstate; neither of those things obtains in MVC. When Eilon says "if you constrain yourself," he is effectively saying if you're not counting on viewstate or postback. And although you yourself might not be explicitly using these features, behavior that's cooked into the Web Forms controls often is. For example, an ASP.NET Button control raises its server-side Click event through the magic of postback. No postback, no Click event; hence, MVC, no Click event. Which is to say, the technology that constitutes the Web Forms abstraction (which, as has been noted, is leaky) doesn't work in MVC.
So, sure, you can use Web Forms controls, but in many cases, you have to stay away from the very behavior that they were designed to implement. You can use an ASP.NET TextBox control, for example, as long as you don't need its state to be maintained if the page is recreated (viewstate) or if you don't need its TextChanged event (postback). At that point, there's not a whole lot of reason left to use the TextBox control instead of, say, an HTML
We include helper methods for handling many of these scenarios. These aren’t "controls" per se, but they handle some of the scenarios. So for the TextBox control, I’d use <%= Html.TextBox(...) %> rather than the straight up HTML. You can read about these helper methods in How to: Render a Form in MVC Using HTML Helpers.
Eilon again, summarizing the story:
Thus, the overall guidance is: Don’t use any ASP.NET controls in WebForms with the expectation that they’ll just work. If you use trial and error and find some subset that works in your particular scenario, you should be safe to continue doing so.
[categories]
aspnet
[tags]
ASP.NET, MVC, Web Forms, controls
|
|
|
|
