Re: Accessing .NET DLL(s) from Classic ASP

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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
http://msdn.microsoft.com/subscriptions/support/default.aspx.

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:
msdnmg@xxxxxxxxxxxxxx

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

--------------------
From: "Shamshad Ali" <sww@xxxxxxxxxxxxxxxxx>
References: <Ov4DYWZiIHA.3940@xxxxxxxxxxxxxxxxxxxx>
<qZdDnSaiIHA.6844@xxxxxxxxxxxxxxxxxxxxxx>
<OQ92yybiIHA.944@xxxxxxxxxxxxxxxxxxxx>
<#XWkLtmiIHA.6264@xxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23XWkLtmiIHA.6264@xxxxxxxxxxxxxxxxxxxxxxxxx
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:
msdnmg@xxxxxxxxxxxxxx

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

--------------------
From: "Shamshad Ali" <sww@xxxxxxxxxxxxxxxxx>
References: <Ov4DYWZiIHA.3940@xxxxxxxxxxxxxxxxxxxx>
<qZdDnSaiIHA.6844@xxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:qZdDnSaiIHA.6844@xxxxxxxxxxxxxxxxxxxxxxxxx
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:
msdnmg@xxxxxxxxxxxxxx

==================================================
Get notification to my posts through email? Please refer to


http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights--------------------
From: "Shamshad Ali" <sww@xxxxxxxxxxxxxxxxx>
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.













.

Relevant Pages

  • Re: OT Loose Change 9-11
    ... They support the NIST findings. ... was known about the effects of a fire from such an aircraft, ... 1967 - steel structure failed due to ... ability of the strong axis to support load is significantly degraded. ...
    (rec.music.makers.percussion)
  • unexpected high load since 2.6.35
    ... machine running) or adds about 0.25 to 0.3 onto load - not more than before 2.6.35. ... Altough I have compiled in with 2.6.35 wireless lan support I have actually not the hardware. ... # Enable WiMAX to see the WiMAX drivers ...
    (Linux-Kernel)
  • Re: DRI seems to bee broken
    ... May 3 11:23:06 schlepptop kernel: The Regents of the University of California. ... Adds ~128k to driver. ... # To include support for VGA VESA video modes ... Load "dbe" ...
    (freebsd-current)
  • Re: can did Milton enable to all the patents? We cant display stewards unless Haron will seldom rec
    ... decisive condition won't load before I encounter it. ... Plenty of marked foreign clusters will yesterday strain the cleaners. ... when Talal acknowledges the inc brake in support of the ...
    (sci.crypt)
  • Re: Accessing .NET DLL(s) from Classic ASP
    ... As you are saying that problem occurs at high load, ... DLL to be failing? ... Microsoft MSDN Online Support Lead ... Is there any issue/conflict using COM interop in classic ASP? ...
    (microsoft.public.inetserver.asp.components)