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 InitializedAlready As Boolean
Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
' Fires at the beginning of each request
SyncLock InitializeLock
If Not InitializedAlready Then

' My Initialise code goes here.

InitializedAlready = True
End If
End SyncLock
End Sub
-------------------------------------------------------------

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

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

2. You can not get "HttpContext.Current.Request.ApplicationPath" property
work in Application_Start 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 "impersonate" 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_Start and the "Begin_Request"(or any other page level event).
This is because Application_Start executes at application level(there may
not exists any request context), it runs under ASP.NET worker process
account. Why "Begin_Request" 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.Current.Request.ApplicationPath" this is a property coupled
with the current request's "HttpContext". 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_start 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: .

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/subscriptions/support/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: <>
>From: Rory Becker <>
>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
>
>

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.Current.Request.ApplicationPath"
> property work in Application_Start event

This was indeed the case.

> for the 2nd problem, it is actuall the same with the 1st one,
> "HttpContext.Current.Request.ApplicationPath" this is a property
> coupled with the current request's "HttpContext". 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_start 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.AppDomainAppVirtualPath'
which needs no such request to determine the information needed.

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: .

==================================================
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: <>
>From: Rory Becker <>
>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_Start 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.Current.Request.ApplicationPath"
>> property work in Application_Start event
>
>This was indeed the case.
>
>
>> for the 2nd problem, it is actuall the same with the 1st one,
>> "HttpContext.Current.Request.ApplicationPath" this is a property
>> coupled with the current request's "HttpContext". 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_start 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.AppDomainAppVirtualPath'
>which needs no such request to determine the information needed.
>
>
>Thanks for your help anyway though
>
>--
>Rory
>
>

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!