dealproc

Depends on using BouncyCastle nuget package for the certificate generation.

dealproc

// Would be best to store this in ~/Scripts/durandal/plugins for convenience.
// This is so that when you must download a file from the web, via WebAPI with an OAuth2 token, you can validate yourself to the Api.
// This has been tested with small-ish files, but has not been tested with larger files, like installers.  Please offer contributions
// back for those items.
define(["durandal/system", "durandal/app"], function (system, app) {
    var defaults = {
        url: "", // to be provided by end user.
        method: "GET",
        mimeType: "application/octet-stream",
        filename: "download.bin",

dealproc

# These are project build parameters in TeamCity
# Depending on the branch, we will use different major/minor versions
$majorMinorVersionMaster = "%system.MajorMinorVersion.Master%"
$majorMinorVersionDevelop = "%system.MajorMinorVersion.Develop%"
$assemblyVersion = ""

# TeamCity's auto-incrementing build counter; ensures each build is unique
$buildCounter = "%build.counter%" 

# This gets the name of the current Git branch. 

dealproc

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Test"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <UsingTask AssemblyFile="$(SolutionDir)packages\xunit.runner.msbuild.2.0.0\build\portable-net45+win+wpa81+wp80+monotouch+monoandroid+Xamarin.iOS\xunit.runner.msbuild.dll"
             TaskName="Xunit.Runner.MSBuild.xunit" />
  <ItemGroup>
    <TestAssemblies Include="**/*.Tests.dll;**/*.IntegrationTests.dll" Exclude="**/obj/**;**/*IntegrationTests*;" />
  </ItemGroup>

  <Target Name="Test">

dealproc

I'm trying to figure out how to describe the issue of what everyone calls a CRUD application, and subsequently start to explain why a CRUD app isn't about CRUD, since those screens need validation involved in them more than most developers understand.

Let's look at the acronym, CRUD:

• C - Create (Insert) values inside the database
• R - Read (Select) values from the database
• U - Update (Update ) values inside the database
• D - Delete (Delete ) values from existence

This gives a 1-1 relationship between a users actions and what we do in the database. We're either inserting data (create/insert), displaying those values that we just created (read/select), updating values that exist (update), and when we no longer need the data, we're deleting the data (delete). The hard part with this notion is that in the real world, this is never the case. To support this theory, we should look at one of the most widely accepted CRUD applications that exist out there... a CRM

dealproc

    using System;
    using System.Collections.Generic;
    using System.Diagnostics;
    using System.Linq;
    using System.Reflection;

    using ServiceStack.Net30.Collections.Concurrent;

    /// <summary>
    /// Helper class redirects events to private Apply(event) method

dealproc

using System;
using System.Reflection;

using CommonDomain;
using CommonDomain.Core;
using CommonDomain.Persistence;
using CommonDomain.Persistence.EventStore;

using NEventStore;
using NEventStore.Dispatcher;

dealproc

if (!$MainDB) {
	$MainDB = '...';
}

tools\migrate.exe --task migrate --connection "$MainDB" --provider "SqlServer2012" --assembly "lib\net45\Adapt.Gift.DatabaseScripts.dll" --tps

dealproc

using System;
using System.Linq.Expressions;
using System.Reflection;
using Xunit;
namespace ReflectedConstructor {
    public static class MemberExpressions {
        public static MemberInfo GetMemberInfo(this Expression expression) {
            var lambda = (LambdaExpression)expression;

            MemberExpression memberExpression;

dealproc

namespace {Product}.Infrastructure.Framework {
	using FluentValidation;
	using FluentValidation.Results;
	using System;
	using System.Text;
	public static class ValidationHelper {
		public static ValidationResult Validate<T, K>(K entity)
			where T : IValidator<K>, new()
			where K : class {
			IValidator<K> __Validator = new T();