Synclock in Begin request must be bad right?

[Rory Becker]

I have had code in my Application_Sta rt which is intended to run once at
the start of my application's life.

It loads connection information and similar from a known location.

However I recently migrated my app using
-------------------------------------------------------------
%systemroot%\sy stem32\inetsrv\ APPCMD.EXE migrate config "Default Web Site/YourApp"
-------------------------------------------------------------

At which point my app's startup code was denied access to the request object.

I found a workaround which was to place the following code in the beginrequest

-------------------------------------------------------------
Private Shared InitializeLock As New Object
Private Shared InitializedAlre ady As Boolean
Sub Application_Beg inRequest(ByVal sender As Object, ByVal e As EventArgs)
' Fires at the beginning of each request
SyncLock InitializeLock
If Not InitializedAlre ady Then

' My Initialise code goes here.

InitializedAlre ady = True
End If
End SyncLock
End Sub
-------------------------------------------------------------

This does work but I'm worried about performance

[Rory Becker]

Damn "Send" hotkeys. Sorry about that. I sent the previous message before
I was done writing it.

This does work but I'm worried about performance

Specifically it occurs to be that I now have a bottleneck in my application
which only one request can pass through at any one time.

This does not seem good for a web site.

Please tell me there is a better way.
Thanks in advance for any help.

--
Rory

[Rory Becker]

Ok move on nothing to see here.

Just some shmuck accessing...

-------------------------------------------------------------
HttpContext.Cur rent.Request.Ap plicationPath
-------------------------------------------------------------

....from Application_sta rt when...

-------------------------------------------------------------
HttpRuntime.App DomainAppVirtua lPath
-------------------------------------------------------------
....would have worked just as well

[Steven Cheng [MSFT]]

Hi Rory,

From your previous messages, you currently encounter the following two
problems, correct?

1.the code in your ASP.NET's Application_Sta rt event which access a
certain object fails(with Access denied) after you switch to a new IIS
directory.

2. You can not get "HttpContext.Cu rrent.Request.A pplicationPath" property
work in Application_Sta rt event

As for the 1st problem, I wonder what is the exact object you're trying to
access, is it an COM object or something else, would you provide some code
snippet or further description? Such "Access denied" error is commonly
caused by security permission issues, therefore, is that certain object
access permission sensitive? If so, have you used "impersonat e" in your
ASP.NET web application. If you have used impersonate, the security account
under which the ASP.NET code executes are different between
Application_Sta rt and the "Begin_Request" (or any other page level event).
This is because Application_Sta rt executes at application level(there may
not exists any request context), it runs under ASP.NET worker process
account. Why "Begin_Requ est" is under the certain ASP.NET client request's
context, if you have used imperonate, it is running under the impersonate
account.
for the 2nd problem, it is actuall the same with the 1st one,
"HttpContext.Cu rrent.Request.A pplicationPath" this is a property coupled
with the current request's "HttpContex t". For each client request to
ASP.NET application, the runtime will attach an HttpContext object with the
request(during the server-side processing lifecycle). However,
Applicaiton_sta rt event is not a Request based event, it is just a global
application level event, there is no HttpContext associated with it,
therefore, if you try accessing any Httpcontext coupled property in it,
that will not be available.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.

=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

>Date: Tue, 10 Jun 2008 11:30:57 +0000 (UTC)
Message-ID: <20************ **************@ news.microsoft. com>
From: Rory Becker <ro********@new sgroup.nospam>
Subject: Re: Synclock in Begin request must be bad right?

>

Damn "Send" hotkeys. Sorry about that. I sent the previous message before
I was done writing it.

>This does work but I'm worried about performance

Specifically it occurs to be that I now have a bottleneck in my

application

>which only one request can pass through at any one time.

This does not seem good for a web site.

Please tell me there is a better way.
Thanks in advance for any help.

--
Rory

>

[Rory Becker]

Hello Steven Cheng [MSFT],

Hi Rory,

From your previous messages, you currently encounter the following two
problems, correct?

1.the code in your ASP.NET's Application_Sta rt event which access a
certain object fails(with Access denied) after you switch to a new IIS
directory.

My appologies if I gave the wrong impression here I am in fact able to access
the file in question, however I was having difficulty locating it as I needed
to locate the applications root directory and base it's location on that.
given that problem 2 is now solved, problem 1 ceases to exist.

>
2. You can not get "HttpContext.Cu rrent.Request.A pplicationPath"
property work in Application_Sta rt event

This was indeed the case.

for the 2nd problem, it is actuall the same with the 1st one,
"HttpContext.Cu rrent.Request.A pplicationPath" this is a property
coupled with the current request's "HttpContex t". For each client
request to ASP.NET application, the runtime will attach an HttpContext
object with the request(during the server-side processing lifecycle).
However, Applicaiton_sta rt event is not a Request based event, it is
just a global application level event, there is no HttpContext
associated with it, therefore, if you try accessing any Httpcontext
coupled property in it, that will not be available.

However it did used to fire at a point in time when there was an httprequest
available. It is only since the migration that this event has shifted.

This however has led to my discovery of 'HttpRuntime.Ap pDomainAppVirtu alPath'
which needs no such request to determine the information needed.
Thanks for your help anyway though

--
Rory

[Steven Cheng [MSFT]]

Thanks for your quick reply Rory,

I'm glad that you've found the solution. Yes, For ASP.NET web application,
in Application level event, it is better to avoid using those object which
is specific to HttpContext/Request. And the AppDomain properties you found
is not specific to any request context, but keep available based on the
given ASP.NET application(a certain .net AppDomain).

If you have any further questions, also welcome to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.

=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no
rights.--------------------

>Date: Wed, 11 Jun 2008 07:23:52 +0000 (UTC)
Message-ID: <3a************ **************@ news.microsoft. com>
From: Rory Becker <ro********@new sgroup.nospam>
Subject: Re: Synclock in Begin request must be bad right?

>Hello Steven Cheng [MSFT],

>Hi Rory,

From your previous messages, you currently encounter the following two
problems, correct?

1.the code in your ASP.NET's Application_Sta rt event which access a
certain object fails(with Access denied) after you switch to a new IIS
directory.

My appologies if I gave the wrong impression here I am in fact able to

access

>the file in question, however I was having difficulty locating it as I

needed

>to locate the applications root directory and base it's location on that.
given that problem 2 is now solved, problem 1 ceases to exist.

>>
2. You can not get "HttpContext.Cu rrent.Request.A pplicationPath"
property work in Application_Sta rt event

This was indeed the case.

>for the 2nd problem, it is actuall the same with the 1st one,
"HttpContext.C urrent.Request. ApplicationPath " this is a property
coupled with the current request's "HttpContex t". For each client
request to ASP.NET application, the runtime will attach an HttpContext
object with the request(during the server-side processing lifecycle).
However, Applicaiton_sta rt event is not a Request based event, it is
just a global application level event, there is no HttpContext
associated with it, therefore, if you try accessing any Httpcontext
coupled property in it, that will not be available.

However it did used to fire at a point in time when there was an

httprequest

>available. It is only since the migration that this event has shifted.

This however has led to my discovery of

'HttpRuntime.Ap pDomainAppVirtu alPath'

>which needs no such request to determine the information needed.
Thanks for your help anyway though

--
Rory

>