Keeping Secrets out of the web.config

See here for Microsofts official recommendations on best practices to keep secrets out of the web config.

I am mostly concerned about appSettings and connectionStrings sections in the web.config

The Microsoft article says everything I am going to say below, but they are some important points to consider.

appSettings

To keep your appSettings secret, put them in another file that is not checked into source control. The contents of this file will be merged with what is in the web.config so this works well to allow developers to override values in appSettings.

The syntax is basically

<appSettings file="..\..\AppSettingsSecrets.config"> <add key="webpages:Version" value="3.0.0.0" /> <add key="webpages:Enabled" value="false" /> <add key="ClientValidationEnabled" value="true" /> <add key="UnobtrusiveJavaScriptEnabled" value="true" /> </appSettings>

The file attribute accepts paths that are relative or absolve and the file does not have to exist. This is useful when deploying to different environments that may not use this file and instead use VSTS / replacing of tokens to manage values per environment.

connectionStrings

The connectionStrings section isn't as nice as the appSettings. The tags between connectionString tags are replaced by the contents of the external file. The file referenced MUST be in the same directory as the web.config that is referencing it. This means the secret file is per project. The other thing that makes it not work as easily is that it MUST exist otherwise you will get a build error because the project file will try to find the file. You can edit the project file and tell it to only include the file in the project for particular environments, but that is tedious and must be done on each project file.

Fixing build issues

It can be hard to work out exactly where the problem is via visual studio directly. You can use the following to leverage msbuild and get more accurate information.

From a  cmd prompt run:

msbuild /verbosity:d > build.txt

Customizing Code Coverage in VS2015

The code coverage in Visual Studio 2015 by default includes the test code itself. This is often not desired. Below are some links go pages to help with this.

Customizing Code Coverage Analysis
Using Code Coverage to Determine How Much Code is being Tested
Troubleshooting Code Coverage
Troubleshooting missing data in Code Coverage Results

My conclusion is that the default settings that comes Visual Studio 2015 is not sufficient because it includes the test code in the test results. I found the .runsettings file to be a necessary change. When I did this, I was tempted to exclude test assemblies to the list of modules to exclude, but found this actually stopped the tests from being reported on. Instead I found it better to use namespace exclusions using the function tags.

For example,

   <Functions>
              <Exclude>
                <!--Exclude (Tests from the results) any functions in namespaces that have Test in them-->
                <Function>.*Test.*</Function>

I also found it useful to exclude tests (classes or methods) from the code coverage results that use particular attributes on them. For example,

 <Attributes>
              <Exclude>
                <!--Don't forget "Attribute" at the end of the name -->
                
                                <Attribute>^Microsoft\.VisualStudio\.TestTools\.UnitTesting\.TestClassAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.GivenAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.WhenAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.ThenAttribute$</Attribute>


I did however add any assemblies that have their own unit tests and code coverage reports to the list of modules to exclude. That way the code coverage of these assemblies is not counted twice.

The rest of the .runsettings file can be just as the sample file from MS.
Also, Here is a reporting tool that helps show code coverage results in a more user friendly manner.

How to have TFS version control not ignore .DLL and .EXE in the packages directory.

If you are not using Visual Studio to refresh your Nuget packages then you need to check them in to source control. In my case this is the version control in TFS. To solve the problem you just need to add a .tfignore file to the packages directory.

The easiest way to do this is to create a new .txt file in the packages directory and call it ".tfignore.". Notice it starts and ends with the period. The last period will be removed automatically and you will be left with a file called ".tfignore".

You can also use notepad.exe to create the file. The trick with this is to change the type to All File and just type the name ".tfignore".

Once you have a file created open it in notepad and add the following lines to it.

!*.exe
!*.dll

The ! tell the source control to NOT ignore the files with these extension.

Modelling project gives warnings when Unity is used.

The issue as reported here and copied / summarized below:

I am using Visual Studio Enterprise 2015 and tried to create a layer diagram in order to generate and validate dependencies. But this fails because VS is throwing warnings while building the modeling project:

CurrentVersion.targets(1819,5): warning MSB3268: The primary reference "...\ClassLibrary4\bin\Debug\ClassLibrary4.dll" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "...\ClassLibrary4\bin\Debug\ClassLibrary4.dll" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".

I figured out that if you remove Unity the warnings are gone and dependencies are shown as expected.

What is the reason for this behavior and is there any workaround?

I tried the Unity prerelease package and also another targeting frameworks. No effect at all. The issue is reproducable with a new project after adding a modelling project and using unity in one referenced projects.

The solution that worked for me as well:

The problem that VS2015 was compiling the modelling project using the wrong target framework (4.0):

Task Parameter:TargetFrameworkDirectories=C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0

There is no TargetFrameworkVersion in the project file of the modelling project (*.modelproj). But after adding it to the first property group it is compiling and validating as expected. Without any warnings.

Solution:

1. Unload the modelling project
2. Right Click -> Open *.modelproj
3. Add the following line in between the first PropertyGroup open / close tags.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

NOTE: Replace v4.5 with your target framework (the target framework for your application)

After your done, your project file will start with something like this:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{f60f6f86-e1d5-4d33-b8ed-0bf2172780cf}</ProjectGuid>
    <ArchitectureToolsVersion>2.0.0.0</ArchitectureToolsVersion>
    <Name>ModelingProject1</Name>
    <RootNamespace>ModelingProject1</RootNamespace>
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
    <ValidateArchitecture>true</ValidateArchitecture>
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
  </PropertyGroup>
...