I made an application for an automated invoice management system for my company. I am using the tessnet2 library for OCR. The whole application works properly on my development machine but as soon as I put the code on the target machine, wihout the development framework, it gives an error of references not found in the .DoOCR method.
I read that you had the same problem and I hope you can help me with it.
I have put the language files in the same directory as the application itself, but its not helping me.
Any help or suggestions will be highly appreciated.
Thanks
Regards
Vin
Look in the VS folder (under Program Files - you'll need to look in sub-folders) for a program called "Depends". This looks for dependencies from EXE and DLL files. Run it with the DLL as a command-line parameter, and that should list what files are needed by that DLL. Then see if they are all present on the destination system.
Related
I am currently developing a program that uses the Ghost Script DLL, by importing it as so:
[DllImport("gsdll32.dll", EntryPoint = "gsapi_init_with_args")]
Now, when I set the project in my solution that uses this directly (located in the directory...\source\repos\uo_test_viewer\omr_scanner\omrmarkengine-master) as the startup project, everything works fine. However, when I change my startup project to a project located in ...\source\repos\uo_test_viewer\UOTestViewer, I get the following error:
The gsdll32.dll wasn't found in the default search path or is not in correct version
(doesn't expose required methods). Please download at least the version 8.64 from the original website.
The only thing that is being changed is that when I set the project that makes this work as the startup project, I am running it directly -- where as with the project that doesn't work, I am creating an object of the form that uses the Ghost Script implementation. Does anybody know what the issue is?
I believe that I have provided all the necessary information, but please let me know if anything more is required. Thank you in advance for your answers!
DllImport looks first in the current working directory, then in the search path (the $PATH) environment variable).
When you start your application in the folder which contains the Ghostscript DLL, then the Windows API call DllImport looks in the current working directory and finds the Ghostscript DLL, so it loads it.
When you start in a directory which does not contain the Ghostscript DLL, then DllImport looks in the Current Working Directory, and does not find the DLL. It then searches the search path, which presumably does not find a Ghostscript DLL, so you get an error.
You either need to be sure the current working directory has a copy of the Ghostscritp DLL, or the DLL is on the search path, or you need to supply a fully qualified path to the Ghostscript DLL in the first argument to DllImport.
In case you are considering distributing this application, please read the AGPL license to ensure that you comply with the terms for using Ghostscript.
I have an .exe file and it is working properly. It connects to a SQL Server 2012 database. I need to know the authentication to the database. Is there any way to do this? Can I get the connection string from .exe file some way?
If your .net application is not obfuscated (protected against decompilation) you can get it's c# source by decompiling it with a tool like Resharper from JetBrains (contains assembly explorer tool) or free tool called ILSpy http://ilspy.net/.
I'd just add up that if it is not a tool written by you or your company, decompiling it might be a violation of a license agreement of this application.
If it is a fully standalone .exe, there are a couple of options:
Various configuration files that include the connection details may be compressed / merged into the executable, and can be extracted by various means.
The connection details are hard coded into the C# code, which can then be decompiled.
For decompilation, try dotPeek or ILSpy. For simple extraction, you can try 7zip.
As suggested you can try to decompile your executable (assembly) using Telerik JustDecompile (it is free).
Just drag and drop your file into the application, it might ask you for some dependencies. Skip them if they do not seem related to your application and you will be able to see the decompiled code.
I have a question which will probably be quite vague.
I'm developing a Windows Forms application in C# that can read and write games to an Access database. Every game has an attribute that links to an Image in the resource folder.
While debugging I was able to just read and write my screenshots to the following path:
"..\\..\\Resources\\Screenshots\\";
I tried publishing my application earlier today to test if it would still work and if not, to locate the path where the Resource folder would be when published.
So far I have the feeling that the resources just get burned into the exe file or one of the other files it generates.
Is it in any way possible to have a real folder in the published version of an application from which I can keep reading and writing my images like I did while debugging?
Thanks in advance.
Yes your screenshots will be compiled into the assembly as resources when publising.
As for the real folder, you can absolutely do that. Make sure you give your app the right path to that folder.
I made a WPF program which uses SQLite. And by using Visual Studio 2012, it generates both Debug and Release version exe file. When I go to Debug or Release directory and run my exe file, e.g. MultiStart.exe, it can run normally.
But if I copy the MultiStart.exe to my Desktop and try to run it, it failed.
By several tests, I found that I also need to copy files MultiStart.exe.config and System.Data.SQLite.dll to my Desktop. And then it can run now.
But why? Do we have better solution so that I can make it run without addition files?
Thanks!
Why my WPF program cannot run without Visual Studio?
The question title is not really accurate since it's not really related Visual Studio. MultiStart.exe is dependent on configuration (MultiStart.exe.config) as well as other assemblies (System.Data.SQLite.dll). Without these dependencies the application cannot run (because that is how .NET works).
WPF doesn't necessarily need a config file to run so the question is what is in your config file that the application needs. It might be possible to move this configuration information into the code (e.g. connection string) and remove the app.config but then the values will be hard coded in the application.
In terms of dependent assemblies, instead of deploying them it is possible to embed them as resources and then use the AppDomain.AssemblyResolve Event to read the assembly from a resource (see Embedding assemblies inside another assembly for an example).
Another approach instead of embedding assemblies as resources is to merge them into one assembly. ILMerge is a popular choice for merging assemblies but I read that it can have issues with WPF assemblies (not sure if that applies to you). See Merging dlls into a single .exe with wpf for some other ideas for merging assemblies with WPF.
Note that setting PATH variables does not work because .NET does not use the PATH for resolving assemblies -- see How the Runtime Locates Assemblies for the details.
Another, option instead of copying the MultiStart.exe to the desktop is to use a shortcut on the desktop that links to the appropriate directory. Perhaps that is a simpler solution
You can also use ILMerge to merge all dependencies into single .exe file to simplify distributiuon of your application.
More detaiils on ILMerge can be found here: ILMerge on CodeProject
Example of usage: ilmerge /target:winexe /out:YourDestinationApp.exe
YourCurrentProgram.exe System.Data.SQLite.dll
Better solution that i used to do with my windows form apps is, Copy the entire folder, which contains supporting files. place it where you want. then create a shortcut of your .exe on your desktop. That always worked for me.
Because you are missing some dependency. You can open your config file and set the dependency...but I wouldn't recommend you to change config file manually.
You can also copy the dependent dll in system32 folder. ..but its only a trick because exe first search dlls in current folder than system 32 folder.
Because you're missing things from your PATH. Visual Studio is probably set to copy DLLs to the target directory on build.
You're almost certainly pulling in external libraries. Some of these are part of .NET, while others are packaged in libraries in specific folders. When you start your exe, it looks in your PATH and the current folder for everything (which includes all DLLs Visual Studio copied).
When you moved the exe to the desktop, suddenly it had no idea where those DLLs are. You haven't specifically added them to your PATH, and they are no longer in the current folder. This is why copying those DLLs to your desktop magically made them work.
Unless you stop use SQLite, there is not a way for you to not need that DLL (there are lots of ways to package/reference it though).
I have a program written in C# that consumes a dll written in C++. I have the source for that but changing that is out of scope. There are two files of the type .pak and .jrn that get saved in the application. However the location of these files are configurable. If I choose to save it in a local location (somewhere on the hard drive of the machine running my C# code) it works just fine. However, when I try to configure the system to store the files in a remote machine, I get Assertion Failure error in C++.
This is really urgent. Any help will be greatly appreciated.
Thanks in advance,
I notice that you are configuring pakDir, but not jrnDir. So my guess is that jrnDir points to an invalid file path on the remote machine.