Sicos1977 / TesseractOCR

A .net library to work with Google's Tesseract
161 stars 20 forks source link

The DLL's Tesseract53.dll and leptonica-1.83.0.dll are NOT compiled with Visual Studio 2022 Installer Project #52

Closed PhillD2024 closed 7 months ago

PhillD2024 commented 7 months ago

Hi,

In the description for this repository, it states that "The DLL's Tesseract53.dll (and exe) and leptonica-1.83.0.dll are compiled with Visual Studio 2022" However, I have discovered a problem.

While the DLL's Tesseract53.dll (and exe) and leptonica-1.83.0.dll do get compiled by visual studio when debugging and running a solution from within Visual Studio, the files are not bundled/included with the project is installed on an end-users PC using a Visual Studio Setup/Installer project.

When a project is run within visual studio, the DLL's Tesseract53.dll (and exe) and leptonica-1.83.0.dll are copied from the solution package folder to the bin folder where the project is running however, as part of the setup project build process, the files are not copied into the necessary folder. I can MANUALLY add to the setup/installer project however, because the packages folder and files contain a version name included in the folder and file names, if the version every gets updated, the file paths would become invalid and the installer would no longer compile.

Do you have a solution or workaround for this problem? Having to manually keep track of dll's for our installer would be extremely undesirable.

Thank you

Sicos1977 commented 7 months ago

Uh no, I think you have to make your own build script for this. The reason for the version numbers in the dll names is to prevent that a wrong DLL gets used when there are also older versions on someones server or pc

PhillD2024 commented 7 months ago

I would love some suggestions on how to accomplish this. I've been looking into creating a build script for the past 24 hours but the language and syntax is very different from vb.net. Part of the problem is, I need to dynamically detect the Tesseract folder name inside the packages folder inside the solution and then copy the x86 and x64 folders to the Application Folder target within the Setup Project. Do you have any suggestions.?

Sicos1977 commented 7 months ago

I don't think I can help you with that. I also used the internet to figure out how to do it in a nuget package.

Sicos1977 commented 7 months ago

I just asked ChatGPT and this is what it came up with :-)

You Can you tell me how I can make a build script that manually copies a dll from a visual studio project to an setup/installer project?

ChatGPT Certainly! To manually copy a DLL from a Visual Studio project to a setup/installer project, you can use a build script or a post-build event. Below, I'll outline two approaches: one using a post-build event in Visual Studio and another using a separate build script.

Approach 1: Post-build Event Open your Visual Studio Project:

Open the project for which you want to copy the DLL. Open Project Properties:

Right-click on the project in Solution Explorer and select "Properties." Navigate to Build Events:

In the project properties, go to the "Build Events" tab. Enter Post-build Command:

In the "Post-build event command line" box, enter a command to copy the DLL. For example:

bash Copy code copy "$(TargetPath)" "$(SolutionDir)InstallerProject\YourDestinationFolder" This command uses copy to copy the DLL from the target directory to the specified destination folder.

Save and Build:

Save your changes and build your project. The DLL should be copied to the specified destination after each build. Approach 2: Build Script (Batch File) Create a Batch File:

Create a new text file with a .bat extension, e.g., CopyDLL.bat. Write the Copy Command:

Inside the batch file, write the command to copy the DLL. For example:

bash Copy code @echo off copy "Path\To\Your\Project\bin\Debug\YourProject.dll" "Path\To\Your\InstallerProject\YourDestinationFolder" Adjust the paths according to your project structure.

Run the Batch File:

Save the batch file and run it manually or integrate it into your build process. Integrate into Visual Studio (Optional):

If you want to run the batch file automatically after each build, you can add it to the post-build event in Visual Studio by following the steps in Approach 1. These approaches should help you copy the DLL from your Visual Studio project to your setup/installer project. Choose the one that best fits your workflow and preferences.

PhillD2024 commented 7 months ago

Thank you for your suggestion. I will see if I can make this work by accepting a dynamic folder name/path.

Sicos1977 commented 7 months ago

You can ask me a lot about C# programming but making installers and build script is not a thing I do often so my experience on that is very little

PhillD2024 commented 7 months ago

I don't tend to build installers very often either. Once they are created, we just use the rebuild functionality and forget about them. That's why I don't want to manually/statically define the dll's because I know we would forget to update it after we update a NuGet package etc.

jsmithx commented 7 months ago

I don't know why this has been more complicated that it needed to be, but I figured how to fix this situation when trying to "Publish" the project with ClickOnce using Windows 11:

In Visual Studio 2022, look at the "Solution Explorer" and find the folders [Project Name]\x64 and [Project Name]\x86. Apparently, these "x64" and "x86" folders are virtual folders referenced from [Project Name]\Dependencies\Packages\TesseractOCR\Build Files\TesseractOCR.Targets

`<?xml version="1.0" encoding="utf-8"?>

x86\leptonica-1.83.1.dll PreserveNewest x86\tesseract53.dll PreserveNewest x64\leptonica-1.83.1.dll PreserveNewest x64\tesseract53.dll PreserveNewest ` In "Solution Explorer," right-click on [Project Name], and create a "New Folder" named "x64" and "x86." These folders are now no longer virtual. Then right-click on the folder "x64" and select "Open Folder in File Explorer" and you will find that there are no files named "leptonica-1.83.1.dll" or "tesseract53.dll". Then right-click both of those DLL files in "Solution Explorer" in the "x64" and "x86" folders, and select "Copy." Then "Paste" those files to the "x64" folder in File Explorer that was just opened. Then make sure to change "Build Action" to "Content" and leave "Copy to Output Directory" to "Do not copy" for those DLL files in "Solution Explorer." Then repeat the same process for "x86." Then right-click on [Project Name] and click "Publish" which opens up ClickOnceProfile. Then navigate to "More actions" and click "Edit". Then go to "Settings" and click "Application Files" and make sure you see "x64\leptonica-1.83.1.dll", "x64\tesseract53.dll", "x86\leptonica-1.83.1.dll", and "x86\tesseract53.dll". Then make sure that "Publish Status" says "Include" but not "Include (auto)". Then build the installer and install the Project application. Once the installed application is running, open up Windows "Task Manager" via [Ctrl+Alt+Delete] and find [Project Name]. Then right-click on [Project Name] and click "Open file location." Then you should see both folders "x64" and "x86" in your application folder with the corresponding DLL files that were previously missing. Note: I received some helpful tips from here: https://devrecipeshb.blogspot.com/2018/02/adding-files-and-folders-to-click-once.html
PhillD2024 commented 7 months ago

@jsmithx. The problem with taking this approach is, if you (or another team member) ever run the update on the NuGet Terseract package (and the dll's subsequently change), you now have a broken project/non working code. You won't even realize it until the update is published because it's just too easy to update the package(s) in your project and then forget the need to test the actual functionality.

I was able to find a way to fully automate the bundling of the DLL's into my installer project so that if a NuGet package is ever updated, the process still works. I don't know if the approach I took would work in in the ClickOnce client though.