Hi,
I've had a specific problem with the UserController / DNNMembership
provider code which I've found a work-around to so I'm posting my
solution in case anyone else finds it useful or can point out any
problems in my thinking...
First a bit of background:
My website solution using DotNetNuke required an daily user-import
process to import users from external data. This process runs under the
DNN webapp within its own Thread so that you can set it running
via a web interface but not have to wait for it to complete before
viewing the next screen (which in this case is a little web control
that displays a progress report for the running import process).
The problem with this approach was that DNNSQLMembership provider (and
other similar providers such as DNNSQLRoleProvider etc) use the
HTTPContext.Current object to store an "ApplicationName" property:
HttpContext.Current.Items("ApplicationName") = ApplicationName
When called from a Thread other than within a Request/Response,
HTTPContext.Current is null which meant that the UserController.AddUser
was throwing a null object exception when called from my import process
Thread.
My fix is to add a null-check and then use a "ThreadLocal " [java terminology ;-) ] property if HTTPContext.Current is null
So the Set function of DNNSQLProvider.ApplicationName() becomes:
Set(ByVal Value As String)
If (HttpContext.Current Is Nothing) Then
System.Threading.Thread.SetData(System.Threading.Thread.GetNamedDataSlot("ApplicationName"),
ApplicationName)
Else
HttpContext.Current.Items("ApplicationName") = ApplicationName
End If
End Set
This works by attaching the value to the local Thread rather than HTTPContext.
I applied this approach wherever I found HttpContext.Current.Items("ApplicationName") in the DNN Solution and can now modify users from my Thread.
I suspect this fix may be useful to anyone who intends to modify users from the DNNScheduler.
hope someone finds this useful - If so, I can provide more details...
Brendan.