I use modi to do OCR.
Then I want to install the same program on my webserver. Obviously you can't install microsoft 2003 on hostgator hosting.
The problem is, of course, the program need to refer to modi.dll.
I saw several files here:
Interop.MODI.dll (what is this file anyway a wrapper)?
MDIVWCTL.DLL this seems to be the real .dll
In my program if I tried to add reference to mdivwctl.dll I got this error:
A reference to 'D:\business\shared\dropbox\Dropbox\badgers\dotNet\Thumbnailer\WebApplication1\MDIVWCTL.DLL' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
My programmer can add that but only in his computer.
Basically I want the dll to function by itself without registering, etc.
How to achieve that? How do I upload the program to windows shared hosting using asp?
I have a Desktop based application that is using MODI for OCR. At the time of writing the application, 4 months ago, I did some good amount of research into this area. I gave up after a while and just installed the free Sharepoint 2007 which includes MDIVWCTL.DLL. It does not seem likely that you can surpass the requirements of the assembly, it might have references to other components.
Related
I have made a small text based game using VB.NET in a Windows Forms application but it seems that people are a bit hesitent when it comes to downloading exe files. What would an easy way to have it work as a web application without having to rewrite the entire code?
There isn't an "easy" way to turn it into a web application. You can take all of your logic and put it into libraries (Class Library), but you'll need to write new front-end code for both the desktop and web.
If you are wanting the web to accept user input and such without constant reloading, you'll also need to make a web service to talk to using jQuery or the like.
For what it's worth, if anyone is hesitant to download an EXE, then they don't need it. I used to publish installations for VB6 applications on my website years ago, and I had downloads and referrals from all over the place, including educational institutions.
Also, if you are direct linking to an EXE, consider packaging it up in a ZIP along with a readme file.
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.
I'm having a massive problem trying to write a file into the c:\windows\system32 directory. The code works fine on 32 bit machines, however does not work on 64 bit machines.
My user account is an administrator on the machine, and even right clicking and choosing to run the app as administrator does not solve the issue.
When writing the file, no exception is thrown, but the file is not written.
I have read various posts regarding adding an app.manifest file containing the requestedExecutionLevel node to my solution, but as yet am unable to get this to work. I have a feeling this may be because I'm using vb.net rather than c#.net
Has anybody encountered this issue before? I'd be delighted if somebody could provide an example VS2010 VB.Net project with a correctly configured app.manifest file as I'm a little unsure whether my attempts at setting this up are correct.
(also, this is not a malicious app I am writing, I'm working on a version control app for our team and need to be able to interface with IIS files held in c:\windows\system32\inetsrv\config).
Thanks
David
Maybe the file is written under UAC Virtualization and located under C:\Users\Username\AppData\Local\VirtualStore\Windows\System32
Windows Blog - Tips on what is going on behind the scenes.
TechNet - Look under Data Redirection
Under Local Sercurity Policies there is the following option which controls UAC Virtualization.
I work for a service provider and have custom VBscripts on all our supported machines that report back the machines Windows and Office keys. We found that since Office 2010 the method to return keys hasn't worked. From Googling I have found many scripts for Office 2010 but none of them seem to work. What I am looking for is a script that gets the Product Name and Product Key for Office 2010 and puts them into a variable (or two).
I have looked everywhere and googled till my fingers are bleeding but none of the ones I have found have worked. They either return nothing or the wrong key on multiple machines.
From your post it sounds like the scripts you downloaded works on some machines, but not on others, is that correct? If so, I'd check if this might be due to 32bit vs 64bit since there are some differences in registry access. If this is the case you might be able to use the scripts you've found, but just adjust them to look in different location depending on OS.
Otherwise, if you'd be able to use an external executable, then there are plenty of tools on the internet to do this, this one says that they have a command line interface (I've not tried it), that you might be able to automate from your script.
Otherwise I'd suggest downloading Process Monitor and have that running logging any writes to the registry while you install and register a copy of Office 2010 on the various versions of Windows that you support, this should give you the registry location, and then you could hopefully find the decryption algorithm somewhere.
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.