How do I access a COM component from an ASP.NET page. I added reference to my ASP.NET project.
The actual dll I got from the 3rd party is ePadIIu.dll but when I added it to the ASP.NET project it shows as ePadIIu.interop.
I want to access all the methods and properties in the component.
The sample I received from the 3rd party software uses vbscript to access all the methods.
How do I use those methods in the code behind from default.aspx.vb.
When you added the reference to the COM component from your ASP.NET project, Visual Studio ran it through tblimp (type library import utility) to generate an interop assembly for use with .NET. By convention, it named it ePadIIu.interop.dll.
If you view this reference in the Object Browser, you should be able to determine the namespace you will need to reference, as well as any of the classes, properties and methods exposed.
Your using statement at the top of your *.cs might look something like this:
using ePadIIu;
Caution - Slippery When Wet
VB COM components are notorious for being compiled using a Single Threaded Apartment (STA) - though not always the case (if I remember correctly). If ePadIIu happens to be a STA COM component you might experience:
Slower performance
Possible memory leak due to blocked finalizer (not trying to be all doom and gloom, just seems to happen more often than not)
References discussing the problem:
COM Interoperability in the .NET Framework
Running ASMX services on STA Threads
Developing High Performance ASP.NET Websites
ASP.NET Hang and OutOfMemoryException caused by STA Components
Good Luck!
Z
Related
I have an existing application that is closed-source and ships its own version of Mono 3.5. I want to change the behavior of the application; specifically, I want to swap out a built-in class with a new one.
Normally, one goes about this with Mono.Cecil. However, in my case the application assembly is loaded from a readonly volume which makes modifying the assembly itself very very tricky (it involves hardware hacks to produce a new volume). I can, however, get it to load an arbitrary DLL via an officially-supported mechanism, which I could in theory use to modify the assembly at runtime.
There are numerous resources for achieving runtime code injection / function hooking via the .NET Framework, but they all fail under Mono. Approaches I've seen include:
System.Reflection.Emit.MethodRental.SwapMethodBody - not implemented in Mono
This CodeProject sample - uses Microsoft internals
Microsoft Fakes - more Microsoft internals
This MSDN blog post - Even more Microsoft internals
See related questions:
Can Mono.Cecil modify code already loaded in the AppDomain?
Can I redirect .NET method calls to a new method at runtime?
Dynamically replace the contents of a C# method?
I am aware that this is a pretty terrible plan. However since I don't have the sourcecode and modifying the assembly on disk is even more terrible than doing some kind of dirty runtime hack, this is the best alternative I've generated so far.
I'm having to update one of our ancient Intranet applications that was written in Classic ASP and utilizes an in-house COM+ Service. I cannot find the source code to this object anywhere and it was not documented by the developer.
I can view the methods available in the Service through Start -> Administrative Tools -> Component Services but can't for the life of me figure out how to look inside the methods to see what they're doing.
Is there anyway to decompile these COM+ Services, or otherwise see what their methods do, or am I doomed to pure observation of the old application and try my best to mimic the behavior and data?
Note: I exported the service from the old server, installed in on my dev box, added the reference to a VS2010 project, and tried to discern these methods using the Object Explorer. Nothing...
COM services include type descriptions of what methods exist on the COM classes and their parameters so that automation controllers can figure out how to pass parameters to the COM methods.
Beyond that, though, there is nothing to indicate what the COM classes do internally other than the native x86 machine code itself. You can try using an x86 disassembler on the DLL, but unless you are already familiar with x86 machine code instructions, this won't be a lot of help.
Compiling source code down to native machine code throws away an enormous amount of information. Variable names, internal function names, none of that is needed for the CPU to execute instructions and perform the operations indicated by the original source code. It is virtually impossible for disassemblers to reconstitute these names that would be helpful clues as to what the code is intended to do. A disassembler can sometimes help figure out core logic, but it will require a lot of careful analysis and effort by a person to even scratch the surface. It's like trying to understand the forest by looking at individual blades of grass.
Is it possible to include a .net 3.5 framework DLL in classic asp?
You will need to expose this .NET assembly as a COM object. This could be done using the regasm.exe utility. For this the types that you need to use or the entire assembly must be decorated with the ComVisible attribute.
Then consume the COM object from classic ASP as you would with any normal COM object.
Yes, it's called creating a COM-Callable Wrapper.
Here is the MSDN Documentation
The link that pops up for the Code Project article in Google is, surprisingly, not the better one. You'll want to check out this one: Exposing .NET Components to COM It's the best. Complete step-by-step tutorial.
It's worth noting that in a former life I had to develop and support a .NET application which was exposed to some COM-based integrations - and simply slapping ComVisible on my classes was putting me in a world of hurt. Pay attention to the author's explanation of the Interface Types in that article... that article is a gem.
Excerpt:
Previously I was using AutoDual,
however Heath Stewart[^] pointed out
this was not the best method to use as
it can create version-related problems
in the long run. After reading a
little more I changed the code to use
ClassInterfaceType.None which forces
our class to gain access only through
our interface. This keeps everything
viable during changes to the class in
the future.
Like the topic says, can ASP Classic use registration free components? This is on Windows Server 2003. If so, how do I go about doing that?
If not, could anyone please provide some alternatives?
By Registration Free I assume you mean DLLs that are not registered as ActiveX components using regsvr32. If that's the case then no, not directly from ASP 3.0 though you could use it remotely via DCOM using CreateObject. The reason why is without registering it there is no ProgID to reference to find the ActiveX component.
By alternative, I guess you don't mean components that do require registration? 'Cause there are loads of those...
A less common way of using COM with ASP that is quite convenient is to use Windows Scripting Components (WSC). From 4GuysFromRolla:
One of the biggest disadvantages of
developing COM components using one of
these high-level languages is the
time-intensive process of altering an
existing COM component. For example,
say that you are developing a COM
component. You add some properties and
methods and start using it on your
site. Now, say that you wanted to add
a new method. After adding this method
you would have to recompile the COM
component, reregister it, and stop and
restart the Web server...
To solve for this annoyance, Microsoft
has created Windows Script Components,
which, as their name implies, are COM
components created with script! These
components can be developed with any
Windows scripting language (VBScript,
JScript, PerlScript, Python, etc.).
Since these components use script, you
can literally cut and paste your ASP
script into one of these scripted
components! Also, you can edit a
Windows Script Component's code and
the changes are automatically
reflected - no recompiling, no
restarting the Web server, and no
reregistering the component!
For more info, check out these links:
http://msdn.microsoft.com/en-us/library/07zhfkh8(VS.85).aspx
http://technet.microsoft.com/en-us/library/ee692823.aspx
https://web.archive.org/web/20210927201615/http://www.4guysfromrolla.com/webtech/050400-1.shtml
Writing a ASP.NET website, we have a lot of legacy components we need to rely on.
My view is that because we are MTA (Multi Threaded Apartment) in ASP.NET, if we use a STA component then the requests will queue. So even if we use a .NET component which is MTA, if IT relies on an old STA component, this will still queue. Am I right so far?
Anyway, my real question is - By examining a .DLL ONLY, can I find out which threading model it was built under?
Thanks
Duncan
ActiveX and COM are basically the same thing -- they must both be registered in order to be used. Threading models (as far as I know) only apply to COM objects, not .NET objects, so unless you're doing COM interop you shouldn't need to care about threading models.