Using mvc-mini-profiler database profiling with Entity Framework Code First - ef-code-first

I'm using the mvc-mini-profiler in my project built with ASP.Net MVC 3 and Entity Framework code-first.
Everything works great until I attempt to add database profiling by wrapping the connection in the ProfiledDbConnection as described in the documentation. Since I'm using a DbContext, the way I am attempting to provide the connection is through the constructor using a static factory method:
public class MyDbContext : DbContext
{
public MyDbContext() : base(GetProfilerConnection(), true)
{ }
private static DbConnection GetProfilerConnection()
{
// Code below errors
//return ProfiledDbConnection.Get(new SqlConnection(ConfigurationManager.ConnectionStrings["MyConnectionName"].ConnectionString));
// Code below works fine...
return new SqlConnection(ConfigurationManager.ConnectionStrings["MyConnectionName"].ConnectionString);
}
//...
}
When using the ProfiledDbConnection, I get the following error:
ProviderIncompatibleException: The provider did not return a ProviderManifestToken string.
Stack Trace:
[ArgumentException: The connection is not of type 'System.Data.SqlClient.SqlConnection'.]
System.Data.SqlClient.SqlProviderUtilities.GetRequiredSqlConnection(DbConnection connection) +10486148
System.Data.SqlClient.SqlProviderServices.GetDbProviderManifestToken(DbConnection connection) +77
System.Data.Common.DbProviderServices.GetProviderManifestToken(DbConnection connection) +44
[ProviderIncompatibleException: The provider did not return a ProviderManifestToken string.]
System.Data.Common.DbProviderServices.GetProviderManifestToken(DbConnection connection) +11092901
System.Data.Common.DbProviderServices.GetProviderManifestToken(DbConnection connection) +11092745
System.Data.Entity.DbModelBuilder.Build(DbConnection providerConnection) +221
System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext) +61
System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input) +1203482
System.Data.Entity.Internal.LazyInternalContext.InitializeContext() +492
System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType) +26
System.Data.Entity.Internal.Linq.InternalSet`1.Initialize() +89
System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext() +21
System.Data.Entity.Infrastructure.DbQuery`1.System.Linq.IQueryable.get_Provider() +44
System.Linq.Queryable.Where(IQueryable`1 source, Expression`1 predicate) +135
I have stepped through and the type returned by ProfiledDbConnection.Get is of type ProfiledDbConnection (Even if the current MiniProfiler is null).
The MiniProfiler.Start() method is called within the Global Application_BeginRequest() method before the DbContext is instantiated. I am also calling the Start method for every request regardless but calling stop if the user is not in the correct role:
protected void Application_BeginRequest()
{
// We don't know who the user is at this stage so need to start for everyone
MiniProfiler.Start();
}
protected void Application_AuthorizeRequest(Object sender, EventArgs e)
{
// Now stop the profiler if the user is not a developer
if (!AuthorisationHelper.IsDeveloper())
{
MvcMiniProfiler.MiniProfiler.Stop(discardResults: true);
}
}
protected void Application_EndRequest()
{
MiniProfiler.Stop();
}
I'm not sure if this affects things but I'm also using StructureMap as IoC for the DbContext using the following initialiser:
For<MyDbContext>().Singleton().HybridHttpOrThreadLocalScoped();
I understand that there is a similar question on here with a good explanation of what's happening for that user, however it doesn't seem to solve my problem.
EDIT:
For clarity. I am attempting to pass the connection as ProfiledDbConnection in order to profile the generated sql from Entity Framework Code First.
The Entity Framework is expecting a connection with type SqlConnection which of course this isn't.
Here is an example of my connection string (notice the providerName)
<add name="MyDbContext" connectionString="Server=.\SQLEXPRESS; Database=MyDatabase;Trusted_Connection=true;MultipleActiveResultSets=true" providerName="System.Data.SqlClient" />
I attempted to create my own version of the ProfiledDbConnection inheriting from SqlConnection but it is a sealed class.
If there is some way of telling Entity Framework about the custom connection type then perhaps this would work. I tried setting the providerName in the connection string to MvcMiniProfiler.Data.ProfiledDbConnection but that didn't work.
So. Perhaps an evolution of the question would be: How can you pass a custom connection type to Entity Framework Code First?

This is now fully supported, check out the latest source or grab the package from nuget.
You will need the MiniProfiler.EF package if you are using nuget. (1.9.1 and up)
Supporting this involved a large set of modifications to the underlying proxy object to support acting as EF code first proxies.
To add this support:
During your Application_Start run:
MiniProfilerEF.Initialize();
Note: EF Code First will store table metadata in a table called: EdmMetadata. This metadata uses the provider as part of the entity key. If you initialized your provider as a non-profiled provider, you will have to re-build this metadata. Deleting all the rows from EdmMetadata may do the trick, alternatively some smarter providers are able to handle this transparently.

I was still having problems getting this to work and found that I needed to rename or remove the connection string to get Database.DefaultConnectionFactory to work.
Please refer to this answer for more detail.

This error in my experience has always been an invalid connection string, or a lack of connection to the DB, like "A network service error occurred while connecting...".
Also note that the DbContext just needs the "connectionStringKey" in the constructor, like
public MyDbContext() :
base("MyConnectionName", true)
{ }

Related

EF Core FromSQLRaw is not calling the database?

I need to rewrite an old web service because the team that supported the old one no longer wants to support it with their new tool. So I'm rewriting it using ASP.NET Core WebAPI and EF Core 3.1.
The majority of the logic for the service is stuck in stored procedures written years ago. Nothing super complex, but don't really think it's a good idea to start rewriting everything.
The problem is that EF Core's support for stored procs seems lacking at best. I got one working using Database.ExecuteSqlRaw which returns the results as output parameters, but I'm having trouble with another that returns the results as a dataset. (Actually two, but let's not get ahead of ourselves... I've commented it so it's only returning one right now.)
The (current) problem with the .FromSqlRaw query is that it doesn't appear to be querying the database at all when I watch for it in XEvent Profiler. (SQL Server 2016.)
Here's the code I'm using to call the proc:
var bundle_id = new SqlParameter("bundle_id", bundleID) { Direction = ParameterDirection.Input };
var result = this.BundleUserGuideDetails.FromSqlRaw("EXEC dbo.p_fetch_user_guide_details #bundle_id", bundle_id);
var deets = result.FirstOrDefault<BundleUserGuideDetail>();
I did create a DBSet for it in the DBContext class:
public DbSet<BundleUserGuideDetail> BundleUserGuideDetails { get; set; }
And since it's a keyless type I've got this per Microsoft's Keyless Entity guide:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<BundleUserGuideDetail>(eb =>
{
eb.HasNoKey();
});
}
The model I created has all the same field names as the data being returned as well.
So why is the DB not even getting called for this?
EDIT: Forgot to write that the call to FirstOrDefault is throwing "System.InvalidOperationException: 'Sequence contains no elements'"
EDIT: Here is the full exception text:
System.InvalidOperationException: Sequence contains no elements
at System.Linq.ThrowHelper.ThrowNoElementsException()
at System.Linq.Enumerable.Aggregate[TSource](IEnumerable`1 source, Func`3 func)
at Microsoft.EntityFrameworkCore.Query.ShapedQueryCompilingExpressionVisitor.EntityMaterializerInjectingExpressionVisitor.ProcessEntityShaper(EntityShaperExpression entityShaperExpression)
at Microsoft.EntityFrameworkCore.Query.ShapedQueryCompilingExpressionVisitor.EntityMaterializerInjectingExpressionVisitor.VisitExtension(Expression extensionExpression)
at System.Linq.Expressions.Expression.Accept(ExpressionVisitor visitor)
at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
at System.Linq.Expressions.ExpressionVisitor.VisitBinary(BinaryExpression node)
at System.Linq.Expressions.BinaryExpression.Accept(ExpressionVisitor visitor)
at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
at System.Dynamic.Utils.ExpressionVisitorUtils.VisitBlockExpressions(ExpressionVisitor visitor, BlockExpression block)
at System.Linq.Expressions.ExpressionVisitor.VisitBlock(BlockExpression node)
at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor visitor)
at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
at System.Linq.Expressions.ExpressionVisitor.VisitLambda[T](Expression`1 node)
at System.Linq.Expressions.Expression`1.Accept(ExpressionVisitor visitor)
at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
at Microsoft.EntityFrameworkCore.Query.ShapedQueryCompilingExpressionVisitor.EntityMaterializerInjectingExpressionVisitor.Inject(Expression expression)
at Microsoft.EntityFrameworkCore.Query.ShapedQueryCompilingExpressionVisitor.InjectEntityMaterializers(Expression expression)
at Microsoft.EntityFrameworkCore.Query.RelationalShapedQueryCompilingExpressionVisitor.VisitShapedQueryExpression(ShapedQueryExpression shapedQueryExpression)
at Microsoft.EntityFrameworkCore.Query.ShapedQueryCompilingExpressionVisitor.VisitExtension(Expression extensionExpression)
at System.Linq.Expressions.Expression.Accept(ExpressionVisitor visitor)
at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
at Microsoft.EntityFrameworkCore.Query.QueryCompilationContext.CreateQueryExecutor[TResult](Expression query)
at Microsoft.EntityFrameworkCore.Storage.Database.CompileQuery[TResult](Expression query, Boolean async)
at Microsoft.EntityFrameworkCore.Query.Internal.QueryCompiler.CompileQueryCore[TResult](IDatabase database, Expression query, IModel model, Boolean async)
at Microsoft.EntityFrameworkCore.Query.Internal.QueryCompiler.<>c__DisplayClass9_0`1.<Execute>b__0()
at Microsoft.EntityFrameworkCore.Query.Internal.CompiledQueryCache.GetOrAddQueryCore[TFunc](Object cacheKey, Func`1 compiler)
at Microsoft.EntityFrameworkCore.Query.Internal.CompiledQueryCache.GetOrAddQuery[TResult](Object cacheKey, Func`1 compiler)
at Microsoft.EntityFrameworkCore.Query.Internal.QueryCompiler.Execute[TResult](Expression query)
at Microsoft.EntityFrameworkCore.Query.Internal.EntityQueryProvider.Execute[TResult](Expression expression)
at System.Linq.Queryable.FirstOrDefault[TSource](IQueryable`1 source)
at MandTBank.BBFB.BPS.BPSWebAPI.Data.BundleSystemContext.FetchUserGuideDetails(String bundleID) in C:\Users\tdevmcr\Source\Workspaces\BBFB\NeedsAssessmentSystem\Main\Sourcecode\BBFB NAS - I3 - BundleUserGuide Service\MandTBank.BBFB.BPS.BPSWebAPI\Data\BundleSystemContext.cs:line 65
Turns out I had made a simple mistake, and failed to make the fields in the model public
The exception being thrown certainly doesn't make that obvious though...
I also needed to add AsEnumerable() after the FromSqlRaw call for it to work, as per this question: Include with FromSqlRaw and stored procedure in EF Core 3.1

How to make database connection persistent across webforms

I am writing an application using ASP.NET webforms with login dialog. After successfull authentication the connection is opened, but connection object is not visible from other webforms. Is there any way to make it persistent and accessible (in some server session objects), or is it commonly done in another way ? Any tips appreciated.
The best way is to open/close the connection where you want to use it. Don't share it and never use a static connection in ASP.NET which is a multi-threading environment. You should use the using statement for all objects implementing IDisposable which ensures that all unmanaged resources are disposed. This will also close the connection, even on error:
using(var con = new SqlConnection("connection string here"))
{
// do something ...
}
You don't need to be afraid that the physical connection must be opened/closed everytime. The .NET connection pool will handle that for you. Related
A simple example.
Set up a class to handle the SqlConnection object (or whatever DB you're using):
DbConnectionProvider.cs
using System.Data.SqlClient
public class DbConnectionProvider
{
public static SqlConnection GetDbConnection()
{
return new SqlConnection("MyConnectionString");
}
}
Then from all classes that needs to use the database
ApplicationClass.cs
using System.Data.SqlClient
public class ApplicationClass
{
private void GetSomeDbWorkDone()
{
using(SqlConnection Conn = DbConnectionProvider.GetDbConnection())
{
//Do some fancy database operations here
}
}
}
This way, if you need to change your Connection details or do something else regarding the SqlConnection object, you only need to do it once and not everywhere in your code.

All MVC pages fail with the message an item with the same key has already been added

Ultimately I am trying to address the same issue that is referenced in Loading any MVC page fails with the error “An item with the same key has already been added.” and An item with the same key has already been added. A duplicate of the first link is All MVC pages fail with the message an item with the same key has already been added but it has some additional pertinent information, confirming that it only effects MVC pages, while webforms and other aspects of the application that deal with appSettings continue to work without error.
I have now seen this four times in production and it has not been seen in any other environment (dev, test, UAT). I have closely examined and debugged through the source code of System.Web.WebPages and the relevant sections of the MVC stack but did not run into anything that stood out. This problem has persisted through a migration from MVC3 to MVC4, and the latest changeset from aspnetwebstack.codeplex.com does not appear to address this issue.
A quick summary of the issue:
Every MVC page is affected and completely unusable
WebForms and other aspects of the application that use appSettings continue to work just fine
Only an appPool restart will correct this issue
At least once and as referenced in an article above, this has happened after a regular time interval recycle of the appPool by IIS
This has happened during both low and high volume traffic periods
This has happened on multiple production servers, but the issue only affects a single server at any given time, as other servers continue serving MVC pages
The offending line of code is var items = new Lazy<Dictionary<object, object>>(() => appSettings.AllKeys.ToDictionary(key => key, key => (object)appSettings[key], comparer));, but it occurs when the lazy initialization is forced by requesting a value from items The appSettings variable is from System.Web.WebConfigurationManager.AppSettings which is a direct static reference to System.Configuration.ConfigurationManager.AppSettings. So I beleive the line is equivalent to: var items = new Lazy<Dictionary<object, object>>(() => System.Configuration.ConfigurationManager.AppSettings.AllKeys.ToDictionary(key => key, key => (object)appSettings[key], comparer));
I rarely suspect framework issues, but it appears that appSettings has two distinct keys that are the same (not the same as a NameValueCollection supporting multiple values for the same key). The comparer being used in the MVC stack is the StringComparer.OrdinalIgnoreCase which appears to match what is used by the configuration system. If this is a framework issue, the MVC stack appears to be very unforgiving when it forces the NameValueColleciton into a dictionary using the ToDictionary() extension method. I believe using appSettings.AllKeys.Distinct().ToDictionary(...) would probably allow the MVC stack to operate normally as the rest of the application does and be oblivious to the possibility of duplicate keys. This unforgiving nature appears to also contribute to the issue described in NullReferenceException in WebConfigScopeDictionary
Server stack trace:
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)
at System.Web.WebPages.Scope.WebConfigScopeDictionary.<>c__DisplayClass4.<.ctor>b__0()
at System.Lazy`1.CreateValue()
Exception rethrown at [0]:
at System.Lazy`1.get_Value()
at System.Web.WebPages.Scope.WebConfigScopeDictionary.TryGetValue(Object key, Object& value)
at System.Web.Mvc.ViewContext.ScopeGet[TValue](IDictionary`2 scope, String name, TValue defaultValue)
at System.Web.Mvc.ViewContext.ScopeCache..ctor(IDictionary`2 scope)
at System.Web.Mvc.ViewContext.ScopeCache.Get(IDictionary`2 scope, HttpContextBase httpContext)
at System.Web.Mvc.ViewContext.GetClientValidationEnabled(IDictionary`2 scope, HttpContextBase httpContext)
at System.Web.Mvc.Html.FormExtensions.FormHelper(HtmlHelper htmlHelper, String formAction, FormMethod method, IDictionary`2 htmlAttributes)
at ASP._Page_Areas_Client_Views_Equipment_Index_cshtml.Execute()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
at System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context)
at System.Web.Mvc.ControllerActionInvoker.<>c__DisplayClass1a.<InvokeActionResultWithFilters>b__17()
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func`1 continuation)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IList`1 filters, ActionResult actionResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.<BeginInvokeAction>b__22(IAsyncResult asyncResult)
at System.Web.Mvc.Controller.<>c__DisplayClass1d.<BeginExecuteCore>b__18(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
at System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
at System.Web.Mvc.MvcHandler.<>c__DisplayClass8.<BeginProcessRequest>b__3(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
To separate my question from the questions already asked, I will ask has anyone seen the configuration system be corrupted with multiple duplicate keys or where a NameValueCollection.AllKeys returns two identical keys? I know you can have multiple keys defined in the config file, but the last key wins, and that scenario does not reproduce this issue.
Although I am not alone in seeing this behavior multiple times, there are relatively few posts describing this issue, so I also suspect that it might be a configuration/environmental issue, but again, servers will run for months without experiencing this issue, and an appPool restart immediately corrects the problem.
I have mitigated this issue by forcing an appPool restart if a server starts seeing this error, but management is not happy about this "hacky" solution because some user will still experience an error.
Help?!?!?
EDIT:
Here is a contrived, cheezy test that can reproduce the scenario, but doesn't help in solving the issue. It happens during approx. 20% of the test runs. The code will blow up for other threading reasons, but it is the "Same key has already been added" error that is of interest.
[TestClass]
public class UnitTest1
{
readonly NameValueCollection _nameValueCollection = new NameValueCollection();
private Lazy<Dictionary<object, object>> _items;
[TestMethod]
public void ReproduceSameKeyHasAlreadyBeenAdded()
{
Thread[] threads = new Thread[1000];
for (int i = 0; i < 1000; i++)
{
ThreadStart threadStart = AddEntry;
Thread thread = new Thread(threadStart);
threads[i] = thread;
}
foreach (var thread in threads)
thread.Start();
Thread.Sleep(100);
_items = new Lazy<Dictionary<object, object>>(() => _nameValueCollection.AllKeys.ToDictionary(key => key, key => (object)_nameValueCollection[key], ScopeStorageComparer.Instance));
object value;
_items.Value.TryGetValue("4", out value); // approx. 20% of time, blows up here with mentioned error
Assert.IsTrue(value != null);
}
private int _counter;
private void AddEntry()
{
_counter++;
try
{ // add a bunch of even keys, every other one a duplicate
_nameValueCollection.Add((_counter%2) == 0 ? _counter.ToString() : (_counter + 1).ToString(), "some value");
}
catch {}
}
}
StackTrace:
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)
at UnitTestProject1.ReproduceSameKeyHasAlreadyBeenAdded.<TestMethod1>b__0() in c:\Git\AspNetWebStack\aspnetwebstack\UnitTestProject1\UnitTest1.cs:line 37
at System.Lazy`1.CreateValue()
We came across this same issue and finally tracked it down to dynamic updating of the ConfigurationManager.AppSettings collection. I have posted a full answer here: https://stackoverflow.com/a/17415830/2423407
Are you absolutely positive the error is occurring on the line where you are initializing items and not the line on which items is being used to add to some other dictionary (Static I would presume).
To me the most likely way this would occur is if the code was executed in parallel (by two concurrent users) and the second one executing causing the exception.
As a general workaround I usually initialize a strongly typed class with all configuration parameters as an auto-start provider (and add some strongly-typed type checking of the values as well, such as checking that an int is an int, etc) to avoid run-time errors.
This has the double benefit of loading these at warmup, not when the users want the info (better response performance) and thread-safety is supposedly guaranteed with them as well.
See if that doesn't fix your issue. If you do not want to do that I would at the very least try to execute the code that is failing for you with multiple threats hitting it, as my guess would be that you will see your error occur fairly reliably.

Abstracting HttpContext Request and Session - thread safety

I have the following assemblies in my ASP.NET app:
Website - this is an ASP.NET website
ClassLib - this is just a class lib that contains all the business logic
Class Lib needs to interact with the HttpContext Session and Request objects. This is a code upgrade from an old ASP app, where I've hoovered all the VBScript that contained the logic and put it into VB.NET. We simply didn't have time to rewrite.
Instead of ClassLib interacting directly with HttpContext, which I thought was BAD and also prevented us from unit testing, I introduced the following abstraction layer:
Public Class Request
Private Shared _requestWrapper as IRequestWrapper
Public Shared ReadOnly Property RequestWrapper()
Get
If _requestWrapper Is Nothing Then
Throw New Exception("_requestWrapper is null. Make sure InitRequest() is called with valid parameters")
End If
Return _requestWrapper
End Get
End Property
Public Shared Sub InitRequest(ByRef requestWrapper As IRequestWrapper)
_requestWrapper = requestWrapper
End Sub
Public Shared Function GetVal(ByVal key As String) As Object
Return RequestWrapper.GetVal(key)
End Function
etc.
This means in the unit tests I can supply my own MockRequest object into this Request class, which is just a simple NameValue collection. The code in the ClassLib and the Website then simply use the Request class and are none the wiser that it isn't coming from the HttpContext, but rather this mock class.
When it comes to the real deal, I simply have the following (C#) class:
public class RealRequest : IRequestWrapper
{
public void Initialize(HttpContext context)
{
}
#region Implementation of IRequestWrapper
public object GetVal(string index)
{
return HttpContext.Current.Request[index];
}
etc.
This is initialised in Session_Start of global.asax in the Website, as follows:
protected void Session_Start(object sender, EventArgs e)
{
IRequestWrapper requestWrapper = new RealRequest();
WebSession.Request.InitRequest(ref requestWrapper);
}
I think this is similar to the Static Gateway pattern.
Now, I am aware of singletons and static vars in a multi threaded environment such as ASP.NET, but this is slightly different. When it gets down to the RequestWrapper.GetVal(), its actually going to the HttpContext for that running thread - and pulling the value from that.
Certainly, any concurrent tests that we do with multiple users hitting the same server have never shown up any strange behaviour.
I'm just looking for re-assurance that this is a sound design, and if not why not?
Thanks
Duncan
This is fine. We have a very similar case in our applications that either uses HttpContext if it exists or fake implementations otherwise.
The one thing to watch out for is that there is a very specific instance where HttpContext.Current will return a value but HttpContext.Current.Request will throw an exception when triggered by the Application_Start event. In framework code, you really don't know (or want to know) what triggered the call though.
Workaround for HttpContext.HideRequestResponse being internal? Detect if HttpContext.Request is really available?

ASP.NET user database without web.config connection strings

I'm wondering whether it's possible to use built in ASP.NET application services (aspnet_user, aspnet_role etc table) without specifying a connection string in a web.config.
At the moment I store connection strings externally, but I keep finding hard-coded connection strings all over the web.config xml, various providers etc. It's driving me crazy.
Thank you
You can write your own provider via overriding already existed, built-in class so it will read it's connection string from somewhere else:
public class MyMembershiProvider : SqlMembershiProvider
{
public override void Initialize(string name, NameValueCollection config)
{
config["connectionString"] = "what ever you want";
base.Initialize(name, config);
}
}

Resources