I've created a program and would like to release it, but am currently struggling with dll dependency issues. How can I create a msi installer package that will properly install .dlls? Every solution I've found online so far has created msi packages that only include the exe.
Short Answer: Generally, the most common runtimes are: Java, Visual Studio C/C++ Runtime, .NET Framework. Try installing these on a clean virtual and try launching your application. Debugging application launch check-list.
Modern Deployment: Many Microsoft runtimes that we used to deploy are now part of Windows. An exception is the Visual Studio C/C++ runtimes. I am not sure why they are not just included in Windows at this point. In general you should not pick single dll files to deploy, you need to locate a merge module, a setup.exe or an MSI to deploy the runtime. Commercial tools have features to help you download such bundles.
Setup: The basic, general steps to create a setup are described here: How to create a windows installer for multi language program with outside dependencies?
Specific Runtimes: One can generally determine runtime requirements by looking at the application files (experience - trained eye), looking at the application GUI (visual clues), checking dependencies using dependency scanner tools, talking to the developers of the application, checking file properties of files you find to depend upon (Company name is a good clue), etc... Then you verify and test this on a clean, virtual machine. You keep installing runtimes manually until your application works. In the section "The Complexity of Deployment" here you can find a listing of common runtimes and technologies.
Related
I have a dll project which I need to install into the GAC, on our Production machines.
(I wish I didn't have to use the GAC but SSIS insists)
gacutil.exe is not available on the target machines and using "Enterprise.Services" from PowerShell does not work (I don't know why)
My understanding is I should created a msi installer project.
However after installing the Setup and Deploy Extension to Visual Studio (2015 soon to be 2017), I discovered those projects cannot be built by our Build Server because it uses MSBuild, and MSBuild can't build vdproj project files.
What is the correct way, using a CI build pipeline (MSBuild), to create build artifacts, which can install dlls to the GAC, of a Production Environment?
Note: there are several partial answers on SO, but I could not find any, which were up to date/answer my whole question. Please keep that in mind when answering.
You need to break this down into several user stories. You aren't finding partial answers, you are finding actual answers for specific questions. What you ask is more like an epic.
In general I would create an MSI using Windows Installer XML. WiX/MSI can install files to the GAC without using GACUTIL. If you use the WiX Visual Studio extension "Votive" you can create a .SLN / .WIXPROJ / .WXS that can be built using MSBuild. You can then put this into a source control system such as Git/TFVC/Subversion and use a build system such as VSTS V.Next Build, XAML Build, Concourse, Jenkins to automation the pipeline to build the MSI.
I'm very new to WiX based applications, and I need to create an MSI file where it has to check for .NET Framework 4.0 and SQL Server 2008. If they are not installed, I have to get them installed first and then have to install my application's EXE file and one more VBScript agent. It must be done like when you install WiX 3.7 setup (if we double click the setup file, it will show a UI as shown below!
Where do I start? Is there any step-by-step guide to develop this kind of application?
You'll need the following projects. They can be created from project templates in Visual Studio. Each of them would probably have separate tutorials that you might find with a Web search.
A WiX Setup project to build an .msi. The source files for such a project declare a WiX/Product. It could have conditions that check for .Net Framework4.0 and SQL Server 2008. If a check fails, installation of the .msi will fail, which is all that can be done in an .msi. The project would include your application .exe as a Component.
A WiX Bootstrapper project to build an .exe. The source files for such a project declare a WiX/Bundle. In the bundle is a Chain of installers, which would include .Net Framework4.0, SQL Server 2008, your .msi, and your VBScript Agent.
A WPF Library project to provide a BootstrapperApplication implementation with a custom UI for the bootstrapper project.
Your best bet is to consult the documentation, the WiX source code and various tutorials. Keep in the mind that tutorials might be out-of-date--in most cases WiX has gotten simpler with each version.
I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.
I developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
I have a set of utility LabVIEW VIs that make calls to a custom DLL written in C++. I'd like to package the VIs into a LabVIEW toolkit and deploy it via an installer, but am unsure about the standard practices involved in doing this where a custom DLL is involved. I've looked at VIPM for packaging the VIs, but so far I haven't found a way to generate a package and include the appropriate DLL dependencies. What is the correct way to go about generating an installer for a LabVIEW Toolkit and installing the DLL dependency for said toolkit in the correct location (where ever that may be)?
The DLLs immediately known to the system - i.e., the ones entered in the CLFN node - are added automatically.
DLLs which are used indirectly and DLLs which are determined programmatically cannot be auto-included and must be added manually to the Source files section of the respective Build rule.