 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / ASP / Components / March 2008Accessing .NET DLL(s) from Classic ASP
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. 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@microsoft.com. ================================================== 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@newsgroups.nospam> >Subject: Accessing .NET DLL(s) from Classic ASP [quoted text clipped - 39 lines] > >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. > Hi Shamshad, > [quoted text clipped - 97 lines] >> >>Shamshad Ali. 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@microsoft.com. 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. [quoted text clipped - 67 lines] >> ================================================== >> Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif >> ications. >> [quoted text clipped - 62 lines] >>> >>>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. > Thanks for your reply Shamshad, > [quoted text clipped - 186 lines] >>>> >>>>Shamshad Ali. 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@microsoft.com. 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. > [quoted text clipped - 115 lines] >>>> ================================================== >>>> Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif >>>> ications. >>>> [quoted text clipped - 75 lines] >>>>> >>>>>Shamshad Ali. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.