Make SecUtility and other utility classes public rather than internal sealed
I'm trying to build my own role provider for ASP.NET that supports nested hierarchies for roles - like Active Directory, but SQL-based (as an LDAP server is somewhat overkill for my needs, and yes I've seen the new stuff about Windows Azure AD services).
Having reflected (using ILSpy) the deault SqlRoleProvider to keep my code almost identical, I find that most of the classes utilised in there, such as System.Web.Util.SecUtility for parameter checking, System.Web.DataAccess.SqlConnectionHolder for attaching a SQL connection to an HttpContext for application re-use, and System.Web.SR for string resources, are all marked as internal (and in some instances sealed), and therefore cannot be accessed by third-party libraries.
Please can you make these classes public and virtual, as they're kinda useful, and I'd like to be able to use the utilities in the above described classes, and over-ride them with my own implementations in some instances.
Benjamin Howarth commented
Thanks Damian. I have the new providers referenced in my project as it's MVC4 with OData and Web API, but ModelHelper, QueryHelper and ValidationHelper are all still internal static, and therefore cannot be utilised by any derived providers. As much as the provider model is "simpler", my point still kinda stands...
Thank you for the feedback. I suggest you take a look at our new SQL providers on NuGet (http://nuget.org/packages/Microsoft.AspNet.Providers) as they're the recommended SQL providers now.