We Keep Coding

Is there a way to modify the code entered by IntelliSense when using auto code completion in Visual Studio?

I want to modify the auto-fill code that Visual Studio/Intellisense enters in when I press tab or tab tab.
I have already tried searching in online forums and in the Microsoft documentation and I have not found a solution to what I am trying to achieve.
For example, when I type in "MessageBox.s" and press tab, it will auto complete with
MessageBox.Show
I would like to change it so that it will instead auto complete to
MessageBox.Show("");
This way I can save time by not having to type in the parenthesis, quotation marks and semicolon, which I am always going to use. Is there any way to do this in Visual Studio? I am using Visual Studio Community 2017. Or is there a third party add in I can use to customize the behavior?

I'm guessing you've already done that, but to edit the auto-complete / intellisense settings in visual studio 2010 you can go to Tools -> Options... -> TextEditor -> C# -> IntelliSense
I may not be answering your exact question but I think I can solve the underlying issue.
The problem you're trying to solve is typing less to write more, when what you're typing is very frequent.
What you're suggesting might exist (editing the auto complete), but what I use all the time is Live templates. I'm using Rider (not visual studio), so it might be called Snippets, but what it is is exactly what you're asking.
There are already existing examples that are very useful, for example, if you type cw then tab tab, it'll write a complete Console.WriteLine(); and place your cursor in the parentheses. You can even add variables and a lot of very useful stuff. Other default live templates are foreach + tab + tab, or for, or switch, you get the idea.
Anyway, search in your settings "live templates" (or snippets), and you can add as many as you want there. Then, for your case, you could just write mb tab tab and you'd be good to go ;)
I also suggest you look up how to customize these live templates with $VAR$, $SELECTION$ $END$ and so on, so you can maximize your efficiency with it.
Also, Happy new year \o/

The short answer: Yes... and no.
As I understand it, there are two different categories of auto-fill code in Visual Studio:
Code snippets. Blocks of code that are stored in files ending in .snippet.
Classes and their methods
The code snippets are in various places in the VS files (mine are in a quite different place than Schneider's). These are things like If statements, and the files can be opened and edited. You can find the folder/file locations in VS by going to Tools >Code Snippets Manager >CSharp >Visual C#. For me it was C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC#\Snippets\1033\Visual C#.
If you double click on one of the files you can open it in VS and edit the code, which is all XML. If you want to edit the code that fills in you look for a the part of the code with "CDATA":
<Code Language="csharp"><![CDATA[foreach ($type$ $identifier$ in $collection$)
{
$selected$ $end$
}]]>
You can read more into the details of the syntax in the Microsoft Documentation. But if you want to modify the other type of auto-fill stuff - classes and their methods from the built in libraries - as best as I can gather there is no way to do it; however, there is a workaround in creating your own custom snippets with "shortcuts". I found this page from Microsoft to be helpful in figuring out how to do it. There were a couple of things I had to do differently though compared to the documentation, so I will provide an explanation here using the MessageBox.Show example in C#.
Go to File >New >File
When the new file window pops up, select XML file.
Get rid of the default line of code and paste in the following code:
<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Header>
<Title>MessageBox.Show</Title>
<Shortcut>mess</Shortcut>
</Header>
<Snippet>
<References>
<Reference>
<Assembly>System.Windows.Forms.dll</Assembly>
</Reference>
</References>
<Imports>
<Import>
<Namespace>System.Windows.Forms</Namespace>
</Import>
</Imports>
<Code Language="CSharp">
<![CDATA[MessageBox.Show("");]]>
</Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>
The shortcut tag is what you will type in in your code project to trigger this snippet to come up as a suggestion. And what's in between the inner brackets after CDATA will be the code that auto-fills for you.
Save the file into your Documents folder (this is the default folder where VS will look later). Name the file MessageBoxShow.snippet
Now go into Tools >Code Snippets Manager
Select your language (Csharp), then click import
Navigate to the MessageBox.Snippet file you just saved a moment ago and double click it.
The Import Code Snippet dialog opens, asking you to choose where to add the snippet from the choices in the right pane. One of the choices should be My Code Snippets. Select it and click Finish
Click OK to close the code snippets manager.
You should now be able to type in "mess" and have your custom snippet code fill in. If not, you may try closing and reopening your project or VS. The Microsoft tutorial said you can add in the shortcut tag later, but I tried it that way and VS didn't pick it up, so I had to recreate the file with the shortcut tag in place then import it and it worked!
Of course you can essentially use this same method to create a snippet & shortcut for whatever you want. You just need to change the text in the title, shortcut, and code (CDATA) tags and save it under a different file name.
Thank you Peter Schneider and Gil Sand for your contributions. While you did not provide me with a direct solution to my question, you did help me to find what I was looking for.

Intellisense compiles the code in the background and autocompletes the properties, methods and so on. I guess you should take a look at code snippets and define one that fits your needs.
As starting point take a look at the snippets defined in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC#\Snippets\1033\Visual C#

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.

Applying xml transformation to app.manifest

I just inherited a c# application. It currently has an entry in it's app.manifest to enable UAC
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Every time I do a debug build it inside visual studio, I get prompted that "This task requires the application to have elevated permissions". (I have an admin account but I don't logon with it when developing.)
Is there a ways to either apply a xml transformation to it (like on web.configs) or making a app.manifest for release mode?

Using the SlowCheetah NuGet package and accompanying Extension you will get the same behavior on all xml files as you have for web.config.
Be sure to install/activate the NuGet package as well as the Visual Studio Extension. Also, there are a number of Slow Cheetah versions in NuGet - I would suggest using the latest that is released by Microsoft - Microsoft.VisualStudio.SlowCheetah.
Read more on this: https://github.com/Microsoft/slow-cheetah
Edit: I had a long struggle actually getting the transform to work for App.Manifest.xml for my sharepoint add-in project. Turns out the files created for you when you use "Add transform" lack some details that if not included will cause the transform to fail (give no result). This is what I concluded:
<!-- Mandatory block in AppManifest transform files: -->
<App xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform" xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
Name="Not transformed"
ProductID="{12345678-0000-0000-0000-123456789123}"
Version="0.0.0.0"
SharePointMinVersion="0.0.0.0"
>
<Properties>
<Title>Not transformed</Title>
<StartPage>Not transformed</StartPage>
</Properties>
<AppPrincipal>
<RemoteWebApplication ClientId="*" />
</AppPrincipal>
</App>
<!--
This block as it is written will cause no transformation whatsoever, but all elements above must be present for any transformation to be applied.
To transform an entire element along with its text content, add the attribute xdt:Transform="Replace" to the element. This will also replace all
child elements.
-->
Hope this is of help!

Why is this custom backstage UI for Word not displaying its user interface?

I have an Office addin which uses the following backstage XML to add custom UI elements into Microsoft Word backstage:
<?xml version="1.0" encoding="UTF-8"?>
<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui" onLoad="Ribbon_Load">
<backstage onShow="Backstage_OnShow">
<tab idMso="TabSave">
<firstColumn>
<taskFormGroup idMso="SaveGroup">
<category idMso="Save">
<task id="myCustomTask" label="My Custom Task" insertAfterMso="ButtonTaskDynamicServiceProvider">
<group id="myGroupInTabSave" label="Custom functionality" helperText="This group contains custom functionality.">
<primaryItem>
<button id="myButton" label="My Button" onAction="CallMe" />
</primaryItem>
</group>
</task>
</category>
</taskFormGroup>
</firstColumn>
</tab>
</backstage>
</customUI>
This is the exact base-case scenario described here to modify the Save As dialog.
On my machine, it does not show anything under Save As. I do however see that the following function gets called when the backstage is shown:
public void Backstage_OnShow(object contextObject) {
// It hits this method.
}
What are some of the reasons why the UI will not show, and also, how can I debug what is going on here? I tried turning on Show add-in user interface errors in the Advanced tab of Word Options, under the General section, but it doesn't display any errors to me, as far as I can tell.
Not sure if it helps, but our ribbon inherits IRibbonExtensibility.
We've also found this logic sometimes works on some machines but not on others. I am clueless as to why...one thing I can tell you that is definitely different is that the types for this addin are registered with regasm instead of the addin being installed using a path|vstolocal registry key under Outlook's registry. In other words, we are using regasm to install the addin.
Edit: I have tried the suggested answer but it is still not working given that approach. My team and I are pretty convinced at this point that this is a major VSTO bug and we have cooked up a project to showcase it. This project showcases backstage bugs with Windows 10 Pro 64-bit version 1607 (OS build 14393.351) and 32-bit Word 2016 16.0.7426.1009 (Office 2016 32-bit version 1610, build 7466.2023): https://github.com/Murdoctor/WordAddin1
If you run this sample on the same or similar environment, you can see that if you click the Home tab at the top of Word, you will see the button that is defined in https://github.com/Murdoctor/WordAddin1/blob/master/WordAddIn1/Ribbon1.xml, but, if you open up the backstage you don't see the sample tab that should be inserted after the info tab, TabInfo (this screenshot was taken with a release build run in debug mode directly from Visual Studio, and I can see the addin is registered up and everything as well):
The only thing that you will see is this (this is also proof the addin is running and registered to its local VSTO file):
Edit: This also affects Office 64-bit. I just installed Word 2016 16.0.7426.1009 (Office 2016 64-bit version 1610, build 7466.2023) thinking that changing to x64 might help, but I still experience the same issue on my machine.
Edit: This also affects today's release of Windows 10 Pro x64 version 1607, build 14393.447. Also, I have tried disabling all other addins, still the same thing.

This is a bug with Office. I can confirm in my environment, this worked again after updating Word manually with the November 8 update which came out yesterday. This update did not show up when I tried to search for updates in Windows 10, instead I had to install it this way:
Inside of Word, click File to open the backstage.
Click on the Update Options drop-down.
Select Update Now.
Once you update to Office version 1610, build 7466.2038, this bug goes away: