Articles in the category: ASP.NET 4

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.

If you've done any development in ASP.NET, you're probably aware of the presence of the <appSettings /> element in web.config that enables you to store centralized configuration settings. You can use that element to store settings such as e-mail addresses and sender names for outgoing e-mail, settings that determine whether or not to send e-mail in certain conditions, default page sizes and a lot more. While this feature greatly decreases the troubles typically associated with configuration settings in multiple deployment scenarios (development versus a production environment for example), you can use an external component called the Castle DictionaryAdapter to make using the appSettings element even easier.

On a number of pages on this web site I display a list of articles. For example, the home page shows a list of all articles from all categories. The FAQs page shows articles from the FAQs category only. Internally, the content items in the database (sorted in the Content table) are linked through a junction table to the Roles table. This enables me to publish content targeting specific roles. Anonymous users see content for the Anonymous role only, while, for example, I as the site administrator can see content that is assigned to the Administrators role only. I use this in order to add content to my site which is not public yet.

In my (quite possibly very short) series on "things I discovered today in ASP.NET 4", today I am discussing disabling links in ASP.NET 4.

The cool thing about working with beta technology such as Visual Studio 2010 and ASP.NET 4 is that you discover something new every day. Today I found the Sorted Styles that enable you to define the looks of sorted columns and headers in an ASP.NET GridView control.