I'm in need of distributing several old COM applications that are to be installed on locked down computers. I'm trying to get these applications to launch without having to be registered in the registry via regsvr32 or in the case of an EXE component via the /regserver switch. I can control and locally copy all the required dependencies in this scenario.
I know this is possible, however, I'm having a real tough time piecing together the different pieces or finding coherent information on how to set this up.
Any help or pointers would be greatly appreciated.
Microsoft has a good tutorial on Registration Free COM.
There are two basic parts to getting registration free COM working.
First, you need to convert the COM dlls to an assebmly: Just the COM dll's, and create a manifest describing them, and give it a name. Bundle this assembly in the same folder as your application.
Next, you need to tell your application to use the assembly you just created. When COM tries to create a new object, it will first look in any assemblies registered in the default activation context, before looking in the registry.
Registrationless COM can be tricky to set up but the overall process is not very complex. I wrote up my process along with some tools that help with debugging problems in a blog post here:
http://www.west-wind.com/weblog/posts/2011/Oct/09/An-easy-way-to-create-Side-by-Side-registrationless-COM-Manifests-with-Visual-Studio
FWIW, registrationless COM doesn't work with DCOM EXE servers unfortunately - only DLL servers are supported.
Related
I am trying to create a user interface where I can control and receive information from an electronic actuator through a CAN bus.
I am a relatively new programmer with experience in MATLAB and VBA, and have no experience with communicating to external devices.
I downloaded a couple of dll files look like they would be helpful, but when I try to reference either of them I get this error message: "A reference to (name and location of DLL) could not be added. Please make sure that the file is accessible and that it is a valid assembly or COM component."
I have tried relocating the file to the project directory and under C:\Windows\System32. I've looked over the documentation for the DLLs, spoken with customer support for the companies that supplied them, and talked to our IT department but still haven't found any hints.
Any idea on how to get these working? Or is there any built in funtionality in Visual Basic 2010 Express that would allow me to communicate with the CAN bus instead.
My website application uses C# COM+ components running under a particular identity to access SQL Server, invoked from classic ASP.
There's also a web service that utilises a \bin DLL in the website application that contains a method to insert some data into the SQL Server database (let's call it MyApp.Database.dll).
From the website front end, I want to be able to provide authenticated users with this same functionality.
I don't want to duplicate code in MyApp.Database.dll within the COM+ component for obvious reasons.
My idea was to utilise the COM+ component from ASP to invoke the MyApp.Database.dll method to access the SQL database using the application credential since the ASP is running as the user and has no access to SQL Server.
Problem I've seem to run into is that although I can reference MyApp.Database.dll in my COM+ component project (under 'References' and 'using MyApp.Database.dll'), when it comes to actually running or debugging the COM+ component, when it tries to invoke the method from MyApp.Database.dll, it tells me 'Could not load files or assembly 'MyApp.Database, Version=3.3.3.11658, Culture=neutral, PublicKeyToken=.....' or one of its dependencies.'
The MyApp.Database.dll is not registered in GAC (trying to avoid this, it's also used by other applications as well), and hasn't had its codebase registered in the registry using regasm (I tried this and still didn't work). The version is correct, and I've placed MyApp.Database.dll in the application folder of the COM+ component.
Am I missing something or is it not possible to do this?
Thanks in advance for your help.
This is a common mistaken expectation: just because your .NET COM DLL was found in some given folder (the folder set by the /codebase argument or RegAsm) -- it doesn't mean .NET will look on that folder for anything else.
Generally speaking, it won't. Loading a .NET assemblies via COM interop is a special case. For everything else, assemblies will be loaded in the AppDomain based on the Fusion binding policy for the process - which has nothing to do with where your .NET COM DLL is. The process is actually (depending on your version of IIS) either dllhost.exe, iisexpress.exe or w3wp.exe.
You have a few options.
First, the obvious solution is putting MyApp.Database.dll in the GAC, since .NET always looks there. Sometimes that's the right choice (I've done that and it works). You have declined to do so and you have your reasons; that's Ok.
Second, I believe you can change the binding policy with a web.config file. See here: http://msdn.microsoft.com/en-us/library/823z9h8w(v=vs.110).aspx. Yes, your ASP Classic project can have a web.config. Obviously it has no effect on your ASP Classic scripts, but (depending on the version of IIS), .NET and/or IIS itself use it for configuration. I'm afraid that I can't help you much with this alternative because I've never had to try it before, but you're welcome to explore that option - let me know how it goes.
Third option - my personal choice: You said this DLL is already a web service, right? Just call the functionality with a web service call from your COM DLL. That doesn't require mucking with magic folders, GAC and binding policies. Much cleaner. The only mild complication is tracking in configuration where your web service is located - and I bet you already do that for your database connection anyway, so it shouldn't be hard to add.
If you are curious to know where .NET is looking for the DLL, read up on these guys:
How to enable assembly bind failure logging (Fusion) in .NET
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx
http://www.hanselman.com/blog/MoreOnAssemblyBindingStrongNamingTheGACPublisherPolicyAndDynamicallyLoadedAssemblies.aspx
Good luck, and please let us know what worked for you.
I have a "proof of concept" piece of work that crosses over into some unfamiliar territory. I have some experience on J2EE technologies. I'm tasked with connecting an EFTPOS machine to an web application. I am planning to use applet to interact with dll. dll will be running on the client side.
I need to interact with one dll from web application. Please provide me any guidance on this, as I am new to it. I tried interacting with dll from standalone java program, but not able to connect from web application. Any sample codes will be very helpful for me.
Yes that is perfectly possible with an applet. I "connected" an electronice signing device before and it was working very well. Depening on what kind of .dll we are talking about here you need to do the following things:
1.) Create a java access layer / interface for your dll, so that you are able to call the dll functions from java. Depending what kind of dll we are talking about there are several possibilities. The base technology is JNI which is however quite cumbersome to use but luckily there are much more convienient ways out there:
use JNA (if it is a C dll)
use Jacob (if it is a COM component)
use bridj (if it is a c++ dll. You may try swig but haven't used that, so can't tell)
2.) Put your dll inside a jar file and distribute it alongside your applet. How this works is quite nicely described in the jacob project which provides an example for that. You can find it in the source package under jacob-1.17_src.zip\jacob-1.17\samples\com\jacob\samples\applet The example describes the JNLP way to access a native library which will work above java version 1.6.0_10. If you have to use a lower version for some reason, it is also possible but is slightly more tricky...
3.) One more side note: Since the latest available java version (1.7.0_51 or 1.6.0_71) due to security, some rules have been added or tightened for java applets. Now you have to sign your applet with an official certificate and set the right attributes/properties in the manifest, jnlp files. But this has been discussed in great detail here so just search for it. I would probably use a slightly older version for development and if that is working, figuring out how to make it work in the latest java version...
4.) Regarding the interaction part there are also several possibilities. Your Java Applet can call jscript methods from the website it is running in (or also the other way around) or the applet directly communicates with your server. You have all possibilities on that front...
Looking at registration-free COM it is still unclear to me whether you can just take any existing, completely unaware COM component(*) and use it in a registration-free way by adding the correct manifest files.
Is this supposed to work in all cases.
What's with the apartment stuff (comInterfaceProxyStub) they are talking about?
(*) : (e.g. an ocx file or another in-process COM server DLL that is supposed to be used with regsvr32
Yes, no problem. The manifest simply provides the configuration that COM normally reads from the registry. Thus the term "registry-free". The typical problem with writing one for a 3rd party server is that you don't know the guids. Observe the changes that Regsvr32.exe makes to the registry with SysInternals' ProcMon or ask the vendor for help.
The "apartment stuff" is just additional config, the keys written to HKLM\Software\Classes\Interface. Required by COM when an interface call needs to be marshaled from one thread or process or machine to another. COM needs help to figure out how to serialize the method arguments into an interop communication packet. It doesn't know what the function looks like so needs the help of a proxy and a stub. A helper DLL registered with the ProxyStubClsId32 key provides the proxy and stub implementation. Auto-generated from the IDL or provided by the standard Automation marshaller that uses the type library to discover the function declaration. The comInterfaceProxyStub element provides the manifest version of that registration.
I am now facing a very strange issue. One of our product installers registers numerous COM DLLs during the installation of the product. Subsequently, this creates COM+ applications under Administrative tools --> Component Services --> COM+ applications.
One of the COM+ applications is created during the install to run under NETWORK SERVICE account. However, at times , it has been observed that the identity of this COM+ application is set to interactive. I am using a msi based installer. The windows installer log files clearly state that the COM+ application was set to run under NETWORK SERVICE account.
We use our own custom code to create this COM+ application. This issue is not reproducible at will. However, it does happen on some environments.
Either of the two things is happening:
There is a bug in the installer code which is causing this
There is something outside of install which is causing this.
I need to determine the root cause of this behavior. Upon carrying out some research on the web, I have come across the following two articles:
http://support.microsoft.com/kb/926098
http://blogs.msdn.com/b/distributedservices/archive/2009/06/19/tracing-in-com-and-complus.aspx
These two articles talk about how diagnostic logging can be enabled for COM+ components. However, I am not really sure if they will be of use to me , as i need to accurately pin point as to what is changing the identity of the COM+ component to INTERACTIVE USER.
The other major disadvantage with this logging is that the .etl files output are in a binary format and can only be decoded by contacting Microsoft with the help of so-called .tmf files.
Questions:
What are the other options available to me to diagnose this issue?
Can I format the .etl files without the help of Microsoft?
Is there any mechanism in place just like process monitor, which could monitor all the events within COM+?
I don't know if this will help or not but http://www.fileinfo.com/extension/etl says you can use tracerpt.exe (located in your system32/syswow64 directory) to produce reports from the etl files.