We Keep Coding

WiX installer msi not installing the Winform app created with Visual Studio 2017

For a simple test I created a Wix installer app for a simple Winform app as follows. But when I run the msi created with the installer it runs for just one second and exits without installing the Winform app. Question: What could be the issue here? It seems something is missing in my Product.wxs file. Note: I'm using VS2017
Steps to produce the issue
Installed Wix Toolset Visual Studio 2017 Extension from here and followed their instructions to install WiX 3.11 RC2 from here
Created a default Winform project [just one single form nothing added to it]
Created a Wix Setup project by using Toolset\v3\Setup Project template in the same solution
In WiX Setup project Added a reference to Winform project
Built the entire solution.
Right clicked the Setup project and re-built it that created an .msi file in its \..bin\Debug folder
Double clicked the .msi file from step 6. File ran for one second, windows 10 installation dialog appeared (as it appears for any installation asking you if you want to install this program). I clicked Yes. Installer ran for one second again then exited. But the Winform app was not installed.
Default Product.wxs file [I did not add anything here except for adding a value to Manufacturer attribute]
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="SetupProject1" Language="1033" Version="1.0.0.0" Manufacturer="WiX_test_4_Winfrm" UpgradeCode="e69fe67b-5c28-4764-8196-a6613b840eff">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate />
<Feature Id="ProductFeature" Title="SetupProject1" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="SetupProject1" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<!-- <Component Id="ProductComponent"> -->
<!-- TODO: Insert files, registry keys, and other resources here. -->
<!-- </Component> -->
</ComponentGroup>
</Fragment>
</Wix>

WiX Resources: A couple of links first:
WiX quick start resources.
Hello WiX C# Custom Actions.
"Hello WiX" (transparent aluminum please)
I think what you need is the "Hello World" of WiX from CodeProject. This is quite old now, but still good at showing you the very basics of getting a working MSI compiled.
UPDATE: Below I have added a step-by-step description of how to compile an MSI from a fresh WiX 3 Visual Studio project.
Here is another answer from way back with some context information for what WiX really is: MSI vs nuget packages: which are is better for continuous delivery?. You will find the link to "hello world" here as well, but also several other links.
In summary: check the first link to get the "hello world" of WiX. Then update your source with a couple of test components and recompile. You should get hold of Orca (SDK tool) to be able to view the compiled MSI files. Since you have Visual Studio installed, try searching for Orca-x86_en-us.msi and install it (this is Microsoft's own, official MSI viewer and editor). Then find Orca in the start menu. Technically Orca is installed as part of Windows SDK (not Visual Studio), but Windows SDK is bundled with the Visual Studio install. Once you have a compiled MSI file, just right click it and select Edit with Orca.
Some experience will be needed before such a file really makes sense. In essence it is a primitive MS SQL database stored in a COM structured storage file (OLE). Essentially a file system in a file with streams for different content (such as files, and datatables, etc...). Just think of it as a database with normal referential integrity and focus on the core tables such as File and Component at first.
Minimal WiX MSI Compile - Step-By-Step
Let me try a step-by-step description of what you can do in a freshly made WiX 3 project to make it compile with a default WiX GUI. You can see these changes "merged" into a complete sample in the last section of the answer, but do read this step-by-step so it makes sense.
Create a new WiX3 project. You know how to do that, I won't waste time with the details.
Set the Manufacturer attribute to your company name. Now set a new name of your choosing to the Name attribute. In this sample it is set to MinimalTester - use something else please.
Change <MediaTemplate /> to <MediaTemplate EmbedCab="yes" /> to use embedded cab files in the MSI. This way only the MSI is created and there is no additional, external CAB file.
Directly after the MediaTemplate element, add this: <UIRef Id="WixUI_Mondo" />. This will add a default WiX dialog set to your MSI so it has the basics of what is needed to be more generically useful. You can now run repair, and modify and you get a wizard for the original install along the lines of what most MSI files provide from Installshield or Advanced Installer or other professional tools. And crucially: your administrative installation will have a dialog where you can specify where files should be extracted to.
We will add our own License Agreement to the WiX setup (or else you will get an mumbling default one). Directly following <UIRef Id="WixUI_Mondo" /> add this element: <WixVariable Id="WixUILicenseRtf" Value="TestLicenseAgreement.rtf" />. Now create the file TestLicenseAgreement.rtf and place it in the same folder as your main WiX source file (quick way: in Visual Studio, right click project and "Open Folder in File Explorer", now create the RTF file with right click => New => RTF file
. And maybe open the RTF and enter some test text). Further customization of the dialogs (bitmaps and more).
The WiX dialog set is defined in a dll, we need to reference it. In your Visual Studio WiX project: Right click References => Add Reference... => Navigate to C:\Program Files (x86)\WiX Toolset v3.11\bin\. Double click WixUIExtension.dll and finally click OK.
Now add the absolute minimal component possible in WiX with an absolute path specified as source. This is to be sure you can compile the MSI. Afterwards you can make the path relative or a variable (just add this directly under the INSTALLFOLDER directory element for now):
<Component Feature="ProductFeature">
<File Source="C:\Users\someone\SourceControl\MyProject\CoreApp.exe" />
</Component>
Finally right click the WiX project in your solution and select Build. And you can quickly test run the MSI by right clicking the WiX project and clicking Open Folder in File Explorer. Now double click on bin and then Debug (or Release if you switched to a release build - not sure what "default differences" are between the two configurations). You should see your own license agreement in the second dialog in the dialog sequence.
The later WiX versions have great defaults for attributes that are almost always set to "template values" or where two attributes essentially are redundant. Just leave them out of your source and let the WiX compiler add them with default values. Much less fuss.
As an example: The above element lacks a Component Id. During compilation it defaults to the Id of the File element it contains. The File element Id in turn, is also missing and will default to the file name specified by the Source attribute (which is a mandatory attribute).
Maybe look at this answer for a longer description and a concrete example towards the bottom: Syntax for guids in WIX? See how simple your WiX source files can be once you eliminate all the redundancy and duplication of certain attributes? Less text, less bugs.
Sample Minimal WiX Source - Inline Comments
In the below sample the component has been moved into the default ComponentGroup - hence there is no need to specify what feature it belongs to (unlike above).
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!--CHANGE 0: Set Manufacturer attribute to something, you must also specify a full GUID for UpgradeCode -->
<Product Id="*" Name="MinimalTester" Language="1033" Version="1.0.0.0" Manufacturer="My Company" UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<!--Standard: <MediaTemplate />-->
<!--CHANGE #1: Enable embedded cab files, so there is only one file generated, the MSI file -->
<MediaTemplate EmbedCab="yes" />
<!--CHANGE #2: Add the following elements to link one of the default WiX GUI sequences and show the specified license agreement. The RTF file must be created and placed next to your WiX source file -->
<UIRef Id="WixUI_Mondo" />
<WixVariable Id="WixUILicenseRtf" Value="TestLicenseAgreement.rtf" />
<!--CHANGE #3: Add WiX dll reference. In Visual Studio WiX project: Right click References => Add Reference... => Navigate to C:\Program Files (x86)\WiX Toolset v3.11\bin\. Double click WixUIExtension.dll. Click OK -->
<Feature Id="ProductFeature" Title="MinimalTester" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="MinimalTester" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!--CHANGE #4: Remove TODO elements, add the most basic component possible as illustrated below -->
<Component>
<File Source="C:\Users\someone\SourceControl\MyProject\CoreApp.exe" />
</Component>
</ComponentGroup>
</Fragment>
</Wix>
Try to compile and test install. Should install to C:\Program Files (x86)\MinimalTester on a normal system.
Maybe see further links for WiX tutorials here: WIX Installer not displaying the custom image of WixUI Dialog correctly.

Try this:
https://github.com/iswix-llc/iswix-tutorials
https://www.youtube.com/watch?v=nnV_OU6fk8c
Disclaimer: I'm the maintainer of IsWiX, a FOSS WiX accelerator that provides enhanced project templates (scaffolding) and graphical designers to do the majority of the WiX XML heavy lifting for you. As you can see from the video, this is easily only a few minutes of work.

How to generate msi from windows application

I have a Windows Application class where I have defined my Windows Service, and I need to generate a .msi (installer) from it.
What I have done so far for this is: create a new project in Visual Studio Enterprise 2017 - the project is of type Setup Project for Wix v3 (from Wix Toolset); inside this project I have by default References and Product.wxs. From Add References, Projects, I added the Service project.
One of the sources that I found says all that's needed is to add
Source="$(var.MyApplication.TargetPath)" />
as seen here:
http://wixtoolset.org/documentation/manual/v3/votive/authoring_first_votive_project.html
...but this doesn't work for me because:
undefined preprocessor variable $(var.MyApplication.TargetPath)
I don't know where to define this variable and what is the meaning of this path.
Excerpt here:
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent">
<!-- TODO: Insert files, registry keys, and other resources here. -->
<File Source = "$(var.MyApplication.TargetPath)"/>
</Component>
</ComponentGroup>
Any ideas?
Thanks.
This is all autoenerated code except for the File Source line. Don't know what I should add for INSTALLFOLDER either and what the syntax should be.
The purpose is to generate the .msi from my windows service

The Wix documentation for this step is broken as of at least version 3.11.
Instead of creating two separate solutions (app and Wix) you need to add the Wix setup as a second project in your windows forms solution. In the app Solution Explorer pane right-click on the solution then choose Add > New Project. Choose a name like WixSetup.
Next, click on the WixSetup project > References and choose Add New Reference. The projects list should show your app since they are in the same solution.
Next, add the entry to the in Product.wxs but the documentation is incorrect there too, you need to wrap it in a component tab. (Replace MY-APPLICATION-NAME with the name of your windows forms app project.)
<Component Id="ProductComponent">
<File Source="$(var.MY-APPLICATION-NAME.TargetPath)" />
</Component>
You also need to edit line 3 of the .wsx to include a non-empty company name or to remove that attribute:
<Product Id="*" Name="WixSetup" Language="1033" Version="1.0.0.0" Manufacturer="MY-COMPANY"
Finally, you must have a release build in your main application before building the Wix MSI.

How to programmatically update project references in a Visual Studio project

I have a file structure like the following:
- binaries
- binary1.dll
- dev
- <developer-name>
- a.csproj
-trunk
- a.csproj
Developers who need to work on a.csproj will create a branch in dev and they will work from there. Our projects need to have a reference to binary1.dll in the binaries directory.
If the reference is a relative path (the Visual Studio default) then the path will not work both for the project in trunk and the project in the developer's branch.
To work around this problem I thought of creating an environment variable and using that in the project file instead:
<Reference Include="binary1">
<HintPath>$(MY_ENV_VAR)\binary1.dll</HintPath>
</Reference>
This works perfectly, but I wanted to help developers add references more easily, so I wrote a program that will convert relative paths that point to binary1.dll (for example, from the dev branch a.csproj it would change the path ../../binaries/binary1.dll to $(MY_ENV_VAR)\binary1.dll) but I have not figured out how to get that to work.
If I use a pre-build event, the project is already loaded into memory and the event return an error because it cannot write the project file.
Then I realized that I could override MSBuild targets, and attempted with the targets: BeforeCompiler, AfterCompiler, BeforeBuild, AfterBuild and in all of them the project is already locked.
Then I ran into this answer and I modified my code to call the executable in the GenerateApplicationManifest target, but that one doesn't seem to call the executable at all.
Some other ideas that I have been playing with are creating a new project that does the updating of the second project and have a link between them, but that would duplicate the number of projects.
I could also just change the depth of trunk, but that only hides the problem and doesn't really solve it. When developers create a branch inside their dev branch to work on different features or bugs then I have the same problem all over again.
There might also be another feature which fixes this in a more elegant way, but I haven't been able to find anything.
So my question: How do I get MS Build or pre-build events to modify a CS project?

I found a way to do this. The issue was that the Visual Studio process itself was locking the project, but Visual Studio could overwrite the file. I ended up modifying a.csproj to include:
<Target Name="BeforeBuild">
<Exec Command="UpdateReferences.exe" /> <!-- This creates the $(ProjectPath).new file -->
<Move SourceFiles="$(ProjectPath).new" DestinationFiles="$(ProjectPath)" />
</Target>

Configuring Postsharp logging toolkit

Using the free version of Postsharp, I added a logging aspect (using the toolkit, didn't code it myself). Later I changed my mind and wanted to log only upon entering a function, and not on leaving.
Where can this be configured? Couldn't find it anywhere.
Thanks!

Diagnostics configuration is stored in solution (.pssln) or project level configuration file (.psproj). These files may not contain required configuration tags or even they may be missing by default.
You can open the configuration wizard from smart tag over any method without [Log] attribute. The configuration you are interested in is on the first page (Logging Level). Note that there is "New logging profile..." at the bottom of this page - you can have multiple configurations within one application.
If you change diagnostics configuration then pssln file is created after completing the wizard and it should contain something like this:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.postsharp.org/1.0/configuration" xmlns:d="clr-namespace:PostSharp.Patterns.Diagnostics;assembly:PostSharp.Patterns.Diagnostics" xmlns:p="http://schemas.postsharp.org/1.0/configuration" xmlns:p1="http://schemas.postsharp.org/1.0/configuration">
<Property Name="LoggingEnabled" Value="{has-plugin('PostSharp.Patterns.Diagnostics')}" Deferred="true" />
<d:LoggingProfiles p:Condition="{$LoggingEnabled}">
<d:LoggingProfile Name="Default" OnExceptionLevel="None" OnSuccessLevel="None" />
</d:LoggingProfiles>
</Project>
The interesting tag is d:LoggingProfile with it's attributes OnExceptionLevel and OnSuccessLevel. You can add this configuration file manually as well.

C# + StyleCop + MSBuild + Global culture settings failing to be picked up

I've got my C# project file set up to import a StyleCop.Targets project that runs all the StyleCop rules on build. This is great and I've got the project down to zero errors when compiling through Visual Studio.
However when I compile through MSBuild (on the same machine) I get errors along the line of :
The documentation text within the constructor's summary tag must begin with the text: Initializes a new instance of the <see cref="MyClass" /> class.
Focus on the 'Z' in initialises... I've configured my Settings.StyleCop with an en-GB global setting so that I don't get errors about Americanisms within the code. However I can't fathom out why this causes errors in MSBuild.
I know MSBuild is using the same Settings.StyleCop file as if I change a rule (say TabsMustNotBeUsed) MSBuild (and Visual Studio) picks this change up and throws errors all over the place.
I am using StyleCop 4.7, Visual Studio 2012 and MSBuild 4.
Here is a snippet of my Settings.StyleCop file :
<StyleCopSettings Version="105">
<GlobalSettings>
<StringProperty Name="Culture">en-GB</StringProperty>
</GlobalSettings>
<Parsers>
<Parser ParserId="StyleCop.CSharp.CsParser">
<ParserSettings>
<BooleanProperty Name="AnalyzeDesignerFiles">False</BooleanProperty>
</ParserSettings>
</Parser>
</Parsers>
<Analyzers>
<Analyzer AnalyzerId="StyleCop.CSharp.SpacingRules">
<Rules>
<Rule Name="TabsMustNotBeUsed">
<RuleSettings>
<BooleanProperty Name="Enabled">False</BooleanProperty>
</RuleSettings>
</Rule>
</Rules>
<AnalyzerSettings />
</Analyzer>
</Analyzers>
</StyleCopSettings>
Any clues ?
Cheers!

I'm assuming you're using the latest version of StyleCop (4.7.41.0) or a version close to that. There have been a lot of changes and fixes in the 4.7 version line, and there have been fairly regular updates released.
I'm guessing that there must be another Settings.StyleCop file lower down (in a sub-folder) in the folder hierarchy that is setting the culture back to en-US. Modifying other rules in this particular settings file (like TabsMustNotBeUsed) will still behave as expected as long as you're not setting it again in the other settings file. A potential cause could be the working folder that StyleCop is being run from.
I suggest doing a quick scan in your file system to see if you can find any other settings files, and if found, check their culture setting.
Another trick I've done is to stop merging in settings files at the solution root. This can be done by adding the following setting:
<GlobalSettings>
<StringProperty Name="MergeSettingsFiles">NoMerge</StringProperty>
</GlobalSettings>
This will ensure that StyleCop acts the same on all development and build machines, regardless of the settings configured higher up the hierarchy (such as the one in the StyleCop application folder). However if you do this, make sure you copy all the required settings from the files no longer being merged. From your description I doubt that this will solve this particular problem, but I have found it useful to help retain rule consistency.