On the right you find the list of articles published on this Web site in the category ASP.NET 4 conveniently split up in pages.
If you can't find what you're looking for, try another category from the sub menu
|Site Section||ASP.NET 4|
|7/29/2012 4:04 PM|
By design HTTP, the protocol used to request and deliver web pages, is stateless. What that means is that the server does not keep track of requests you made to the browser. As far as the server is concerned, each request for a page is an entirely new one and is not related to any previous request you may have made.
This of course causes issues if you need to maintain data for a specific user. To overcome these problems, web developers have a number of solutions available, including session state, cookies and hidden form fields. ASP.NET Web Forms has been hiding much of this complexity by implementing a concept called View State. Controls (including the Page class itself) can read from and write to the View State collection to maintain data across postbacks. Controls such as Label use this mechanism to send their values to and from the browser, maintaining them across postbacks.
In this article you'll see how to leverage View State to store your own values as well.
The CreateUserWizard control in ASP.NET makes it super easy for your users to sign up for an account. Simply add it to a page, configure it, and you're good to go. In addition, you can control the way it behaves using settings in the web.config file (such as whether or not duplicate e-mails are OK, password lengths and strength, whether or not you want to implement a "security question and answer" and so on). Also, when you don't like its appearance, you can customize the wizard's steps which expands its underlying HTML into your page, so you get full control over the rendering.
However, when you customize the steps, you'll find that the config setting that controls the display of the "security question and answer" no longer works as expected. In this article you see how to set up your control so it still takes the config settings into account.
Some time ago I was involved as a software designer and developer in an MVC 3 project that used Entity Framework Code First 4.1 in a repository layer. During development we postponed dealing with security as requirements were pretty simple (simple logons with a single Administrators role plus the requirement that users should only be able to see their own data). When we were close to deployment, we ran the aspnet_regsql tool against the database that EF had created for us to create the SQL schema and data that the Application Services such as Membership and Roles require. We also added an additional userName parameter to a Get method in the repository to filter records for the currently logged in user. Finally, we added Authorize attributes to a number of controllers to make sure they are only accessible for users that are logged in. We then deployed the application and database, created a number of users using the MvcMembership section we had added to the site, and announced the presence of the site. All of this worked great, but we ran into issues when started work on the next version of the application.
Back in August 2006 I wrote an article about replacing the built-in Application Services providers (such as the Membership and Roles providers) with a new provider targeting a Microsoft Access database, instead of a SQL Server database. This solution has worked well for many people who didn't have access to SQL Server on their production machine, or couldn't (or didn't want to) spend a lot of money for an extended hosting package that includes SQL Server.
I wrote the article using Visual Studio 2005 and the Microsoft .NET Framework 2.0 which was the bomb at that time. And while you can continue to use the concepts explained in the article in web sites that target ASP.NET 4 today without any modifications (you can easily consume .NET 2.0 DLLs in an ASP.NET 4 web site), you may run into some issues when you also want to compile the Access Providers assembly against .NET 4.
In this article I'll show you how to make the Access Providers work under an ASP.NET 4.0 web site.
Many moons ago, in January 2007 to be exact, I wrote an article about storing files in the database using ASP.NET 2.0 and SQL Server. One of the features of the application I demonstrated in the article was the ability to switch between storing the actual file in the database, or saving it on disk. In both cases, meta data such as the content type and the original name were saved in the database, but by changing a configuration setting called DataStoreType you could determine if the actual file was saved on disk, or stored in an NText column in the database together with the meta data. In February of the same year, Steven Bey suggested to rewrite the application and base it on the provider model that has become a quite popular design pattern since it was introduced for the ASP.NET Application Services that appeared in ASP.NET 2.0. I added Steven's suggestion to my "Things to do when I have the time for them" list. And today is the day I finally found the time to do it. In this article I'll show you how I changed the application using the provider based model so you can switch between different providers, including various flavors of SQL Server and Microsoft Access. Adding support for other data stores then becomes really simple.