Running the solution without problems in Visual studio 2017, or directly through .exe file in solution folder (inside release and debug folders). But when the ".exe" file is not in the solution folder, it will crash and stop working.
I found that these lines are causing the issue:
ScreenReaderAPIWrapper.ScreenReader sc = new ScreenReaderAPIWrapper.ScreenReader();
sc.SayString(textDisplay.Text.ToString());
The ScreenReaderAPIWrapper library for .net you're using is a wrapper around another library called UniversalSpeech. There are several solutions alike out there, like Davy Kager's Tolk or Chris Toth's AccessibleOutput. All of these libraries make use of native APIs provided by corresponding screen reader modules (jfwapi.dll, saapi32.dll, NvdaController32.dll and others).
For these libraries to work, you have to provide all of the needed DLLs along with your executable, otherwise you'll get those errors about the exe file that stopped working.
If you need to distribute your program, consider using installer tools like NSIS or InnoSetup to pack all needed files into one single installer.
Related
Hi I am trying to make my qt app run just copying the exe. With hours of static build I succeded it however; I discovered that there is a tool for mac named 'macdeployqt' doing all the process for you.
So I wondered if any equivalent tool or script exists for windows. It will get the exe extract dependencies, creates qt.conf file and put the dll's and exe into right paths.
What I mean here is not about creating setup package, just a folder containing all necesseray libraries etc.
We have a couple of dlls we like to install using an msi.
In our test environment, we are using regasm -codebase to register the dlls.
As I understand from googling, this is accompliched in an msi project by setting the register property to vsdraCOM.
The problem is that when we run the installer and checks the registry, the codebase path is set to the path the file were in when building the msi.
I'm going to expand on Hans' answer and that link info, and it may be more than a comment can hold.
That reg file will contain the path to the file and the link article recommends using [TARGETDIR], which is basically wrong if the file is not being installed to the application folder. The path to your file should be written as [#file-key] in the reg file that you import. In a VS setup project the file-key will be (just an example) something like _B049230C37DE4B6787C578DCEE30252A. Open your MSI file with Orca, go to the File Table and use the file key in the File column that corresponds to your file name.
That comes from here:
http://msdn.microsoft.com/en-us/library/aa368609%28v=vs.85%29.aspx
the 7th bullet point. It resolves to the file path wherever it is installed to.
The other thing that can be done is to let Visual Studio do its incorrect thing, then go to the Registry table with Orca, find the path and put that [#file key] in it such as [#_B049230C37DE4B6787C578DCEE30252A] and people sometimes do those kinds of updates with a post build script to update the MSI.
None of these are great, but they should work and get you out of using the GAC. VS setup projects really should be using that [#file key] syntax, and it's just a silly bug I assume.
Speaking as someone who's made a full time living writing installs for 18 years, my first suggestion would be to switch to Windows Installer XML. If you insist on using .VDPROJ, I would suggest reading: Redemption of Visual Studio Deployment Projects.
The concept is you use Windows Installer XML to create a merge module and then consume that merge module with .VDPROJ. In Wix, you use Heat to harvest the DLL. It will extract the COM / Regasm metadata and author it as Registry table entries. This provides a nice clean encapsulation using authoring best practices and avoids the need to do any post build hacking of the built MSI database.
For the last two years I have been using Java and NetBeans, where all I need to do to add a new third party library to my project is throw in the .jar file and NetBeans does the rest.
Recently I have switch to C++ and Visual Studio and I am having a really hard time getting a project to compile using OpenGL, GLUT and GLEW due to 'Missing reference' errors.
Some tutorials tell me I need to download the projects for GLUT/GLEW and run them (that didn't work), some tutorials tell me I need to add a .dll file to my Win32 folder, others say just put the header files in the same directory as your project and some say I need to install these libraries in to Visual Studio itself, not just to my project.
None of these approaches have worked thus far.
All I want is for this one project to use these libraries. This is throwing a major spanner in the works for me at the moment, any help would be appreciated.
Sorry, I don't have an easy answer for you. I've been using OpenGL on Windows for years, and it can be a pain.
MS doesn't even (really) support OpenGL, the headers that come with Windows are the old 1.x ones - and they have no plans on changing that (they want to you use DX).
So, I would start small.
First, get a basically empty Win32 console "Hello World" app running.
Then, just add one component, like Glut.
Then, do the same - keeping it compiling / linking - incrementally add other components.
Wherever they tell you to put headers, libraries, DLLs, etc, it needs to be reflected in your project file. So:
add the location of the header files to "C/C++->Additional Include Directories"
add the .lib files to the "Linker->Input->Additional Dependencies"
(it still won't find them so) add the location of the .lib files to "Linker->General->Additional Library Directories"
With all that in place it should compile and link, but may not run still because it can't find the DLLs (that go along with the .lib files).
The shortest path to getting running might just be to dump the DLLs in the Windows/System32 folder. But in the long run that can be problematic as other apps may overwrite it (or see you as overwriting theirs).
What I do with specific DLLs is just load them explicitly in my application so I know for sure what DLL I'm getting (I don't do much Windows-specific GL, but when I did, I had my own \OpenGL directory with the versions of .h files, libs and DLLs I wanted).
Good Luck!
Oh, LoadLibrary() will load a DLL, etc.
I have got an old project, C++, 64 bits compiled on VS2008. The project is built using some Python scripts (SCONS). I have got to compile it in VS2010.
All is working pretty fine except one small detail: in VS2008 all output goes to Debug\Win64 or Release\Win64, where scripts are looking for it, while in VS2010 it goes to Debug\x64 or Release\x64.
I know that there are PLATFORM/PLATFORMNAME macros being used by VS. Anything I did trying to change these values is mighty ignored by VS, or, if I am changing it manually in vcxproj files, VS refuses to compile at all.
For some company-related reasons scripts could not be changed. So for now I just added to a batch file that runs the script some xcopy commands to copy all the files from\x64 to \win64 before the script starts. It's kind of working, but I would like to know about a more elegant solution.
Thanks,
fLot
Another solution that might work is to create a file system junction so that \Win64 and \x64 becomes two different names to the same physical folder. You have to create a junction for each configuration instead of copying the files but once created it should stick between builds and ensure the two folders have the same content. See Wikipedia: http://en.wikipedia.org/wiki/NTFS_junction_point.
How to run the exe file to other system?
Using VB 6
I copied the exe file to other system, then run that exe file, it not working it showing error
“component comdlg32.ocx or one its dependencies not correctly registered a file is missing or invalid”`
Can any one help me how to avoid this error?
When deploying VB6 applications, you should create a Setup, this will manage the DLL's that the VB6 application depends on. Since it is not enough to just copy the .Exe and .Dll's. You also need to register them.
The creation of the setup is included in the VB6 environment.
You can read this http://support.microsoft.com/kb/830761 which is very comprehensive.
1: http://support.microsoft.com/kb/830761 for more information.
Or if you just want the redistributable files check this kb http://support.microsoft.com/kb/290887
Copy and register the comdlg32.ocx on other system. Link: Fix Missing Comdlg32.ocx Run time Error in Portable apps.
Create an installer for your program.
Unless you are deploying your program to really old versions of Windows (prior to XP), one nice alternative is to create an XCopy package using reg-free COM. This is fairly easy for most simple programs using Make My Manifest though it can be done by hand or using other tools if you invest in a little study.
Even then a formal installer package is usually desireable though, if nothing else to create Start Menu shortcuts and set up application workspace directories.
Keep in mind that even the PDWizard is difficult to use blindly. Packaging and deployment is a topic that requires some learning investment.
Outdated or missing comdlg32.ocx runtime library is causing this error. Here is a copy of comdlg32.ocx (~60 Kb Zip). Download the file to the Desktop and extract the comdlg32.ocx to your the Windows\System32 folder.
Note: If you already have a copy of comdlg32.ocx, backup the existing file to a different folder and delete it from System32 folder.
1. Download comdlg32.zip and save to Desktop.
2. Unzip the file using WinZip or any other utility.
3. Extract comdlg32.ocx to Windows\System32 folder.
4. Type the following command from Start, Run dialog:
regsvr32 %Systemroot%\System32\comdlg32.ocx
Typically a VB 6 app will consist of an .exe some .dll libraries and a config.ini file. The exe is the starting place and it consumes the dll's and config.ini and other resources to run => you have to have all parts in the same directory for the app to run typically called "packaging" an app. E.g. An installer simply ensures that all those files in a packaged app are placed on a users computer in an Windows application directory, and creates a shortcut launch icon so that a user can click the shortcut in the start bar and the app will run.
To "package" your app (put the dll's and exe in the same folder) you can use an Add-In called "Package and Deployment Wizard":
And here is a demo of using it: https://www.youtube.com/watch?v=XT7jaoAiKDo
You can either package and create an installer and package or just create a package:
Now if the Deployment Wizard doesnt show as an add-in on your VB6 Editor Installation, go to editor's program folder and find the tools Tools folder, i.e:
Then you should be able to find the Deployment Wizard there:
Open it to use it.