Basic for setting up a new angular application

These are the basic steps involved in creating a new project in Angular 2.

Step 1 Initial setup

Install Node

Install TypeScript

Run the node command npm install -g typescript

Step 2 Create a new project

Here are 2 options from many for creating the new project

If using ASP.NET

  1. If you are using ASP.NET then there are SPA templates that can be used.  See
  2. Install templates with command dotnet new –install Microsoft.AspNetCore.SpaTemplates::* 
  3. Created new application
  4. Create empty folder and run node command dotnet new angular

If using Angular CLI

  1. Install Angular CLI – starter project from scratch npm install -g @angular/cli
  2. Be sure to be in the project’s parent folder
  3. Run command ng new ApplicationName
  4. >This will create a new folder with the name and it will install all the dependencies

Step 3 Install dependencies

npm install

Step 4 Build

ng Build

Step 5 Run

Run this command: npm start – same as npm run prod, ng serve, ng serve –e dev

Stop is ctrl-c



I had a task where I needed to add basic authorization to a soap call and I found that I couldn’t set the network credentials nor the authorization header.  In order to do this you have to create another class that inherits the proxy class and then override the GetWebRequest method.  Here is sample code:

using System;
using System.Net;
using System.Text;

namespace MyNamespace
    public class MyProxyOverride : TheProxy
        string _url = null;
        string _username = null;
        string _password = null;

        public MyProxyOverride(string url, string userName, string password)
            _url = url;
            _username = userName;
            _password = password;

        protected override System.Net.WebRequest GetWebRequest(Uri uri)
            var request = (HttpWebRequest)base.GetWebRequest(new Uri(_url));
            var netCredential = new NetworkCredential(_username, m__password);
            var networkCredentials = netCredential.GetCredential(new Uri(_url), "Basic");

            if (networkCredentials != null)
                byte[] credentialBuffer = new UTF8Encoding().GetBytes(
                networkCredentials.UserName + ":" +
                request.Headers["Authorization"] =
                "Basic " + Convert.ToBase64String(credentialBuffer);
                throw new ApplicationException("Missing authentication information.");
            return request;



Basic React Component Structure

Here is some sample code to create a basic react component


<div>import React from 'react';
import ReactDOM from 'react-dom';

class App extends React.Component {
return (
<HelloWorld />

class HelloWorld extends React.Component {
return (


<h2>Hello World</h2>



export default App</div>

<div>//or ReactDOM.render(<App />, document.getElementById('app'));</div>


Could not establish trust relationship for the SSL/TLS secure channel with authority

A frustrating issue I run into occasionally in calling web services on my Windows development machine is “Could not establish trust relationship for the SSL/TLS secure channel with authority”.  I usually have to think back and search on the internet how to fix it.

Certificates can be a little confusing and I’m one who just wants to do as little work as possible to get past irrelevant issues so I can get to what is important.  I know enough about certificates to use them and deploy them but I’m not an expert.  So what I have found works but there may be better solutions.

Anyway, here are a couple of ways I’ve resolved the issue.

First, if you just want to ignore all certificates and you don’t mind a hard-coded solution,  you can add this code to the client before calling the service: System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };

A second option is that you can use the manage certificates snap-in.  Navigate to the Personal\Certificates folder and copy the localhost certificate to the Trusted Root Certification Authorities\Certificates folder.



Type Sharing – Data Access Layer

To start off my “Code Structure” tag, I usually find developers create a big type library to hold all their types used across multiple libraries.  In my opinion, this violates the “Separation of Concerns” rule.

Another problem with this is developers tend to misuse the types and tightly couple code together such that a change to the type can potentially impact multiple areas.

For example, I’ve seen types meant for web service contracts used all the way down in the data access layer.

Another issue I’ve seen is types that have a ton of fields.  In many cases they have most of the fields in the corresponding database table.  By the way, I don’t necessarily believe that the types have to match the database table structure. 

I believe this issue is also what is described as the “God Class”.  Anyway one problem with this is that it can be confusing in code as to whether the objects of this type have been properly populated.  The default thinking should be it is always correctly populated by the data access layer but of course I’ve seen developers reuse a type and only partially populate the object.  They probably did this inadvertently from not thoroughly reviewing their code. 

So at least when coding in the data access layer and Update/Add APIs, I believe we should carefully select what fields are passed in.  All parameters and objects fields passed in should be assumed to be the exact values that will be stored in the database.

There are a few other issues with these “God Classes”.  One is type fields that are for calculations.  There is no good reason to pass these to the data access layer and cause confusion when reading the data access layer code.  Another issue is there is unnecessary payload being passed around.  And finally, the more fields you have to consider the more complex the API can be. 

Ideally, the data access Update/Add APIs should be simple processing of related data.

Code Structure

It’s impressive how much information there is on software development on the internet.  You don’t have to read books in order to develop applications.  It’s amazing how knowledgeable people are able the many programming languages and technical matters and how experienced they are.

But there is one thing I don’t see much of and that is how to organize code and projects.  And how to select the best third party libraries and solutions.

I have read many of the books and articles about the different ways you can solve problems.  There are all the different design patterns and architecture patterns.  Some of my favorites are

  1. Clean code
  2. Design Patterns – Elements of Reusable Object-Oriented Software.
  3. Refactoring To Patterns
  4. Patterns of Enterprise Application Architecture
  5. Patter-Oriented Software Architecture
  6. Refactoring

And I have some favorite Architecture Books

  1. Software Architecture In Practice
  2. Just Enough Software Architecture
  3. Software Architecture For Developers
  4. Documenting Software Architectures

And I luckily I read Code Complete back when I started my development career.

But there’s not much available on how to structure your projects and your libraries.  And what are the pros and cons of all the different ways that this has been done.

The most common structure I’ve experience is the multi-layer pattern.  It seems to be the most suitable and encourages “Solid Code”.

Anyway, when I have some special insight, I’ll be sharing my thoughts as to what seem to be best practices to me in organizing and structuring code.