Tuesday, November 20, 2018

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.


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="" /> <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.


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.

Thursday, November 8, 2018

Save objects in Visual Studio for reuse later

One easy way to save an object while debugging in Visual Studio so that you can use it later for troubleshooting, or maybe use in LINQPad is to serialize the object to disk.

All the libraries you need are built into .NET and can be done in the Immediate Prompt in Visual Studio.

Save the Object to disk

string json = new System.Web.Script.Serialization.JavaScriptSerializer().Serialize(myObject);
System.IO.File.WriteAllText($@"c:\dev\{nameof(myObject)}.json", json);

Read the Object from disk

string json = System.IO.File.ReadAllText(@"c:\dev\myObject.json");
var company = new System.Web.Script.Serialization.JavaScriptSerializer().Deserialize<MyClass>(json);

The caveat to this is that you will need the MyClass available when you bring it back to life.You can also pass Object instead of MyClass if you don't have it.

Wednesday, August 22, 2018

Running IISExpress from the command line or Powershell

You don't need to open up Visual Studio just to run another project. You can run IISExpress via the command line instead.

Here is the same example, once for the command prompt and again for Powershell. The name of the site can be found in the applicationhost.config file. You'll see a <site> tag and the name attribute is the siteName. This is also the name that shows up in the system tray when you launch the site in Visual Studio itself.

You can use the system tray IIS Express icon to quit instances started using Powershell or command prompt. You can also type a the letter Q at the command prompt that gets spawned.

Command Prompt

"C:\Program Files (x86)\IIS Express\iisexpress.exe" /config:"C:\dev\MyMvcApp\.vs\config\applicationhost.config" /site:"MyMvcApp"

You'll need to tweak this to match your paths, etc.


$scriptDir = Split-Path $script:MyInvocation.MyCommand.Path

function Start-IisExpress($config, $siteName) {
    Start-Process -FilePath 'C:\Program Files (x86)\IIS Express\iisexpress.exe' -ArgumentList "/config:$config /site:$siteName"

Start-IisExpress -config "$scriptDir\.vs\config\applicationhost.config" -siteName: "MyMvcApp"

NOTE: This assumes that you have put this in a Powershell (.ps1) file and placed it next to your solution and more importantly that the .vs directory is in the same directory as the .ps1 file. If not, you'll need to adjust the path or hard code the full path.

Tuesday, June 19, 2018

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

Thursday, June 14, 2018

Testing XPath

If you write XPath it is helpful to have a quick way to test what you are doing. You can give it a try using an online tool XPathTestBed. This is pretty easy to use.

If you are doing XPath on page source you can use the Console built into Chrome or Firefox and get immediate results. Just F12 to get into the developer tools. Go to the Console, and enter the following to get all div tags for example.


Very useful and easy to use.

Monday, June 11, 2018

How to use Google to find unsecured web.configs

I can't believe how easy it is to find web.config that are not secured. Put this into Google and you will be amazed at what you will get back.

inurl:ftp inurl:web.config filetype:config


inurl:http inurl:web.config filetype:config

Imagine if any of them have passwords in them.

inurl:ftp inurl:web.config password


inurl:http inurl:web.config password

Wednesday, May 23, 2018

Angular - Creating a Component using Angular CLI

Install Angular CLI

If you don't have Angular CLI you will need to install it using npm

npm install -g @angular/cli


ng g c products/product-detail.component --flat

ng = Angular CLI
g = generate
c = component
--flat = no folder will be created

This will create 4 files:


It will update the file which will register the component in the app.module.ts:

It will also wire the components together putting some useful code in