I have a 3rd party legacy app that requires a VB6 Active X EXE library interface. I am looking to update the VB6 Active X EXE library to a currently supported language. As the legacy host application is from a 3rd party I do not have the ability to change the host API to use an interface other than ActiveX EXE. Is there any currently supported Microsoft language i.e., x86 C++, C++/CLI, C# or VB.NET that can create the equivalent of an ActiveX EXE interface?
I suspect the answer is no but am looking for a definitive response saying so. That any legacy host application using ActiveX EXE library must be itself be modified to allow the use of supported languages and tools. Basically confirming that effectively ActiveX EXE is now an unsupported API interface.
I've already looked at this similar question and from it one could deduce that the answer is no but there is no definitive response. I've also looked at this Microsoft Tutorial and from what I can tell it talks about updating the host application which isn't an option in this case. The tutorial talks about switching to an ActiveX DLL but my understanding is that this would require a change to the 3rd party host application. Again that is not an option in my case. I need something that looks like an ActiveX EXE library to the host.
If you are sure that an ActiveX Exe is required, have you considered just using VB6 to create the that as a thin shim and then have it delegate all implementation to a .NET assembly? You probably would never need to recompile the Exe again, unless the 3rd party vendor is still expanding their interface.
If you post some more information about the VB6 Active X EXE library interface, I might be able to refine this solution with specific code samples. Presumably your Active X Exe must implement a provided interface?
Related
I have a VB.NET winforms application (4.0) that depends on a number of external 3rd party libraries/software (ie mapping, directx, etc).
Ideally I would like to run a computationally-intensive portion of the program on another machine without having the other libraries installed (due to licensing restraints).
Is it possible to have the VB .NET application ignore the 'Imports'/requirement for the other libraries? Can I error handle it?
You could split the functionality that requires 3rd party libraries in to a separate assembly that you load using reflection only when it is configured to do so. If all the access is done through interfaces defined on the main program then it will not require a direct reference to the "plugin" assembly.
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...
This question already has answers here:
How to write a browser plugin?
(4 answers)
Closed 9 years ago.
In my legacy web application I need to read user system registry from JS and do some other stuff. I cannot not use ActiveX for security reasons so I have written a plugin. My Plugin consists of a DLL file which is a COM component. This COM component exposes few functions which I call from Java Script code.
In IE I package my DLL in a CAB file and install it, say it's test.dll, in the following way:
<object classid="clsid:some class id here" codebase="test.cab" height="0" width="0" onError="testInstalled=false; return true;" id="testComp"></object>
The above HTML tag install the COM component as plugin in IE and Im able to access the exposed functions of the same from my JS code:
var testCompApp = document.testComp;
testCompApp.callSomeFunction();
It works fine in IE. I need the same functionality in other browsers(Chrome,Firefox, Safari)
Can you pls suggest how to develop plugins for other browsers using my DLL file?
Thanks,
I don't get it: First you say "I can't use ActiveX for security reasons", and then you do the same bad things that ActiveX does in all its dangerous glory: a CAB-packaged COM object running unrestricted native Win32.
How does doing that solve your security concerns with ActiveX?
Leaving aside for a minute the question of "security": if you are not doing "ActiveX" already, you're pretty close. I don't remember off the top of my head all the details of what goes into [the-IE-plug-in-architecture-that-shares-with-other-stuff-the-marketing-moniker-of] "ActiveX", but I think all you are missing to be called "ActiveX" is a few interfaces you must implement. I also suspect that by being shy of "ActiveX" you don't even get to sign your CAB with Authenticode, which would provide your users with a modicum of confidence (assuming you maintain proper controls and key management, and that your users trust you enough to allow your native code to run on their computers).
In any case, that DLL you wrote will only ever run in IE. There is no other browser that supports Win32 native COM objects (whether you choose to follow the ActiveX specification to the letter or not). If you want to do the same thing in other browsers, you are going to have to rewrite it with something else.
I think you have (at most) two options for doing what you want to do:
COM/ActiveX: Native Win32 code in a COM object. What you are doing now. This only works on IE and it's extremely dangerous for users, unless it's done in a controlled environment (e.g. if this is a commercial product to be distributed by an enterprise customer's IT department, or if you have an established presence and a reputation, like some large companies do).
Java:. This would run on all browsers assuming your users have the proper runtime installed and enabled. But it will only work for you if Java allows access to the information you seek via a sandbox-authorized method, because you can't call registry API's from the Java sandbox. The same goes for "the other stuff" you need the plug-in to do.
Ok, so you have a third option:
Reimplement the whole thing in something that is not tied to the browser: a native Windows executable; maybe in a downloadable installer or maybe a .NET program deployed via ClickOnce.
You are in a pickle: You are saying "I have security concerns with running ActiveX but I need to do something dangerous". Any piece of code downloadable and runnable by a web browser that is able to access the registry directly is - necessarily - a dangerous piece of code. Any conceivable technology that allows you to run such code from a browser will immediately elicit the very same security concerns that ActiveX elicits.
Indiscriminate access to the registry is out of the question from a modern browser sandboxed environment, so you either have to find a different source for the specific information you want, or you have to use ActiveX/COM running under IE.
Does anyone know if there exist a dll in windows (2003 server) which I can call to calculate a MD5/SHA1 hash for a string?
I've written a .dll in C# that do this but I'm not allowed to use this because of company regulations for our servers.
/Ausgar
If you do have a .NET 2.0 installed (which I think you do), then yes, there is one.
It's accessible via COM as System.Security.Cryptography.MD5CryptoServiceProvider and System.Security.Cryptography.HMACSHA1, respectively.
It's no use to implent it in C# as C# relies on .NET and .NET has implemented it for you already.
P.S. If there is no .NET on your system or you reluct at using .NET/COM for some reason, then there is sample using Microsoft Crypto API.
Have you tried openSSL?
(e.g. there are precompiled libeay32.dll and libssl32.dll files for windows, I'm not sure where the docs are that describe the DLL functions available in each of those, though)