Previous Discussion	Next Discussion

Classic ASP Calling VB DLL that calls VC++ DLL Need some big favor here. Two scenarios, one works, the other doesn't. Scenario one: VB6 EXE using CreateObject("MY_VBDLL.MY_CLASS") which in turn uses Declare Function MY_C_FUNC Lib "MY_VCDLL.DLL"... blablabla. Works fine. Scenario two: ASP using CreateObject("MY_VBDLL.MY_CLASS") which in turn uses Declare Function MY_C_FUNC Lib "MY_VCDLL.DLL"... blablabla. Error '800a0035' File not found: MY_VCDLL.DLL Note that logic or structure in bolded text are exactly the same, yet in Scene 2 I get this error that does not make any sense. Reason that I think does not make sense: 1. Everything is there. Scene 1 proves that all code workds, and proves correct register of the VB DLL. ALL files involved (ASP, VB6 DLL, VC++ DLL) reside in the same directory. 2. I've used Dependency Walker to peek into the VC++ DLL and made sure the dependency files are there. (I am not a VC++ developer) 3. I've tried modifying the Lib part within the "Declare Function" statement, using either just the DLL file's name, with or without extension, plus the full absolute path to the VC++ DLL. Same results: Scene 1 works, not Scene 2. 4. I've tried setting the environments PATH and added the directory which contained all those files above. No success. 5. I've tried moving all the DLLs into system32, system32\inetsrv... No success. 6. I've googled and have failed to find even the simplest example as I have, nor have I have straight resolved answers to this issue. Environment(s) XP running IIS 5.1 Vista Home Premium running IIS 7.0 Server-side language: Classic ASP ASP / VB EXE Code <% Dim c, lng Set c = CreateObject("MY_VBDLL.MY_CLASS") lng = c.DoThis("00000000000000000001") '------------- Dies on this line Response.Write lng ' or MsgBox lng for the case of VB EXE Code %> MY_VBDLL.MY_CLASS Code Option Explicit Private Declare Function DoThat Lib "MY_VCDLL.DLL" Alias "_XXXXXXXXXX@4" (ByVal IN_szString As String) As Long Public Function DoThis(ByVal IN_szString As String) DoThis = DoThat(IN_szString) End Function MY_VCDLL.DLL (Unknown, not controlled by me, but Scene 1 confirms that it works) ASP Error MY_VBDLL Error '800a0035' File not found: MY_VCDLL.DLL /DEFAULT.ASP, Line 3 Note on Error As I have mentioned that I have also tried using a full absolute path referring to the VC++ DLL, and same error appears, showing me the full path of the DLL which EXISTS, yet stating "File not found", which is complete non-sense. Question and rant Has anybody got this to work? I mean calling a VC++ function from a VB6 Class from an ASP page? Like always, I find Microsoft's error messages completely unhelpful for debugging. Need some advise from someone who actually experienced this type of call and got it to work: What am I missing here? Started By Terry Young on Sep 1, 2010 at 6:45:14 PM This message has been edited.

10 Response(s) | Reply

Earlier Replies | Replies 4 to 10 of 10 | Later Replies Goto Page: 2 1

Monte on Sep 2, 2010 at 6:11:13 AM (# 4) Seems like a pain in the rear, but this might work: http://weblogs.asp.net/dneimke/archive/2004/01/31/65330.aspx I know it references a .NET assembly, but I'm sure the basic premise applies to a DLL. ChrisRickard on Sep 4, 2010 at 12:57:26 AM (# 5) I've done this many times before... It should work. My guess is the most likely culprit is permissions. Whenever Declare XXX is used to a c dll a Win32 LoadLibrary call is invoked which searches the exe directory (for w3wp or inetinfo) and the Path Environment variable. Since you tried both these in #4 and #5 I would venture to guess that LoadLibrary is failing because of *something* and the error is translated as a generic "File Not Found" because that's the most common error. The account on behalf of IIS might have privileges to load that dll. If you want to send me what you have to rickard234@gmail.com I can take a look and try to repro/fix it. Terry Young on Sep 21, 2010 at 7:06:55 AM (# 6) This message has been edited. Thanks for your attempts. Unfortunately, I'm still stuck in this deep pile of Microsoft dung. OK. For some unknown reason, putting the VC++ DLLs into system32 "seems" to work. But I'm seeing initial results or returned values that just doesn't add up (Long story, specific to what I have in hand, which I'll skip here) And I do not want them to be in system32. I just can't believe there are no alternatives. And, setting PATH won't work, that hasn't change. What shocks me is I can't Google this one up, not even examples or tutorials,... nothing. I never believed there would be such a day where I have spent days and nights trying to search this damn thing and end up with absolutely nothing. I just cannot believe I am the only one trying to do this without getting system32 involved. I damn myself for not being a C++ coder, but that's the current fact, otherwise, I just couldn't accept defeat. I can't believe there's not even one article or example out there that demonstrates this. ~sigh~ ~rant over~ ~for now~ brian on Sep 22, 2010 at 1:01:51 AM (# 7) Terry, Just saw this thread and have 2 things to say. 1. It is possible using VB. I needed a COM object for ASP years ago and while I loathe VB, it turned out to be the easiest way to do it and it was so incredibly easy. I tried with Delphi, C Builder and MFC/MS C++ and it didn't work so well or at all. Needless to say it is perfectly possible and it shouldn't be so bad. 2. There is a second option you can try and this depends on what you have on the server. You can use a .NET assembly from ASP via COM and it is so simple - just create a class library and then there's a specific tool for registering the DLL as a COM object - regasm.exe. Anything public in the COM object will be available. If you google 'register .net assembly for com' and look at the MSDN blog entry in the results you'll find some useful information too. I've used both options and 2 is definitely better IMHO as you have full access to the .NET framework and, more importantly, if you ever migrate away from ASP to .NET you will have a bunch of pre-made DLLs you can reuse. I've also found that some older COM objects no longer work on later servers - an Upload DLL I used by ASPSmart (no longer around I think) doesn't work which is a shame and was written in VB 6 I believe. This could also be part of your problem but should only affect you on Vista/W7/Server 2008 as the DLL works fine on Server 2003. If you need any help with this, I'm happy to assist. Terry Young on Sep 27, 2010 at 11:39:05 PM (# 8) The reason we need to use classic ASP is to deliberately avoid any dependency on .NET and stay away from it (long story which I will skip here) We have had a recent change, and that is modifying the C++ DLL code and have it as an ATL (ActiveX Type Library). There are just some issues with some particular dependencies in the existing DLLs, but our current approach now is to remove the VB DLL out of the equation. There are just so much assets already developed in C++ code, that removing the C++-written DLL out of the equation is out of the question (at least for now) Then again, from a learning perspective, I'm still surprised such information is absent on the web. brian on Sep 28, 2010 at 12:53:25 AM (# 9) I would understand the avoiding .NET if you're using PHP or something but since you're depending on ASP which, while not really dead, is kinda dead technology and the same goes with traditional VB (since the dev environment doesn't work correctly in vista or W7 and MS stopped supporting VS6 about 5 years ago, final apps work fine, C++ anyways but in our experience VS6 dies horribly) it seems puzzling to me why anyone would not bother with .NET yet use ASP. OK, ASP works but compared to .NET it is slow. However, doing it all in C++ would make more sense if it is all in C++. I could hazzard a guess at why there's a lack of information and that would be that, for the most part at least, VB programmers generally ended up using ASP since it was deemed a logincal step so there's very little in the way of information for how to interface with VBS from a C++ COM/ActiveX object. Personally all my ASP pages were written using JScript because it made more sense to me that client-side code and server-side code were written using the same language to minimise the learning curve. Terry Young on Jul 11, 2011 at 8:45:10 AM (# 10) This message has been edited. Many things happened since I last replied (jees, that's almost a year ago). Thanks to all that replied. I personally can put it to rest now, simply because it's out of my hands and I'm being dedicated on something else. JScript was out of the question because we needed to compile as much critical VB code into a DLL as much as possible. (i.e. closed source would be a better way to say it). The intention is to actually take advantage of the fact that traditional VB is discontinued, and hence there's definitely no new bugs possible to be introduced. .NET signals this risk of introducing new bugs that, once occurs, is out of our hands. We wanted zero-tolerance for errors, performance is secondary. We needed this more nearer to the metal, and more into our own hands as much as possible. And Classic ASP works almost out of the box on almost all IIS servers without additional installation. It sounds weird, I know, but it was a unique, uncommon case, and those were some of the reason behind it. Anyhow, it's off my desk now and I'm back in concentrating what I do best (and enjoy doing), i.e. web development. I'm glad that it's out of my hair now. Case unresolved, but I'm not obligated or assigned to care anymore, frankly.

Earlier Replies | Replies 4 to 10 of 10 | Later Replies Goto Page: 2 1

To respond to a discussion, you must first logon.

If you are not registered, please register yourself to become a member of the SiteExperts.community.