I have an old site that I was tasked with fixing after it broke. We are getting the following error:
ActiveX component can't create object for aBRR.Generato`r
The code on that line is:
set taMaker = createObject("aBRR.Generator")
I found the DLL aBRR.dll on an old machine. I believe it needs to go in:
e$\components\COM+\theAppName\
To install it in the COM+ folder do I just drop it in there? Is there anything else?
Do I just add the IUSR with what permissions to the DLL?
I think that was done but it's still giving the error.
If it's a classic COM DLL, you simply need to register it with regsvr32.
However, if the library depends on COM+, you need to place it inside a COM+ application. That way, any call to createObject() gets intercepted by the COM+ catalog manager, which ensures that that the object receives additional services.
See this link for further details.
Related
I have an ASP.NET web site targeting Framework 4.6.2 where I attempt to use a GRPC service from my controller. When I attempt to create the Channel, I get an exception:
"Error loading native library \"C:\\Users\\sstainba\\repos\\location-management-service\\src\\LocationManagement.Web\\bin\\grpc_csharp_ext.x86.dll\""}
My project already has a reference to the GRPC, GRPC.Core, GRPC.Auth and GRPC.Tools packages. And, in fact, the assembly DOES exist at that exact location. I am at a loss as to why it won't load. What other things can I try other than adding the reference?
Figure out the problem... Permissions on the bin folder. I temporarily set permissions to give everyone full control and it worked.
Whelp, I avoided it as long as possible, but the time has finally come to make some changes to some ancient VB6 code. I'm a recent college grad so I was hoping to stay away from this code that is almost as old as I am.
The DLL is compiled in a local installation of VB6 and deployed via Component Services. That component is then called by VBScript in a Classic ASP application running on a windows 2003 Server.
I've tried just about everything to debug this code using the VB6 debugger, but I can't get it to work. I've compiled the DLL to the same location that Component Services has it deployed to (a random folder on a non-system drive), and set binary compatibility to that same DLL. Each class file has instancing set to MultiUse and MTSTransactionMode set to '1 - NoTransactions.' The component works fine until I attach the debugger, then I get 'ActiveX component can't create object' when trying to instantiate the object. If I detach the debugger, it works again.
I noticed that in Component Services when I attach the debugger, the DLL location changes to C:\Program Files\Microsoft Visual Studio\VB98\VB6DEBUG.DLL, which I assume is just VB6 intercepting calls to the component. When I detach the debugger, it changes back. I should also note that the component is configured to use a specific user identity separate from my logged-in user account, however everyone has been granted access to the component via a user role. The component activation type is also 'Server Application,' however setting it to 'Library Activate' doesn't seem to make a difference.
I've also tried using the VC++6 IDE, and VS2010, but had no luck. I was able to debug the dllhost.exe in VS2010 and was able to hit some breakpoints, but the symbols weren't loaded properly. I tried compiling the DLL with debugging symbols and loading those to the VS2010 environment via the Debug settings menu, however that didn't resolve the issue.
I also didn't find the component services JIT Debugger to be very useful. I'd much prefer to just be able to debug in VB6.
What amazes me most is that this code is thousands of lines and has been maintained without the use of any debugger whatsoever. My young, spoiled self isn't ready to accept that this code can't be debugged.
Got some strange problem.
I'm developing some complicated Web Services network that uses some VB6 .dll. In my previous post I got some problems with the dll but we've solved them.
So, the new problem is:
When I debug my service (those which uses VB6 dll) on development server from visual studio - everything works fine, the problem starts when I publish my service on IIS (I tried my local IIS). After that, when I call .dll method (as I understand I need to call it by reference - and that's what the compiler tells me) I got an exception:
"System.Runtime.InteropServices.COMException (0x800A000D): Type mismatch at ..."
Actually is happens here in the third line:
Object s = (Object)OrderId;
Object s1 = (Object)lines.Length;
proxy.OrderRead(ref s, ref s1);
OrderId and Legth are integers.
As I understant this is exception that comes from the .dll from vb6 :/
What the problem may be? Why it runs when debugging but fails on IIS?
When debugging in vb6,the IDE will register the dll for you. After publishing, have you may ahve to register your vb6 dll on the server. Open a command prompt and change to the location of the dll and run regsvr32 myvb6.dll.
Also, check these settings.
http://support.microsoft.com/kb/281630
I have C++ project that compiles as DLL Assembly in .NET 3.5 SP1
Project is used for Image rendering processing by using WPF (it loads 2 images from local folder, applies one image on another and saves the output file in the same folder).
I want to use that that project as a reference in ASP.NET project to the rendering on the website.
So I created simple Web Project in ASP.NET C# that uses C++ project as a Reference.
Everything works great in ASP.NET Web Development Server (built-in Web server in VS2008).
But once I publish this project to IIS on the same Machine or use IIS for debug instead of built-in Web server Image rendering it's not working anymore. I'm not getting any exceptions or error messages, it just output image is not processes as it supposed to be.
If anyone know what could cause that I would really appreciate your insight!
Do you have access to the Event Logs? You should check there for any errors. You should try to throw an exception from a C#-only code path and make sure that everything is OK and regular exceptions are being thrown. Is the C++ compiled to managed code, or is native code? You might find that ASP.NET does not have the appropriate code access security permissions and needs to be registered in the GAC of the server to accessed from C#.
You should also check whether the DLL is thread-safe. This has caused issues for other users in ASP.NET/IIS.
I just tried to copy my entire web application to a new instance of Visual Studio 2008 on another (virtual) machine.
It builds just fine, but when I try to run the applicaton I just get the message "The specified module could not be found".
Does anyone have an idea how I can find out which module this message refers to? Because there are quite a lot, and as far as I can see they're all installed.
I would suggest you delete all the temporary ASP.Net files for your project and then do a rebuild. This will ensure all the new code is recompilled and no old references remain.
Sometime simply building the solution doesn't work and you need to rebuild instead to force it to either show you the real error or get the references correct.
If your project uses COM and an interop assembly, you'll be able to build (because the assembly is there), but raise a runtime exception if the COM server is not registered on the new machine.