I've made multiple C# DLLs in MS Visual Studio which I then access from Excel via VBA calls. These work fine on my machine (obviously VS COM registers them for me when compiling as long as I have the right boxes ticked). I also got them working on other machines by searching my registry for any seemingly relevant keys to each of the DLLs, and copying the entries into other machines registries. Obviously that's madness though, so I want I want to make a simple installer so I can install said COM DLLs on other machines easily.
Since I have a windows forms app in there to test all the DLLs, I figured it makes most sense to just make an installer for that app, and the other DLLs should get installed as they're dependencies. Right-clicking, and publishing gives me the setup.exe. I can then install this on the other machines. But the DLLs aren't COM registered on the new machine, so although the test app works, I can't actually use them from Excel/VBA.
What do I need to do? (googling only seems to turn up pretty old stuff that I can't seem to follow with older versions of VS)
I'm using the full version of VS 2019.
I'm using the basic right-click/properties/publish to make a setup.exe and associated folders.
I may get more options by adding an MSIX installer project into the solution? But I've never done that before so when I tried the learning curve of that it seemed a nightmare and wouldn't compile, largely complaining I didn't seem to have an icon of every size under the sun included. Trying to use VS to auto-generate them from 1 image caused VS to crash every time. I can try sitting in paint making them all manually if that's my only option, but it may be pointless if I don't need and MSIX installer anyway.
At this point I'm also interested in just COM registering them manually for sanity sake without typing in the registry entries, and can work on the installer later. But as far as I can tell regasm/gacutil aren't on any of these other machines. (I also haven't used that before, so am somewhat confused by which I should use, and if I need to do it for both x86 and 64.)
I'm a noob to VS installers, DLLs and the registry (and associated terms), so please try keep it simple. Although obviously I've got as far as making C# DLLs I can call from VBA (once COM registered), and they otherwise work a treat.
Related
I am trying to distribute a program in our small business environment. I tried to choose therefore ClickOnce in Visual Studio 2019 and DotNet 5. However, if I open the EXE from the published folder, it tells me that a DLL is missing. After adding this one, it tells me another DLL is missing, aso. In contrast, if I publish to a local folder, everything works as expected.
What may I do wrong? It seems like the missing DLLs have something to do with PowerShell automatization (Microsoft.Management.Infrastructure) which as I understood is only available as either x64 or x86. I tried to restrict my program to x64, however, without any success.
If you know any other simple distribution method for a small business (all pcs conneted locally) I am very happy and thankfully.
The solution was simple. Missing dependencies can be added here, during the setup for ClickOnce export creation.
I developed a program in VB 6.0 and used Package & Deployment Wizard to build an Setup exe file installer, but my software contained some dependency folder and the VB Package & Deployment only allows files, not folders.
Does anyone know any other types of Packages & Deployment or setup generator that I can use?
You're asking the right question. :) The PDW was never a stable enough solution to risk using it in a production environment. It never fully solved the "DLL Hell" problems that come up with it.
One of the main problems was that after the PDW was released, OS service packs started disallowing replacement of numerous DLL files that were used by the OS. This was the only way that they could solve the ubiquitous version problems that were plaguing server installations everywhere. They never did anything with the PDW to address this change. So, if your installation package includes a DLL file that the OS doesn't allow you to replace, the OS won't register it. Then, when you reboot as part of the installation process, the PDW errors out and tries to reboot again, and you get caught in an endless loop of reboots. Very very bad. If you should be interested, I wrote this up in detail here back in '03.
There are plenty of solutions for what you're trying to do, and some of the other answers give some of them. Microsoft's own solution is the Visual Studio Installer, which you can read up on here. This is the one that builds those .msi files that you see all the time; msi = Microsoft Installer.
Try using iexpress.exe, it's built in with windows for creating windows installation packages, it's fairly simple to use and i know it works for windows7, 10, and probably others too! You can search in the start menu to find it or use the run dialog box, or command prompt, just type in iexpress.exe and there you go, i make a few vb6 setup programs this way.
Why should one go for Windows Installer XML (WiX) when we have in built .net MSI installer?
It would take me hours to rant about everything I hate about VDPROJ. I won't because in my (expert) opinion it's already settled law that VDPROJ sucks. If your install is so simple that you haven't noticed any problems, then be my guess and stick with it. But if you already find yourself fighting the tool trying to get it to do things it doesn't do, then take my advice and dump it fast for WiX.
10 things I hate about VDPROJ
No MSBuild Support. Sure, you can call devenv from the command
line but it's not as good.
No exposing of the critical concept of
a component. Every file/reg key is a keyfile of it's own component.
No effective way to fully exclude automatic dependency scanning.
Shortcuts are always Advertised
No way to describe a service.
No way to describe many things which leads to overuse of custom
actions.
No way to fine control the scheduling / execution of
custom actions. Too abstracted.
Abstraction is wrong. Deferred
CA's are scheduled with Impersonation which breaks on Vista.
Various limitations lead you down a path of massaging the built MSI
during postbuild to get around all the limiations. Results in a
very poor build automation hacks.
Merge Module directory tables
are authored incorrectly.
100 other things suck that I'm not
remembering right now.
The introduction of WiX tutorial gives the basic idea about WiX advantages comparing to other setup development tools (including VS setup projects):
declarative approach
unrestricted access to Windows
Installer functionality
source code instead of GUI-based
assembly of information
complete integration into application
build processes
possible integration with application
development
support for team development, both
in-house and third-party
free, open source
Hope this helps.
Visual Studio deployment packages can only be built by visual studio. They cannot be built using plain MSBuild command lines, which makes them less than ideal for e.g. build servers.
All the above answers have included most of the annoying features of Visual studio setup projects (.VDPROJ), one thing that most people have missed.
.VDPROJ file format is such that, and if we make a small
change to one single entry it completely rewrites all the entries
within which makes it impossible to merge changes from 2 different
branches.
Some of us don't want to use / can't use the .NET installer.
Some of us don't want to have to install Visual Studio to distribute a program, written in, say, Borland Delphi. WiX and .NET have nothing to do with one another.
WiX provdes a much more complete feature set than the .NET installer.
I am wondering about the need for an install wizard for my little Windows Forms application. No database access, just file access on a shared network drive.
I have seen times when an executable is sent in an email, copied to a desktop and used.
Other times when an 'install wizard' seems to be used to set up the application.
What dictates the need for this or not?
And if I want to use one - what needs to be added to my windows form app?
If your application is truly just an .exe file, it's probably okay to distribute it as-is without an installer. This might be preferable for more advanced users, because they won't have to worry about cleaning up a broken/unwanted install - they can just delete the file and be done with it.
On the other hand, most Windows users are used to working with installers, and having shortcuts automatically created on the desktop or Start->Programs. This is where an .msi can really help. Also, using an installer will usually put your application in the "Add or Remove Programs" control panel, which most people know how to use. Also, if your application is more than just a single .exe file (e.g. multiple .dlls and resource files), you'll probably want to use an .msi.
Creating an installer is easy, look at "Setup Projects" in Visual Studio.
An installer is almost always a good idea, because it can work out what dependencies your application has - which you may not even be aware of.
It also looks more professional and users will have more confidence in it.
There's an open source installer called NSIS that's pretty good, if you find the Visual Studio setup wizard too clunky, as I sometimes have.
Sometimes simply copying a file just isn't sufficient, this is when you need a setup program.
Checking if the correct version of .NET is installed
Installing C++ runtime dependencies
Creating a desktop shortcut
Setting up "default" configuration data
Adding exceptions to the Windows Firewall
Preventing installation on unsupported systems such as Windows 95/98/ME
etc, etc.
If your program is a stand-alone application with no dependencies and can run on a stock-standard install of Windows 95... then you don't need to worry about setup ;) But if your app has any external dependencies then you want to spend some time on setup.
I'm using a VS 2008 Setup and Deployment project to deploy a mixed managed / unmanaged application. I've had trouble registering mixed-mode DLL's using the built-in registration property ("vsdraCOM" enumerated value of the "Register" property.) As a workaround, I've added a .NET custom install assembly (with a class that derives from System.Configuration.Install.Installer.) I'm certain that that class is running and a number of operations successfully install and uninstall through code in that assembly, including executing the Dll(Un)RegisterServer entry point of a number of assemblies.
However, one DLL is not successfully registering. It is the only DLL that depends on some 3rd-party redistributable assemblies that want to be installed to the GAC. I have those assemblies installed to the GAC thanks to the built-in support for that in VS 2008's setup and deployment projects, and I know that is working. I've confirmed that what is happening is that the custom action is executing before the installer executes the GAC installation.
Whew. So my question is, is there a way to force the installer to execute the GAC installation before executing the custom action? Is there a way to use the "Condition" property of the custom action to do this? If not, what's my best alternative? Capturing the registry entries from the DLL and adding them to the registry settings for the installer (don't like this because someone may add new COM servers to the class in the future)? Using .NET code to install the assembly into the GAC manually (don't know how to do that yet)?
Thanks,
Dave
The setup projects you can create in Visual Studio are very limited. It only allows custom actions to be scheduled at 4 points. However, MSI allows custom actions to be scheduled at any point in the process with some restrictions on what they can do.
My first solution is to stop using Visual Studio 2008 as your setup development tool. The Visual Studio team has tried to abstract away all the complexity of creating an install. However, in the process they have also taken away all the flexibility of MSI. Wix, InstallShield, or Wise are much better products for anything but simple installs. I started off using Visual Studio for our installs and it ended up being too much work. There was always one more workaround to be implemented and its side effects to be dealt with.
If you can't switch technology, then you will need to learn how to manually modify the resulting MSI file. In your case you will need to modify the InstallExecuteSequence table, http://msdn.microsoft.com/en-us/library/aa369500(VS.85).aspx. You can do this manually through Orca, http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx or through the MSI API http://msdn.microsoft.com/en-us/library/aa372860(VS.85).aspx. Make sure to download Orca and run the validation scripts against your install. The scripts point out numerous problems that fixing will save you countless hours when deploying to customer machines.