|Monte on Sep 2, 2010 at 6:11:13 AM (# 4)|
Seems like a pain in the rear, but this might work:
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 firstname.lastname@example.org 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)
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.