I am designing a multilanguage application in C#. The project structure is shown here:
The form frmLogin use 3 resource files to get some controls text and labels frmLogin.*.resx which I would like to add in the wix project file.
The language is selected at runtime by a number of radio buttons.
I DO NOT want to have a multilanguage Wix installer, just a single installer which installs the required culture-elated dlls in the installation directory
I looked here Add resource files in wix installer but it did not worked in my project
There is something obviously wrong in the wix project file since it does not create language directorys like this:
in the installation directory ...
I am sorry if I am missing something trivial but I am starting now with wix which looks very promising indeed but I am just starting now
many thanks
Related
I am trying to create an installer with Wix and Visual Studio 2019. I am a Wix newbie so I just started to get something really simple working, from scratch. Therefore, I read this explanation. I use Windows 10 build 19042.
Creating the winforms project does work fine for me but the next project does not. This is because of this step.
Choose the Windows Installer XML node in the Project types tree,
then select Setup Project
I can find Wix projects.
And I installed the Wix toolset.
So creating a very simple installer should be very simple. But in fact, it is not as I fail to do one tutorial step referring to a project type I cannot find.
You can help in these ways:
Tell me what to do the make sure the Windows Installer XML node
becomes visible.
Provide the step to do the same without the Windows Installer XML node.
And logically, I double checked if the Windows Installer XML node is really not there. And it really is not.
VS2017 vs VS2019: I guess that explanation was written for Visual Studio 2017 - which is quite different for the "New Project" dialog. You can select "WiX" in the drop down button that says "All languages" in that dialog
WiX Project Types: Just double click the "Setup Project for WiX v3" - this is the project type that creates an MSI. The "Bootstrapper Project for WiX v3" is for making setup.exe bundles.
WiX Downloads: For the record, make sure you have installed both WiX itself and the WiX Visual Studio Extension. It looks like you already have (just mentioned for others who see this).
WiX Training: I have a few answers on WiX crash course and training material:
Short WiX sample links
Long WiX Tips and Tricks and samples links
A few selected examples from github (there are more WiX projects at the root level):
https://github.com/glytzhkof/WiXDefaultDialogsSample
https://github.com/glytzhkof/WiXLaunchConditionTest
We have a solution, there are about 100 hundred projects in it. And we have around 20 installers which we created with vdproj.
I need to create WiX projects, which would create .msi instead of vdproj. I used dark.exe to generate wxs file out of msi and got binaries out of it.
I successfully created an msi file and everything was good.
But then I started thinking about it. If some of these projects are changed, will those changes be applied to the application after rebuilding of wix project? Or wxs will be referencing the old version and to update it someone will have to rebuild vdproj project to create new msi, then use dark.exe again?
I am sorry for a stupid question, it's my first time using wix and working with installers in general.
Thank you in advance
You've started on the right track. The VDPROJ outputs are .msi files, so using dark to convert those to wxs files is the right thing to do. Now that you have your wxs files (the base source file to build wix deployments), you can do away with the VDPROJ projects in your solution and only update and use the wxs files (I believe WiX has a visual studio project template available as well).
You'll have to update you wxs files with new assemblies or deliverable files as your projects change.
It is better this way then doing a wildcard pickup (something you can't technically do with WiX, anyway) as having explicit control of what goes on the target machine is preferred. I've seen many cases where developers carelessly add a reference as build output that isn't needed, and sometimes that reference cannot be redistributed per the license agreement or other legalities.
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/
Can someone help me understand how WiX works? I have a directory structure which I would like to create an installer for. I have generated the for the directory structure with heat.exe and when I build the setup project it generates an .msi file but I don't think it installs anything.
Maybe someone can walk me through the steps of generating a .msi installer.
Any advise is appreciated,
Thank you
If you're using Visual Studio:
Install the WiX Toolset V3 Visual Studio plugin.
Install the Wax interactive editor.
Build your project if you haven't already.
Add a new project to the solution containing the project you want to create an installer for.
Choose the template Setup Project for WiX v3.
Name the installer. A personal convention is the name of the project plus ".Setup"
A Product.wxs file will open up. Change the Manufacturer="" value to something like your company name or your name. Keep the file open.
Go to Tools -> WiX Setup Editor
On the left under Root Directory choose InstallFolder
Under Projects to install, choose the project you want to install.
In the red area to the right, you'll see a list of files. These are the output results of your build from step 3.
Click the plus sign next to files you want to copy. They should turn white and change to a Resolved state.
This might look daunting, but you're just telling it what to copy--which would be your project's executable, configs, dll libraries, and images it's dependent upon.
You typically want to copy everything. If there are dll's you know you don't need, it's better to remove them as a dependency from the Visual Studio.
Notice the Product.wxs has changed. It now has the files you checked off in the Setup Editor GUI added to the <Wix><Fragment><ComponentGroup> section. Save that file.
Close the Setup Editor.
Build the setup project you just configured.
Open Windows explorer and go to that project's bin/Debug or bin/Release folder, depending on what mode you built in. There you'll see the .msi that you can copy to where you need.
To make an update, make the necessary changes and then change the version number in that project's Properties -> Application -> Assembly Information. Then also change it in Product.wxs <Wix><Product.Version>. Then just build your setup project again.
Good tutorial here:
http://wix.tramontana.co.hu/
http://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with
They should get you started.
If you learn something about the MSI log that will also help - install the MSI with a command line that includes /L*vx
And "doesn't install anything" should be easy to check - are there are any files installed, or did it create an entry in Programs&Features?
WiX is a language (XML/XSD) that serves as a way of authoring (compiling) Windows Installer (.MSI) databases. WiX doesn't install anything, MSI does.
I maintain an open source project called IsWiX. The concept is simple. IsWiX provides additional WiX project templates (scaffolding) and graphical designers to assist you in creating installer. Then as you gain knowledge of WiX and MSI you can make additional tweaks of the WiX XML by hand and go beyond what IsWiX currently knows how to author.
Here's a video showing how to author, build and test an MSI to deploy an IIS website in a mere 3 minutes.
Update: IsWiX has tutorials now.
After a few 'false starts' trying to learn WiX from online tutorials I noticed that on http://wixtoolset.org/ there is a link to the book "WiX 3.6: A Developer's Guide to Windows Installer XML". You can buy it pretty inexpensively in E-book form from Packt, or also Amazon if you like the easy interface with Kindle.
I found this book to be VERY helpful with every little step regarding the .msi creation process. The book will guide you to create your first .msi in the very 1st chapter! Granted, you have to continue a little more to have a fully functioning .msi, but given the complexity of Wix, this book is terrific. It may not be for the gurus among us, but for those of us who need a little more help to understand the material it's wonderful. I've seen many posts speak to the 'steep learning curve' regarding WiX and it is a complicated process to create a valid .msi, but this book goes a long way toward making that learning curve very bearable.
If you are using the build system 'cmake', then you can use cpack to generate .msi file by setting the cpack generator to wix.
What worked for me best, was this fantastic tutorial video: https://www.youtube.com/watch?v=6Yf-eDsRrnM
Its best selling points for me was
independent of visual studio version
it describes deploying a .NET (Core) app also
it focuses on what an average app's installer should be capable of (including heat, icon, background image and banner)
you don't have to learn another layer on wix
it gives you good practices on easy package generation and future maintenance
it gives an installer project template which you can reuse: https://github.com/angelsix/youtube/tree/cecd38ea3d5eea11cc75fc0123297ffc3b5e662b/C%23%20General/Windows%20Installer%20Wix%20DotNet%20Core/ConsoleApp1.Installer
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.