All Articles

Back in July I wrote an article that showed how you can require your users to confirm their e-mail addresses before they can access your site after signing up for a new account. In this article I describe a similar but slightly different technique where an administrator of the site can approve the account before the user gains access to the site.

A question that comes up often on forums such as p2p.wrox.com is how to let users manage their own data stored in a database. Probably the easiest way to accomplish this is to keep the user name in a separate column. Then when you query the data, you add a WHERE clause that retrieves only those rows that matches the user's name. Likewise, when inserting data, you store the user name along with that data.

But how do you capture the user's name? In the remainder of this article you see a two different ways to retrieve the user name of the currently logged in user.

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.

Over the past couple of weeks I received a number of e-mails from readers with more or less the same question: how do you require users to confirm their e-mail addresses before they are allowed to log in with an account they just created. Rather than answer them individually by e-mail, I decided to write this article to explain the principles.

In versions of ASP.NET before 4.5 there was no direct way to enable a user to upload multiple files at once. The FileUpload control only supported a single file at the time. Common solutions to uploading multiple files were to use a server-side control such as those from Telerik or DevExpress or to use a client-side solution using a jQuery plugin for example. In the latter case, you would access Request.Files to get at the uploaded files, rather than retrieving them form a FileUpload control directly. Fortunately, in ASP.NET 4.5 uploading multiple files is now really easy.

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.

Over the past weeks I received a number of requests to explain how I typically set up my Visual Studio projects so they are easy to manage across a team that uses Team Foundation Server (TFS). I received another request from a client just this week and instead of helping him over the phone or paying him a visit and do it for him, I decided to write a quick document with instructions which eventually resulted in this article.

In this article you'll see how to create a multi-project solution in Visual Studio. I'll show you how you can use this structure to set up an ASP.NET MVC 3 application with a separate class library project for business logic and one or more unit test projects. However, you can use the exact same principles for other types of Visual Studio projects such as Web Forms, Win Forms, WCF and more. Over the past years, I found that this set up brings me the following benefits:

• It has a clear structure, making it easy to figure out where to find or store something
• It can be retrieved from TFS without any hassle
• It allows for easy branching
• It resolves most reference issues to third party assemblies

This is just my take at setting it up. If you find anything wrong, or have better alternatives to accomplish the same thing: feel free to speak up using the Comments section at the end of this article.

Without further ado, let's get started.

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.

Some time ago I received a question on the Wrox P2P forum about checkboxes that should behave like radio buttons. The poster of the question was looking for a (client side) solution to have multiple checkboxes per row in a GridView with multiple rows. A user should only be able to check off at most one of the checkboxes in each row. My first thought was to use radio buttons instead, but then I realized that with radio buttons you lose the ability to uncheck all options. Once you've selected a radio button in a group of radio buttons, there's no way for an end user to uncheck it again.

Fortunately, with a bit of jQuery, this is really simple to accomplish with checkboxes as I'll show you in this short article.

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.