NET 2.0 has the wonderfull user and role provider system, called Membership, which make login, access and role control quite simple. I used this feature in some occasions to full satisfaction. Drawback of the providers is that you either need to incorporate special user/role tables into your database, or write your own provider classes if you want to use your own user/role tables.
One feature I’m particulary fond of is the way the menu component adapts itselfs to the access rules you define for your users. In this post I’m going to explain how to set up a menu system which is controlled by roles without having to use the user/role providers.
As I laid out in post Visual Studio 2005.NET SP 1, there are some problems using business objects inside reporting services reports. The problem in short is that the businessclasses you have defined are not visible inside the “Data Sources” pane of the report editor. I also suggested a possible solution, which is very cumbersome to perform. Here is another possibility to work around this problem.
Today I’ve installed the recently released service pack 1 for Visual Studio.NET 2005. Since at the moment I’m working on a really report-intensive project, I noticed some flaws in the Report Designer (that of reporting services) concerning using custom business objects.
Between .NET programmers there is often the discussion about what to use as the language of programming, especially when a new project needs te be started. This post states my opinions on the subject.