Rolling out product for multiple languages and platforms? Not me. I just want to create a one-method DLL that returns "Hello World" and install it on my own computer, then communicate with it from Classic ASP or MS Access.
The code in the DLL is no problem. Discovering all relevant property sheets and filling them out correctly are. It's almost comical, after attempting an install, to see which property sheet values are used as file paths, which are in the registry, which are in the install/uninstall page, and so on. Who would expect the name of the INSTALL PROJECT to be used as the ACTUAL PRODUCT'S file path?
But today I limit my question to this: Should any GUID in my WiX project also be found in my DLL? My interface and class both have GUIDs. Do those need to be in the installer code, so the installer can add those to the registry? (Or are those GUIDs needed in the registry? If not there, then how are they used?)
Just trying to create a simple test to see WHAT WORKS!
If you have COM classes in your Dll that need registering then the general answer is to look at heat.exe, the WiX harvesting tool. For example the answer here:
How to run heat.exe and register a dll in wix
https://www.firegiant.com/wix/tutorial/com-expression-syntax-miscellanea/components-of-a-different-color/
Related
I want to make a MSI installation using WiX and EmbeddedGUI. I really want to make it highly modular - ie the main MSI will contain only the basic files (the required ones), and all other features will be split into separate MSI files, which will be downloaded from internet if not present on hard drive and installed only if selected in my EmbeddedGUI.
But I am totally new to WiX, and I can't find a way to actually how to make that modules? MS Office and MS Visual Studio seems to be using this scheme, by using the modules which it downloads over internet and installs them in case of need - something like this:
It seems that Fragments is mostly like "static libraries", not "dynamic libraries" which would be more useful in such a situation. There is also the Chaining mechanism, but I'm not sure I will be able to bundle the features as the same application (only one entry in "Install/Delete" window) because it seems to be calling external MSIs completely separately (more like invoking "separate exes" instead of loading "dynamic libraries").
So, what is the way to go for making a highly modular setup package with WiX?
Use a bundle (chain). The Burn engine, which manages bundles, will show only the bundle in Add/Remove Programs and can download any packages that aren't already present -- for example, using the MsiPackage/#DownloadURL attribute.
I'd like to create an installer package to install registration-free COM components (with manifest files included). This would be more or less a self-extracting archive to place some files in a target directory given as commandline argument, but it would also need to check or install some other redistributables like VC++ or DirectX.
The package is supposed to be used in another applications's installer as some kind of redistributable package itself. It should not be registered in the "Program and Features" dialog of Windows but has to be removed with the application. Ideally there should be no changes to the Windows registry.
So far I haven't been very successful. Can anyone please provide me with some hints regarding this use case?
You've got about a dozen different questions in that one question. Start with just creating a simple MSI that successfully installs your files and your manifest. Create a COM client to test it. You can also put AppSearch and LaunchConditions in your MSI to detect your dependencies and not allow installation if they are missing.
That's about all you should have to do for this simple question. As for the other questions.... if you are a redistributable and someone else is silently installing you then it's their job to handle the installation of the other redistributables. Also if they don't want you listed in Programs and Features they can pass the ARPSYSTEMCOMPONENT=1 to your installer and you won't be listed. If they want to uninstall you when they uninstall themselves, that's their problem not yours.
If you are really creating a redistributable to be used by other products, sometimes a merge module is the appropriate solution. They build their MSI files and include your merge module.
Otherwise, reg-free COM is in theory an easy install because you're just installing manifest files and Dlls etc. However I don't understand how that could be used by other apps because (IIRC) a client app exe needs your manifest and Dll in their install folder, so how can they do that when they are not installed yet? Or even if they are installed how can you find them? So that goes back to the merge module idea so they include your merge module and install an exe, your manifest and your Dll in the same location. When they uninstall so do your files.
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
Background to Question
I am currently in the process of trying to put together a means of distributing a new project I am working on which requires that a COM exposed .NET DLL be registered on the user's system and as I am new to WiX and making the move to it for this I am trying to keep things as simple as possible.
The Problem
The big issue with my DLL registration is that regasm sets the default value of the InProcServer32 key to "mscoree.dll", but my DLL can only seem to be instantiated when the full path to it is used, e.g. "C:\Windows\SysWow64\mscoree.dll"
Currently I have a custom action in my setup project (which I want to abandon to use WiX) which will call the SearchPath API to find the full path to mscoree.dll and overwrite the default value with the full path, so that the DLL can be instantiated without any issues.
Proposed Solution / Question
As I am new to WiX I have had the idea of preparing a .reg file that will contain all the necessary information to go into the CLSID tree and then having WiX execute that some how.
My question is:
Are there any inherent flaws by registering a DLL this way?
As the main reason I am trying to find work arounds here is the mscoree.dll issue, is there any native means of doing this in WiX?
Take a look at the WiX program called "Heat". This can "harvest" your DLL including registry information related to the RegAsm / COMVisible parts. You can then snip this code and work it into your wxs file.
You can also use Regasm /regfile and then manually transform that information into RegistryValue elements.
With regard to your path problem, use the SystemFolder property.
[SystemFolder]mscoree.dll
If you mark your install as 32bit (x86) this will automatically resolve to the SysWow64 folder when run on a 64bit OS and the System32 folder when run on a 32bit OS.
I have a C++ activex control that I need to make an installer for. It needs to drop the dll and make some registry keys.
I have about 6 .RGS files which I made for self-registration via regsvr32, which work.
To do an installer I am manually porting the RGS scripts into the visual studio 2008 windows installer registry GUI. I feel like its not possible to do an exact port (e.g. RGS keywords like ForceRemove).
Isn't there a way to generate these files from the IDL file? Am I doing this wrong?
SelfReg is not a best practice in an MSI install because it's out of process and fragile. Visual Studio 2008 Installers are limited but you should be able to set the Register property to vsdrfCOM instead of vsdrfCOMSelfReg. This will cause the COM meta data to be harvested from your DLL and authored natively in MSI.
After you build your MSI, you should notice the SelfReg table is empty and a serious of automatically authored rows in the Registry table for you COM data.
Note: VDPROJ is kind of flakey at extracting this COM so it may not work. You might have to consider a stronger tool such as InstallShield or Windows Installer XML.
You are doing it wrong. The .rgs files are there so that the component can install itself. Any installer supports letting a component install itself. A Visual Studio Setup project for example, set the Register property.