Accessing .NET DLL(s) from Classic ASP

[Shamshad Ali]

Hi,

I have similar question that i saw yesterday (Calling .NET DLL from Classic
ASP), but we have achieved some good results and we can't go back but not
sure that approach is perfect or need more efforts or any better is
available?

here is some details:

We have production website running on Classic ASP (Windows Server 2003 E.Ed
+ IIS and SQL Server 2000 SP-4). we are tracking hits of students on their
courses and other stuff in database. This is done by COM wirtten in C# 2.0.
there is no error and run fine until there is much traffic on site. We faced
following error:

Server object error 'ASP 0177 : 80131509'
Server.CreateObject Failed

/includes/trk_SessionEndTime_Cookie.asp, line 32

I tried to find out any solution or details about this error on Microsoft
site but nothing found. the only solution is to re-start IIS. Our site is
providing credit to students and doing re-start is not solving our problem
and we lost online users credit for that period. The reason we wrote this
DLL was due to site performance issue with classic ASP code, so we used .NET
2.0 DLL. that produced better results in performance.

This is not at all, further we have to send some users/students information
to their respective colleges (they have provided us web services), calling
web service via ASP is done by creating another DLL written in 1.1, 2.0 and
3.5 version of .NET and all are tested on local system, that may update
users results online to their specific colleges/universities.

The is question is, is this a right way to do? (calling DLLs written in
different .NET version from classic ASP) is there any better solution
available? Right now we can't migration our whole classic ASP website to
..NET


Shamshad Ali.

[Steven Cheng]

Hi Shamshad,

As for calling .NET component (assembly) directly from classic ASP, I think
COM interop is the only approach. Also, if you want to call multiple .NET
components, I think you'd better make sure they're built-in upon the same
version (or at least of compatible versions). Because for a single process,
only one version of CLR runtime will be loaded(and those built-in framework
components). .NET 3.X relies on .NET frameworrk 2.0, therefore, I think
components built-in upon .NET 2.0 and .NET 3.X can work together as long as
the process has loaded the higher version. And the order how you load
multiple .net components into unmanaged process will also affect the
behavior, the version of the first .NET component you load(in unmanaged
process) will determine the CLR runtime version it will load for the entire
process.

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:
[email]msdnmg@microsoft.com[/email].

==================================================
Get notification to my posts through email? Please refer to
[url]http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif[/url]
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
[url]http://msdn.microsoft.com/subscriptions/support/default.aspx[/url].
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights--------------------

>From: "Shamshad Ali" <sww@newsgroups.nospam>
>Subject: Accessing .NET DLL(s) from Classic ASP
>Date: Wed, 19 Mar 2008 12:50:11 +0500
>
>Hi,
>
>I have similar question that i saw yesterday (Calling .NET DLL from

Classic

>ASP), but we have achieved some good results and we can't go back but not
>sure that approach is perfect or need more efforts or any better is
>available?
>
>here is some details:
>
>We have production website running on Classic ASP (Windows Server 2003

E.Ed

>+ IIS and SQL Server 2000 SP-4). we are tracking hits of students on their
>courses and other stuff in database. This is done by COM wirtten in C#

2.0.

>there is no error and run fine until there is much traffic on site. We

faced

>following error:
>
>Server object error 'ASP 0177 : 80131509'
>Server.CreateObject Failed
>
>/includes/trk_SessionEndTime_Cookie.asp, line 32
>
> I tried to find out any solution or details about this error on Microsoft
>site but nothing found. the only solution is to re-start IIS. Our site is
>providing credit to students and doing re-start is not solving our problem
>and we lost online users credit for that period. The reason we wrote this
>DLL was due to site performance issue with classic ASP code, so we used

..NET

>2.0 DLL. that produced better results in performance.
>
>This is not at all, further we have to send some users/students

information

>to their respective colleges (they have provided us web services), calling
>web service via ASP is done by creating another DLL written in 1.1, 2.0

and

>3.5 version of .NET and all are tested on local system, that may update
>users results online to their specific colleges/universities.
>
>The is question is, is this a right way to do? (calling DLLs written in
>different .NET version from classic ASP) is there any better solution
>available? Right now we can't migration our whole classic ASP website to
>.NET
>
>
>Shamshad Ali.
>
>
>
>

[Shamshad Ali]

Thanks for your reply. One thing I missed earlier was that we are also using
a VB6 version of component (dll) in our classic ASP website.



Also as i discussed that we have tested .NET 1.1, 2.0 and 3.5 COM interop
within ASP without any problem, but it fails sometime, with error i posted
earlier.



Is there any issue/conflict using COM interop in classic ASP? if yes, how it
can be resolved in such environment?



IIS (ASP.NET 2.0)

Classic ASP

1 - using vb6 COM

2 - using .NET 2.0 COM



3 - using .NET 2.0 COM (one another COM to perform some specific
tasks)

4 - using .NET 3.5 COM



From above hierarchy till point no. 2 is already implemented and working
fine until there is small No. of users hitting our website, and we face
error when there is large no of users hitting the site.



We need to further implement web service calls using .Net 2.0 and 3.5 DLLs
as mentioned in above step 3 and 4 and require help from you whether this
approach is correct or not?



Coz we are already facing ASP 0177 error as I mentioned earlier.





Thanks



Shamshad Ali.



""Steven Cheng"" <stcheng@online.microsoft.com> wrote in message
news:qZdDnSaiIHA.6844@TK2MSFTNGHUB02.phx.gbl...

> Hi Shamshad,
>
> As for calling .NET component (assembly) directly from classic ASP, I
> think
> COM interop is the only approach. Also, if you want to call multiple .NET
> components, I think you'd better make sure they're built-in upon the same
> version (or at least of compatible versions). Because for a single
> process,
> only one version of CLR runtime will be loaded(and those built-in
> framework
> components). .NET 3.X relies on .NET frameworrk 2.0, therefore, I think
> components built-in upon .NET 2.0 and .NET 3.X can work together as long
> as
> the process has loaded the higher version. And the order how you load
> multiple .net components into unmanaged process will also affect the
> behavior, the version of the first .NET component you load(in unmanaged
> process) will determine the CLR runtime version it will load for the
> entire
> process.
>
> 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:
> [email]msdnmg@microsoft.com[/email].
>
> ==================================================
> Get notification to my posts through email? Please refer to
> [url]http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif[/url]
> 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
> [url]http://msdn.microsoft.com/subscriptions/support/default.aspx[/url].
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no
> rights--------------------

>>From: "Shamshad Ali" <sww@newsgroups.nospam>
>>Subject: Accessing .NET DLL(s) from Classic ASP
>>Date: Wed, 19 Mar 2008 12:50:11 +0500
>>
>>Hi,
>>
>>I have similar question that i saw yesterday (Calling .NET DLL from

> Classic

>>ASP), but we have achieved some good results and we can't go back but not
>>sure that approach is perfect or need more efforts or any better is
>>available?
>>
>>here is some details:
>>
>>We have production website running on Classic ASP (Windows Server 2003

> E.Ed

>>+ IIS and SQL Server 2000 SP-4). we are tracking hits of students on their
>>courses and other stuff in database. This is done by COM wirtten in C#

> 2.0.

>>there is no error and run fine until there is much traffic on site. We

> faced

>>following error:
>>
>>Server object error 'ASP 0177 : 80131509'
>>Server.CreateObject Failed
>>
>>/includes/trk_SessionEndTime_Cookie.asp, line 32
>>
>> I tried to find out any solution or details about this error on Microsoft
>>site but nothing found. the only solution is to re-start IIS. Our site is
>>providing credit to students and doing re-start is not solving our problem
>>and we lost online users credit for that period. The reason we wrote this
>>DLL was due to site performance issue with classic ASP code, so we used

> NET

>>2.0 DLL. that produced better results in performance.
>>
>>This is not at all, further we have to send some users/students

> information

>>to their respective colleges (they have provided us web services), calling
>>web service via ASP is done by creating another DLL written in 1.1, 2.0

> and

>>3.5 version of .NET and all are tested on local system, that may update
>>users results online to their specific colleges/universities.
>>
>>The is question is, is this a right way to do? (calling DLLs written in
>>different .NET version from classic ASP) is there any better solution
>>available? Right now we can't migration our whole classic ASP website to
>>.NET
>>
>>
>>Shamshad Ali.
>>
>>
>>
>>

>

[Steven Cheng]

Thanks for your reply Shamshad,

From the error message, it is a general error, and since the problems
occurs on high workload condition, it is really difficult to determine the
problem from appearance. I think there is still something we can try to
isolate the problem. Since you've used multiple .NET components in the
application, you can try remove some of them and determine which one will
always raise this problem(wihtout other ones loaded) at high load
condition. I think the problem one is likely the one that is frequently
called in the application.

Best regards,

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:
[email]msdnmg@microsoft.com[/email].

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

--------------------

>From: "Shamshad Ali" <sww@newsgroups.nospam>
>References: <Ov4DYWZiIHA.3940@TK2MSFTNGP05.phx.gbl>

<qZdDnSaiIHA.6844@TK2MSFTNGHUB02.phx.gbl>

>Subject: Re: Accessing .NET DLL(s) from Classic ASP
>Date: Wed, 19 Mar 2008 17:22:27 +0500

>
>Thanks for your reply. One thing I missed earlier was that we are also

using

>a VB6 version of component (dll) in our classic ASP website.
>
>
>
>Also as i discussed that we have tested .NET 1.1, 2.0 and 3.5 COM interop
>within ASP without any problem, but it fails sometime, with error i posted
>earlier.
>
>
>
>Is there any issue/conflict using COM interop in classic ASP? if yes, how

it

>can be resolved in such environment?
>
>
>
>IIS (ASP.NET 2.0)
>
> Classic ASP
>
> 1 - using vb6 COM
>
> 2 - using .NET 2.0 COM
>
>
>
> 3 - using .NET 2.0 COM (one another COM to perform some specific
>tasks)
>
> 4 - using .NET 3.5 COM
>
>
>
>From above hierarchy till point no. 2 is already implemented and working
>fine until there is small No. of users hitting our website, and we face
>error when there is large no of users hitting the site.
>
>
>
>We need to further implement web service calls using .Net 2.0 and 3.5 DLLs
>as mentioned in above step 3 and 4 and require help from you whether this
>approach is correct or not?
>
>
>
>Coz we are already facing ASP 0177 error as I mentioned earlier.
>
>
>
>
>
>Thanks
>
>
>
>Shamshad Ali.
>
>
>
>""Steven Cheng"" <stcheng@online.microsoft.com> wrote in message
>news:qZdDnSaiIHA.6844@TK2MSFTNGHUB02.phx.gbl...

>> Hi Shamshad,
>>
>> As for calling .NET component (assembly) directly from classic ASP, I
>> think
>> COM interop is the only approach. Also, if you want to call multiple .NET
>> components, I think you'd better make sure they're built-in upon the same
>> version (or at least of compatible versions). Because for a single
>> process,
>> only one version of CLR runtime will be loaded(and those built-in
>> framework
>> components). .NET 3.X relies on .NET frameworrk 2.0, therefore, I think
>> components built-in upon .NET 2.0 and .NET 3.X can work together as long
>> as
>> the process has loaded the higher version. And the order how you load
>> multiple .net components into unmanaged process will also affect the
>> behavior, the version of the first .NET component you load(in unmanaged
>> process) will determine the CLR runtime version it will load for the
>> entire
>> process.
>>
>> 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:
>> [email]msdnmg@microsoft.com[/email].
>>
>> ==================================================
>> Get notification to my posts through email? Please refer to
>>

[url]http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif[/url]

>> 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
>> [url]http://msdn.microsoft.com/subscriptions/support/default.aspx[/url].
>> ==================================================
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights--------------------

>>>From: "Shamshad Ali" <sww@newsgroups.nospam>
>>>Subject: Accessing .NET DLL(s) from Classic ASP
>>>Date: Wed, 19 Mar 2008 12:50:11 +0500
>>>
>>>Hi,
>>>
>>>I have similar question that i saw yesterday (Calling .NET DLL from

>> Classic

>>>ASP), but we have achieved some good results and we can't go back but not
>>>sure that approach is perfect or need more efforts or any better is
>>>available?
>>>
>>>here is some details:
>>>
>>>We have production website running on Classic ASP (Windows Server 2003

>> E.Ed

>>>+ IIS and SQL Server 2000 SP-4). we are tracking hits of students on

their

>>>courses and other stuff in database. This is done by COM wirtten in C#

>> 2.0.

>>>there is no error and run fine until there is much traffic on site. We

>> faced

>>>following error:
>>>
>>>Server object error 'ASP 0177 : 80131509'
>>>Server.CreateObject Failed
>>>
>>>/includes/trk_SessionEndTime_Cookie.asp, line 32
>>>
>>> I tried to find out any solution or details about this error on

Microsoft

>>>site but nothing found. the only solution is to re-start IIS. Our site is
>>>providing credit to students and doing re-start is not solving our

problem

>>>and we lost online users credit for that period. The reason we wrote this
>>>DLL was due to site performance issue with classic ASP code, so we used

>> NET

>>>2.0 DLL. that produced better results in performance.
>>>
>>>This is not at all, further we have to send some users/students

>> information

>>>to their respective colleges (they have provided us web services),

calling

>>>web service via ASP is done by creating another DLL written in 1.1, 2.0

>> and

>>>3.5 version of .NET and all are tested on local system, that may update
>>>users results online to their specific colleges/universities.
>>>
>>>The is question is, is this a right way to do? (calling DLLs written in
>>>different .NET version from classic ASP) is there any better solution
>>>available? Right now we can't migration our whole classic ASP website to
>>>.NET
>>>
>>>
>>>Shamshad Ali.
>>>
>>>
>>>
>>>

>>

>
>
>

[Shamshad Ali]

Thanks, your comments are appreciated.

As you are saying that problem occurs at high load, that is true and i
already mentioned. I wanted to know its fix. Is this a normal behavior of
DLL to be failing? Ofcouse the DLL is doing some job and that lines of coz
may cause problem like reading connection string for database from registry,
updated database etc...

what should we do to solve such kind of problem and its all necessary to do.


""Steven Cheng"" <stcheng@online.microsoft.com> wrote in message
news:%23XWkLtmiIHA.6264@TK2MSFTNGHUB02.phx.gbl...

> Thanks for your reply Shamshad,
>
> From the error message, it is a general error, and since the problems
> occurs on high workload condition, it is really difficult to determine the
> problem from appearance. I think there is still something we can try to
> isolate the problem. Since you've used multiple .NET components in the
> application, you can try remove some of them and determine which one will
> always raise this problem(wihtout other ones loaded) at high load
> condition. I think the problem one is likely the one that is frequently
> called in the application.
>
> Best regards,
>
> 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:
> [email]msdnmg@microsoft.com[/email].
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> --------------------

>>From: "Shamshad Ali" <sww@newsgroups.nospam>
>>References: <Ov4DYWZiIHA.3940@TK2MSFTNGP05.phx.gbl>

> <qZdDnSaiIHA.6844@TK2MSFTNGHUB02.phx.gbl>

>>Subject: Re: Accessing .NET DLL(s) from Classic ASP
>>Date: Wed, 19 Mar 2008 17:22:27 +0500

>

>>
>>Thanks for your reply. One thing I missed earlier was that we are also

> using

>>a VB6 version of component (dll) in our classic ASP website.
>>
>>
>>
>>Also as i discussed that we have tested .NET 1.1, 2.0 and 3.5 COM interop
>>within ASP without any problem, but it fails sometime, with error i posted
>>earlier.
>>
>>
>>
>>Is there any issue/conflict using COM interop in classic ASP? if yes, how

> it

>>can be resolved in such environment?
>>
>>
>>
>>IIS (ASP.NET 2.0)
>>
>> Classic ASP
>>
>> 1 - using vb6 COM
>>
>> 2 - using .NET 2.0 COM
>>
>>
>>
>> 3 - using .NET 2.0 COM (one another COM to perform some specific
>>tasks)
>>
>> 4 - using .NET 3.5 COM
>>
>>
>>
>>From above hierarchy till point no. 2 is already implemented and working
>>fine until there is small No. of users hitting our website, and we face
>>error when there is large no of users hitting the site.
>>
>>
>>
>>We need to further implement web service calls using .Net 2.0 and 3.5 DLLs
>>as mentioned in above step 3 and 4 and require help from you whether this
>>approach is correct or not?
>>
>>
>>
>>Coz we are already facing ASP 0177 error as I mentioned earlier.
>>
>>
>>
>>
>>
>>Thanks
>>
>>
>>
>>Shamshad Ali.
>>
>>
>>
>>""Steven Cheng"" <stcheng@online.microsoft.com> wrote in message
>>news:qZdDnSaiIHA.6844@TK2MSFTNGHUB02.phx.gbl.. .

>>> Hi Shamshad,
>>>
>>> As for calling .NET component (assembly) directly from classic ASP, I
>>> think
>>> COM interop is the only approach. Also, if you want to call multiple
>>> .NET
>>> components, I think you'd better make sure they're built-in upon the
>>> same
>>> version (or at least of compatible versions). Because for a single
>>> process,
>>> only one version of CLR runtime will be loaded(and those built-in
>>> framework
>>> components). .NET 3.X relies on .NET frameworrk 2.0, therefore, I think
>>> components built-in upon .NET 2.0 and .NET 3.X can work together as long
>>> as
>>> the process has loaded the higher version. And the order how you load
>>> multiple .net components into unmanaged process will also affect the
>>> behavior, the version of the first .NET component you load(in unmanaged
>>> process) will determine the CLR runtime version it will load for the
>>> entire
>>> process.
>>>
>>> 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:
>>> [email]msdnmg@microsoft.com[/email].
>>>
>>> ==================================================
>>> Get notification to my posts through email? Please refer to
>>>

> [url]http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif[/url]

>>> 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
>>> [url]http://msdn.microsoft.com/subscriptions/support/default.aspx[/url].
>>> ==================================================
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights--------------------
>>>>From: "Shamshad Ali" <sww@newsgroups.nospam>
>>>>Subject: Accessing .NET DLL(s) from Classic ASP
>>>>Date: Wed, 19 Mar 2008 12:50:11 +0500
>>>>
>>>>Hi,
>>>>
>>>>I have similar question that i saw yesterday (Calling .NET DLL from
>>> Classic
>>>>ASP), but we have achieved some good results and we can't go back but
>>>>not
>>>>sure that approach is perfect or need more efforts or any better is
>>>>available?
>>>>
>>>>here is some details:
>>>>
>>>>We have production website running on Classic ASP (Windows Server 2003
>>> E.Ed
>>>>+ IIS and SQL Server 2000 SP-4). we are tracking hits of students on

> their

>>>>courses and other stuff in database. This is done by COM wirtten in C#
>>> 2.0.
>>>>there is no error and run fine until there is much traffic on site. We
>>> faced
>>>>following error:
>>>>
>>>>Server object error 'ASP 0177 : 80131509'
>>>>Server.CreateObject Failed
>>>>
>>>>/includes/trk_SessionEndTime_Cookie.asp, line 32
>>>>
>>>> I tried to find out any solution or details about this error on

> Microsoft

>>>>site but nothing found. the only solution is to re-start IIS. Our site
>>>>is
>>>>providing credit to students and doing re-start is not solving our

> problem

>>>>and we lost online users credit for that period. The reason we wrote
>>>>this
>>>>DLL was due to site performance issue with classic ASP code, so we used
>>> NET
>>>>2.0 DLL. that produced better results in performance.
>>>>
>>>>This is not at all, further we have to send some users/students
>>> information
>>>>to their respective colleges (they have provided us web services),

> calling

>>>>web service via ASP is done by creating another DLL written in 1.1, 2.0
>>> and
>>>>3.5 version of .NET and all are tested on local system, that may update
>>>>users results online to their specific colleges/universities.
>>>>
>>>>The is question is, is this a right way to do? (calling DLLs written in
>>>>different .NET version from classic ASP) is there any better solution
>>>>available? Right now we can't migration our whole classic ASP website to
>>>>.NET
>>>>
>>>>
>>>>Shamshad Ali.
>>>>
>>>>
>>>>
>>>>
>>>

>>
>>
>>

>

[Steven Cheng]

Thanks for your reply Shamshad,

For this kind of issue, the normal approach is performing debugging to the
process which launch the .NET component(also load CLR runtime). You can
inspect the code execution in debugging and check process status. Also,
you can try using performance counter or some other profiling tools to
check the memory statistics of the process to see whether there is any
particular unexpected behavior during high load condition. If you're not
quite familar with .NET COM interop debugging, I suggest you contact
product support service since some support professional there can help
provide further assistance such as debugging or static dump analysis.

Microsoft Customer Support Services (CSS) at
[url]http://msdn.microsoft.com/subscriptions/support/default.aspx[/url].

Best regards,

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:
[email]msdnmg@microsoft.com[/email].

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

--------------------

>From: "Shamshad Ali" <sww@newsgroups.nospam>
>References: <Ov4DYWZiIHA.3940@TK2MSFTNGP05.phx.gbl>

<qZdDnSaiIHA.6844@TK2MSFTNGHUB02.phx.gbl>
<OQ92yybiIHA.944@TK2MSFTNGP05.phx.gbl>
<#XWkLtmiIHA.6264@TK2MSFTNGHUB02.phx.gbl>

>Subject: Re: Accessing .NET DLL(s) from Classic ASP
>Date: Thu, 20 Mar 2008 15:24:38 +0500

>
>Thanks, your comments are appreciated.
>
>As you are saying that problem occurs at high load, that is true and i
>already mentioned. I wanted to know its fix. Is this a normal behavior of
>DLL to be failing? Ofcouse the DLL is doing some job and that lines of coz
>may cause problem like reading connection string for database from

registry,

>updated database etc...
>
>what should we do to solve such kind of problem and its all necessary to

do.

>
>
>""Steven Cheng"" <stcheng@online.microsoft.com> wrote in message
>news:%23XWkLtmiIHA.6264@TK2MSFTNGHUB02.phx.gbl. ..

>> Thanks for your reply Shamshad,
>>
>> From the error message, it is a general error, and since the problems
>> occurs on high workload condition, it is really difficult to determine

the

>> problem from appearance. I think there is still something we can try to
>> isolate the problem. Since you've used multiple .NET components in the
>> application, you can try remove some of them and determine which one will
>> always raise this problem(wihtout other ones loaded) at high load
>> condition. I think the problem one is likely the one that is frequently
>> called in the application.
>>
>> Best regards,
>>
>> 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:
>> [email]msdnmg@microsoft.com[/email].
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> --------------------

>>>From: "Shamshad Ali" <sww@newsgroups.nospam>
>>>References: <Ov4DYWZiIHA.3940@TK2MSFTNGP05.phx.gbl>

>> <qZdDnSaiIHA.6844@TK2MSFTNGHUB02.phx.gbl>

>>>Subject: Re: Accessing .NET DLL(s) from Classic ASP
>>>Date: Wed, 19 Mar 2008 17:22:27 +0500

>>

>>>
>>>Thanks for your reply. One thing I missed earlier was that we are also

>> using

>>>a VB6 version of component (dll) in our classic ASP website.
>>>
>>>
>>>
>>>Also as i discussed that we have tested .NET 1.1, 2.0 and 3.5 COM interop
>>>within ASP without any problem, but it fails sometime, with error i

posted

>>>earlier.
>>>
>>>
>>>
>>>Is there any issue/conflict using COM interop in classic ASP? if yes, how

>> it

>>>can be resolved in such environment?
>>>
>>>
>>>
>>>IIS (ASP.NET 2.0)
>>>
>>> Classic ASP
>>>
>>> 1 - using vb6 COM
>>>
>>> 2 - using .NET 2.0 COM
>>>
>>>
>>>
>>> 3 - using .NET 2.0 COM (one another COM to perform some specific
>>>tasks)
>>>
>>> 4 - using .NET 3.5 COM
>>>
>>>
>>>
>>>From above hierarchy till point no. 2 is already implemented and working
>>>fine until there is small No. of users hitting our website, and we face
>>>error when there is large no of users hitting the site.
>>>
>>>
>>>
>>>We need to further implement web service calls using .Net 2.0 and 3.5

DLLs

>>>as mentioned in above step 3 and 4 and require help from you whether this
>>>approach is correct or not?
>>>
>>>
>>>
>>>Coz we are already facing ASP 0177 error as I mentioned earlier.
>>>
>>>
>>>
>>>
>>>
>>>Thanks
>>>
>>>
>>>
>>>Shamshad Ali.
>>>
>>>
>>>
>>>""Steven Cheng"" <stcheng@online.microsoft.com> wrote in message
>>>news:qZdDnSaiIHA.6844@TK2MSFTNGHUB02.phx.gbl. ..
>>>> Hi Shamshad,
>>>>
>>>> As for calling .NET component (assembly) directly from classic ASP, I
>>>> think
>>>> COM interop is the only approach. Also, if you want to call multiple
>>>> .NET
>>>> components, I think you'd better make sure they're built-in upon the
>>>> same
>>>> version (or at least of compatible versions). Because for a single
>>>> process,
>>>> only one version of CLR runtime will be loaded(and those built-in
>>>> framework
>>>> components). .NET 3.X relies on .NET frameworrk 2.0, therefore, I think
>>>> components built-in upon .NET 2.0 and .NET 3.X can work together as

long

>>>> as
>>>> the process has loaded the higher version. And the order how you load
>>>> multiple .net components into unmanaged process will also affect the
>>>> behavior, the version of the first .NET component you load(in unmanaged
>>>> process) will determine the CLR runtime version it will load for the
>>>> entire
>>>> process.
>>>>
>>>> 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:
>>>> [email]msdnmg@microsoft.com[/email].
>>>>
>>>> ==================================================
>>>> Get notification to my posts through email? Please refer to
>>>>

>>

[url]http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif[/url]

>>>> 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
>>>> [url]http://msdn.microsoft.com/subscriptions/support/default.aspx[/url].
>>>> ==================================================
>>>> This posting is provided "AS IS" with no warranties, and confers no
>>>> rights--------------------
>>>>>From: "Shamshad Ali" <sww@newsgroups.nospam>
>>>>>Subject: Accessing .NET DLL(s) from Classic ASP
>>>>>Date: Wed, 19 Mar 2008 12:50:11 +0500
>>>>>
>>>>>Hi,
>>>>>
>>>>>I have similar question that i saw yesterday (Calling .NET DLL from
>>>> Classic
>>>>>ASP), but we have achieved some good results and we can't go back but
>>>>>not
>>>>>sure that approach is perfect or need more efforts or any better is
>>>>>available?
>>>>>
>>>>>here is some details:
>>>>>
>>>>>We have production website running on Classic ASP (Windows Server 2003
>>>> E.Ed
>>>>>+ IIS and SQL Server 2000 SP-4). we are tracking hits of students on

>> their

>>>>>courses and other stuff in database. This is done by COM wirtten in C#
>>>> 2.0.
>>>>>there is no error and run fine until there is much traffic on site. We
>>>> faced
>>>>>following error:
>>>>>
>>>>>Server object error 'ASP 0177 : 80131509'
>>>>>Server.CreateObject Failed
>>>>>
>>>>>/includes/trk_SessionEndTime_Cookie.asp, line 32
>>>>>
>>>>> I tried to find out any solution or details about this error on

>> Microsoft

>>>>>site but nothing found. the only solution is to re-start IIS. Our site
>>>>>is
>>>>>providing credit to students and doing re-start is not solving our

>> problem

>>>>>and we lost online users credit for that period. The reason we wrote
>>>>>this
>>>>>DLL was due to site performance issue with classic ASP code, so we used
>>>> NET
>>>>>2.0 DLL. that produced better results in performance.
>>>>>
>>>>>This is not at all, further we have to send some users/students
>>>> information
>>>>>to their respective colleges (they have provided us web services),

>> calling

>>>>>web service via ASP is done by creating another DLL written in 1.1, 2.0
>>>> and
>>>>>3.5 version of .NET and all are tested on local system, that may update
>>>>>users results online to their specific colleges/universities.
>>>>>
>>>>>The is question is, is this a right way to do? (calling DLLs written in
>>>>>different .NET version from classic ASP) is there any better solution
>>>>>available? Right now we can't migration our whole classic ASP website

to

>>>>>.NET
>>>>>
>>>>>
>>>>>Shamshad Ali.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>

>>

>
>
>