Is it hard to compile software so that it is a single .exe file? I have been publishing the program in the traditional manner and the resultant program consists of a setup file and a couple data files. Ideally I would like to have a lone exe that runs program without having to install.
In general, if you're using Visual Basic, you'll always need to, at a minimum, guarantee the target computer has the proper .NET Framework installed.
If that's the case, then you can just deploy your .exe from your Console or WIndows Application project, and it will work, provided you don't use any references or types outside of the standard framework types. If you have any assemblies you use, or require any extra data to exist, then an installer is the correct way to go.
In general, building an installer makes sure that all of the dependencies are in place, which is why it's the "traditional" manner of publishing. Without that, you (or somebody) has to verify the dependencies before running your program manually.
Related
I am new into software developing. I have found this GitHub repository which I plan to modify. Let's just say I fork this repository and modify it. How would I then be able to export it from there. By export it I meant turn all of those files into one windows executable file. Thanks.
In general, building a project is a project-specific task unless the project is written in a language (such as Rust) that has a built-in build tool. If you're unclear about the steps to build a project, you should look in the documentation or the wiki for steps about how to do so, and failing that open an issue asking them to document the procedure for building the project.
Just looking at the project, it does not seem obvious that it should produce a binary executable of any sort since it's written mostly in JavaScript.
Usually you use a compiler to turn source code into machine code (exe files).
As bk2204 mentioned, this project is based on Javascript and Node.js.
Javascript is interpreted instead of compiled, so another program (Node.js) reads the source code and executes it directly every time instead of first compiling it into an exe file. That other program itself may be in an exe file.
The project you have linked is a fork of this project, and that one seems to have a Windows launcher/installer exe file (that probably installs or contains Node.js, but I haven't checked).
That installer is available here in both exe and source code form. So you could modify the launcher and rebuild it, but the main app is not in the launcher, instead it's in all the JS files. You may be able to edit the JS files and just use the same launcher without modifying it. There may be a packaging step required after editing the JS files, to package them into a form that the launcher expects. You would need to run this build step after every time you modify the JS files, to provide the new code to the launcher.
You would have to explore the project's structure and build process to find out the exact steps.
If you're very new that may be exceedingly difficult.
You may want to practice by learning Javascript and Node.js.
You could after that try Java which is compiled, and possibly more powerful than Javascript. Just for fun.
Maybe you could do 30 of these practice projects, then you'll have a chance of being able to modify this project successfully.
I'm using JavaFX to build a GUI for the software I'm working on. I call it software but it's actually a series of automated steps, compiled into a standalone .exe file. I have about 6 of these executable files, which is why I'm building a GUI to act as the front-end, main menu of sorts.
Ideally I'd have the entire package (GUI, exes) combined into one file Jar which I'd then send to clients, or wrap it with JSmooth or Launch4j.
Questions:
1) Is it possible to combine all 6 .exe files into a package along with the GUI.? So if I click button 2 on the GUI, it runs .exe #2, etc. Which concepts should I understand?
2) Is this best practice, or is there a better method? I'm new to Java which is why I haven't built the entire software with it, just the GUI.
3) I've read that its best to extract the exe from the parent jar (or exe?) into a temp file on the users PC. Is this correct? Even for multiple wrapped exes?
Any answer is helpful. I'm trying to avoid building something only to realize I can't do what I needed. Thanks
It would be much easier to write an answer if you were a bit more specific regarding what those 6 .exe files do. Nevertheless, a few things can be pointed out. Answers are in the same order as questions.
Yes, you can package exe files into a jar. No, you can't run exe from within the jar. A common solution is to unpack exe either temporarily (while your application is active) or permanently, and then tell OS to execute it.
I'm not entirely sure what "best practice" refers to in your question. Ideally, your logic (back-end) code would be written in Java and all your 6 exe files would be a part of a single Java application. I respect that you are new to Java, so in your particular case having a front-end to your executables is perfectly fine. However, do keep in mind that your solution is Windows specific, unless you plan to provide other OS executables too.
Yes, you will need to extract the exe files. It doesn't really matter what parent executable you use (exe or jar). For the sake of simplicity, I'd go with the jar, because you won't need to use any 3rd party software to build such a jar.
Just to sum up, considering your situation, package your JavaFX app and the .exe files into a single executable jar. When the user needs to execute an ".exe", extract that ".exe" into the same directory where JavaFX is running from. When the app exits, delete all ".exe" files from that directory
I've got a certain project that I build and distribute to users. I have two build configurations, Debug and Release. Debug, obviously, is for my use in debugging, but there's an additional wrinkle: the Debug configuration uses a special debugging memory manager, with a dependency on an external DLL.
There's been a few times when I've accidentally built and distributed an installer package with the Debug configuration, and it's then failed to run once installed because the users don't have the special DLL. I'd like to be able to keep that from happening in the future.
I know I can get the dependencies in a program by running Dependency Walker, but I'm looking for a way to do it programatically. Specifically, I have a way to run scripts while creating the installer, and I want something I can put in the installer script to check the program and see if it has a dependency on this DLL, and if so, cause the installer-creation process to fail with an error. I know how to create a simple CLI program that would take two filenames as parameters, and could run a DependsOn function and create output based on the result of it, but I don't know what to put in the DependsOn function. Does anyone know how I'd go about writing it?
You can read the PE imports table to find out what DLLs are required at load time. This is what Dependency Walker does, and also the dumpbin tool included with the Microsoft Platform SDK (which is installed by Visual Studio and also available as a separate download). Some of the debughelp APIs provide access to information from the PE header, but why not invoke the dumpbin tool and inspect its output? Since it's text-based non-interactive it should be pretty straightforward to integrate into your installer build process. Dependency Walker also has a capability to run in non-interactive mode with text output.
If you do need to retrieve the information without the help of any other tool, the ImageDirectoryEntryToDataEx function is a good place to start. Also, here's a question that shows how to do it manually (but do use ImageHlp instead, which knows about all the various variants of the PE format):
Printing out the names of implicitly linked dll's from .idata section in a portable executable
I'm maintaining a VB6 application with many COM components (DLLs and OCXs). In order to streamline development and deployment I'd like to use reg-free com. The problem with development is that the application runs within the VB6.EXE instance. How can I trick VB6 to use my (unregistered) components? It is very important for me to not have to go through registering/unregistering components when switching between branches. Generating a .manifest file for VB6 is not out of the question but is there some other, more optimal way, to specify a .manifest file when launching VB6.EXE?
Note: The Activation Context API doesn't seem to help, even if used from within the development environment.
Solutions I've thought:
A utility application that activates a context from a manifest and launches VB6 as a child process (doesn't work; processes don't inherit activation context)
Injecting context activation into the VB6 process at startup (too complicated; must hack the executable to do this)
Hosting VB6 in my own process after activating the right context (can't even find out if this is possible)
Using a VB6 Add-In or other utility that runs within VB6 to activate a context (tried that but it doesn't seem to work)
Update Jan. 16
As suggested by wqw, I did some testing with a VB.exe.manifest. The VB6.exe.manifest worked, with some caveats:
The SxS dll specified in the manifest would not appear in the references window on projects that didn't actually reference the component
On projects that did reference the component it would be shown to reside in the directory according to the following order:
The pathname recorded in the project file (if the file was still present)
A pathname as if it resided in the same folder as the project (vbp)
If the file was not in any of these folders, the project would not compile (just running the code causes an internal compile in VB6) with the message "Can't find project or library".
Obviously, VB6 actualy scans the registry to find COM components and verifies, during compilation, that they exist where they say they exist. I'm not sure what that might mean if I actually want to use VB6.exe.manifest to redirect COM component instantiation. Perhaps having dummy component files at some predefined location might trick VB6 into believing that everything is as it should be, although an entirely different set of components got loaded for use.
Further update:
I did a test on that last assumption and it proved to be false. The component has to actually be there in order for the project to compile. It must even properly load (no dummy, zero-length files accepted!). Now I'm not even sure if the manifest works. That's a more time-consuming test (requires a component with two versions that produce different results, one with the project, and one for the manifest).
Our approach to this problem was to write a build assist program that registered and unregistered components, run the VB6 compiler, and would even rewrite project files with updated GUIDs when interfaces changed. You would hand it a VBG project group and it would do the rest.
I suppose we could also have added a mode that unregistered components when you switched branches.
Are you following the practice of using "compatibility" binaries? You shouldn't use the binary at your build location for compatibility references - you should commit a separate copy to version control and configure your project to consider that the "compatible" version - only change this file when you break interfaces.
I've got a project that depends on a particular version of MSVCR80.dll (the MS Visual C Runtime) and I'm running into problems where, depending on the particular system configuration, my app doesn't always get the right version of that file. It's been a bit of a crap shoot as to what path it takes to find a file with that name, and it's not always right...
Is there a way, when creating a Deployment Project in VS2005, to ensure that my app will always use the runtime that I provided?? When I add the runtime file to the project, it asks about creating a merge module...but not really sure what that does. And regardless of creating one, the issue remains.
Martin Richter wrote an article about that on CodeProject:
Create projects easily with private MFC, ATL and CRT assemblies
This solution does not rely on your MSI packages but on the application that uses the CRT files.
I am not sure if it is your application after installation that doesn't work, or if it is a dll you use as part of the installation that doesn't work?
To make a very long story, very short: new versions of the C / C++ runtimes are installed as Win32 assemblies, or side-by-side installation. This means the files will go into folders under C:\Windows\winsxs - the Win32 equivalent of the GAC, and several versions of the same file can co-exist here.
Applications compiled with Visual Studio 2005 / 2008 will put a manifest file into the binary, and this manifest specifies what side-by-side runtime version to bind to. It doesn't matter if you put the MSVCR80.dll next to your EXE or even in system32 - the manifest embedded in the EXE will load the file from C:\Windows\winsxs.
This is all "full circle". In the old days runtimes went to System32. This caused the original dll-hell: applications overwriting each other's global runtime files. To remedy all this the idea was to "isolate changes" to each application. Hence the new approach was to isolate a local copy of the runtime file next to the EXE. Now this caused an entirely new problem: how do you make sure security updates for the isolated dll was deployed? In most cases this never happened, and you had lots of applications running with local, unsafe dll's. So what to do? The decision was to introduce the second coming of dll-hell: the side-by-side assembly approach. In this approach runtimes are not local, but global - with the critical difference of supporting side-by-side installations. This way, in theory, applications can function without overwriting each other's runtime dlls.
So that was the quick summary of "how to make runtime deployment complicated". I am not positive it is still possible to do, but did you check whether you can statically link to the runtime? Sometimes old-school really is easier...