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.

WebConfigurationManager (and ConfigurationManager) throw exceptions when trying to load a web.config in anything less than High Trust environments. The sole reason for this being that the local web.config is merged all the way down from the machine-level web.configs, via any parent applications in IIS.

Better idea: put all inherited configs into a read-only dictionary at runtime (rather than putting the ConfigurationManager settings into a dictionary, which is what actually happens, therefore preventing writing back of a .config file to disk after modifying a setting). When the web.config is loaded at runtime, take the inherited settings dictionaries, apply them to the local web.config settings. Then, in the setters of the strongly-typed classes, check whether the setting is local or not. If yes, write to the file and allow save, if no, check if over-rides are allowed for the setting. If yes, add the new setting and save. If no, exception out.

When using an inbult ASP.Net control you're stuck with the default rendered HTML output and changing the output is a tedious and time consuming task.

Allow the user to create a template to be assigned to a control, so when this control (for instance something as simple as the HTML rendered by using a ASP.Net Panel control, could be used) - this would also allow you to assign CSS defaults, control properties etc to the control whenever it's used.

This would eliminate the need for the user to manually assign a class or specific property to the control whenever it's used.

This should be set on a global and/or per project scale (eg. be a editable property of the project).

The AspNetCompiler task has a great many features, and among them is the ability to specify a particular version of the ASP.NET compiler to use via ToolPath. Websites inside solution files contain constructs similar to AspNetCompiler tasks, but these seem to be missing support for ToolPath, and I suspect support for other properties as well. My solution looks like this:

ProjectSection(WebsiteProperties) = preProject

SccProjectName = "SAK"

SccAuxPath = "SAK"

SccLocalPath = "SAK"

SccProvider = "SAK"

TargetFrameworkMoniker = ".NETFramework,Version%3Dv4.0"

Debug.AspNetCompiler.VirtualPath = "/MyPath"

Debug.AspNetCompiler.PhysicalPath = "MyPath\"

Debug.AspNetCompiler.TargetPath = "PrecompiledWeb\MyPath\"

Debug.AspNetCompiler.Updateable = "true"

Debug.AspNetCompiler.ForceOverwrite = "true"

Debug.AspNetCompiler.FixedNames = "false"

Debug.AspNetCompiler.Debug = "True"

Debug.AspNetCompiler.ToolPath = "C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe"

Release.AspNetCompiler.VirtualPath = "/MyPath"

Release.AspNetCompiler.PhysicalPath = "MyPath\"

Release.AspNetCompiler.TargetPath = "PrecompiledWeb\MyPath\"

Release.AspNetCompiler.Updateable = "true"

Release.AspNetCompiler.ForceOverwrite = "true"

Release.AspNetCompiler.FixedNames = "false"

Release.AspNetCompiler.Debug = "False"

Release.AspNetCompiler.ToolPath = "C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe"

VWDPort = "62641"

EndProjectSection

In the sln.metaproj file that is generated by MSBuild this maps to:

<AspNetCompiler Condition="(false) or ('$(AspNetConfiguration)' == 'Debug') or ('$(AspNetConfiguration)' == 'Release')" VirtualPath="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetVirtualPath)" PhysicalPath="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetPhysicalPath)" TargetPath="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetTargetPath)" Force="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetForce)" Updateable="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetUpdateable)" Debug="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetDebug)" KeyFile="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetKeyFile)" KeyContainer="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetKeyContainer)" DelaySign="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetDelaySign)" AllowPartiallyTrustedCallers="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetAPTCA)" FixedNames="$(Project_E6D3E448-55BC-48DC-9D7F-98782DE8AFF6_AspNetFixedNames)" ToolPath="C:\Windows\Microsoft.NET\Framework64\v4.0.30319" />

Note that MSBuild is not generating a property for ToolPath at all. Anything I enter for ToolPath value in the solution file is simply ignored.

MSBuild should support all of the parameters for the AspNetCompiler task when performing the solution->metaproj conversion.

Right now the files served from your CDN at least jquery.validate are served without an Expires or Cache-Control max-age

What this means is that every request has to recheck the files and get a 304 which delays page rendering.

For now it looks like I will have to use jquery.validate from elsewhere I just wanted to use a CDN to increase the chance of the file being cached but with no chance of it really being cached (and saving a round trip) there is not much point in using the microsoft CDN right now.

I actually have a video that covers why this is important that I made for a class http://ontwik.com/python/permanent-url-caching/

In the ASP.NET security model, the documentation goes out of its way to talk about the difference between Authorization and Authentication.

Unfortunately, the framework itself makes no such distinction. It treats an unauthenticated user access the same as a user who does not have authorization and returns the same error.

I realize this is probably a result of the fact that most web servers treat file access errors as 403's, because HTTP doesn't really give you any other status code, and you want to differentiate between server oriented 403's and framework generated 403's, but there must be a better way of dealing with this.

I suggest that the framework should not respond with a 401 if the user is authenticated, but rather a 403.something code maybe.