If you change VS to use the dark theme, the provider icons don't look very good. If you look at the Single Page provider icon it has two issues. 1. It is very difficult to see as the black border of the transparent page blends in with the background. 2. It has a light 1 pixel wide line on the right edge of the icon.

Provider authors will likely not know how to do custom themes without some initial guidance.
They will likely just apply their own style to the controls in their Views, losing the default theming. Without a sample, they will likely just brute force duplicate the themes, possibly even for dark and blue themes

This is a sample for how to use the ~12 controls that have common themes, and make a customization on our common themes

The XAML designer uses default constructors on types to provide intellisense, and WYSIWYG support.

In our samples, and providers, we make use of the ConnectedServiceProviderContext as a context, passed in. This is used in the constructors. With this pattern, the default constructor is only used for the designer and makes the code look strange, and coding confusing as it surfaces a designer requirement to add the parameterless constructor, but has no provider author value.

Context is a valuable property, used in most providers, and should be added to the base classes, set for the provider author, so there's less to worry about.

Proposal:
Add ConnectedServiceProviderContext to ConnectedServiceConfigurator
In ConnectedServiceProvider, when CreateConfiguratorAsync is called, set the ConnectedServiceProviderContext for the provider author, so they get the value, without having to write the code, and break the XAML designer

• Action is to update the samples to set the context externally, and leave the parameterless constructor for the XAML designer

The resource:
VsResourceKeys.ThemedDialogTextBoxStyleKey
mentioned here in the SDK:
https://github.com/Microsoft/ConnectedServices/blob/master/SDK/articles/ModifyingWPFStyles.md
is not present in the Microsoft.VisualStudio.Shell14 library.

We have a reference implementation of using T4 templates within the Salesforce connected service. However, Salesforce tends to be a bit complicated to grock smaller concepts.
This would show how to use T4 templates, including a common reference location allowing the service to be updated without overriding customizations.
Alternatively, if the reference implementation in Salesforce is what we should convey, then perhaps an article in https://github.com/Microsoft/ConnectedServices/tree/master/SDK/articles

If your Connected Service supports more than one handler, and the questions may vary based on the current project, you'll likely want to ask the questions relevant to the specific project, or even some details related to the project. For instance, in the Azure Active Directory Connected Service, the developer is prompted different whether the project support is considered a WebAPI or MVC project. In the Salesforce case, the developer is prompted for Web Server Flow authentication in a Web App. If the project were a WinForms or Console App, it should hide that option. In the Azure Active Directory case, this was implemented, however as of Visual Studio 2015 RTM, we had not yet implemented the project detection.

Issue is to create a sample## for detecting the project type, Showing/Hiding a WizardPage or WPF element, or simply disabling an option based on the current project type.