How it works is that for every purchase made at Amazon by first clicking through on the link at purchase4charity.org will add 5% of the revenue to the fund that will be donated to charity by the end of each month.

So instead of buying that polo for $100 at amazon.com you can still buy it for $100 at amazon.com only that $5 of that $100 will be donated to charity!

So what are you waiting for?

So I whipped something up over at brogrammers.org

All you brogrammers “and aspiring brogrammers”, keep it real or keep it HARD. peace out.

Why you want to do this is because you cannot run both IIS and TeamCity on port 80 but you would like to access TeamCity on port 80

1. TeamCity

Download and install TeamCity, set it to run at port 8080 and make sure it is up and running on http://localhost:8080

2. Application Request Routing

Download and install ARR from http://www.iis.net/download/applicationrequestrouting

3. Create a Server Farm

There should be a new node in your IIS beneath “Sites” named “Server Farms”

- Right click on that node and choose “Create Server Farm”.

- Choose a name for the farm (ex “TeamCity”) and click next.

- Enter “localhost” in the server address box.

- Click “Advanced settings…”, expand “applicationRequestRouting” and change the httpPort to 8080.

- Click Finish.

4. Configure Server Farm Routing

- Expand “Server Farms” and select your newly created Farm node.

- Double click on “Routing Rules”

- Click “URL Rewrite…” beneath “Advanced Routing” on the right.

- Double click on the single folder beneath Inbound rules.

- Set the top “Match URL” to Regular Expression and the Pattern to “.*”

- Expand “Conditions” and add “input={HTTP_HOST},Type=Matches the Pattern, Pattern=teamcity.internal-server.com”

- Click “Apply”

5. Done!

You should now be able to access TeamCity trough IIS7 via the url http://teamcity.internal-server.com/login.html

In this movie there are people who have realized how they are controlled by the system and has broken free. They liberate others and offer them a choice, either take the blue pill and continue to live out their lives in ignorance or take the red pill, live in the real world and help change it into a better place.

IPV4/V6: says who we are

Whenever you connect to the internet you connect trough a Internet Service Provider (ISP). As you do so you are assigned a unique IP address either randomly or static. If you have been assigned a IPV4 address it would look something like this: 209.85.148.106.

This is not very readable for humans and a IPV6 (2001:0db8:85a3:0000:0000:8a2e:0370:7334) is even worse!

We could bypass ISP by building a decentralized network of WIFI nodes where each node is connected to one or more node in the network and each node may have zero or more users connected to it by WIFI. All users connected to this network would be able to communicate with eachother and if any node in the network would be connected to the internet, every one would have access to it.

A node in this network could be a dekstop, laptop or whatever computer with WIFI enabled and the right software. You could build one using a £35 Bifferboard, just add a WIFI dongle and some software.

DNS: controls who we are

The solution is to map a IP address to something more readable, instead of printing 209.85.148.106 on your business cards you can print www.google.com

So it is basically the same idea that your social security number is a unique identifier for you as a individual but your name is how you are known to others.

How this mapping is done today is via the DNS system, if you register www.something.com and point it to 127.0.0.1 this is registered in the root DNS system managed by IANA and then replicated across other DNS nodes like the ones managed by your ISP.

This must mean that whoever is in a position to excerpt control over IANA basically has the power to census the internet on a fundamental level.

Last I checked IANA is managed by ICANN that is based in the USA which means that the operate beneath said nations set of laws (and whatever state). This in turn means that control over all domains in the world rests with one nation and relies on their good will.

There are already ideas on how to leave DNS and instead use a decentralized system where there are no ownership of domains, instead you are who the majority agrees upon you are.

Certificate Authority: provides basic security, for a price

A SSL certificate basically provides you with two things.

1. Authentication: wheres the certificate certifies to your visitor that you are who you claim to be.
2. Integrity: wheres the traffic between you and the client is encrypted

A Certificate Authority is whoever sells you the certificate, browser maintains a list of CA’s so whenever you navigate to a website with https it verifies the website certificate against said list. If you want to secure your website with a certificate be prepared that you may pay a hefty price. Why it is so expensive is because they can.

There is no way to just enable encrypted traffic without registering with a CA (or make it difficult to use your service) which in turn means that our integrity was never a priority when they laid the foundation of the the internet. I like to think about how we time and time again fail to measure something like time, eventually we just give up, make odd/even numbers of days for each month and throw in leap years just to keep everything from falling apart. I feel the same way about the fundamentals of the world wide web.

DNS and CA is the glue of the world wide web and also the whip & chain used to moderate it. In a decentralized name lookup system, certificates could be used to verify authenticity of the service if needed. A non profit CA could be established to ensure security and integrity for all.

In the movie “The Matrix” there are individuals that know all about how they are used by the machines but still they want to go back into the virtual world and forget. I believe this behavior is the same with internet users, why change something that works and why should we care as long as I can check Facebook every now and then?

What is the matrix you ask? you are looking at it right now.

How can we cover this in our automatic deployment setup?

The goal is to never use SQL Management Studio during development and instead rely on updating version controlled .sql files and let these make updates to the database during deployment.

This post covers how to export Microsoft SQL Server stored procedures, adding them to our solution, managing schema updates and deploying changes using Phantom with MSDeploy

1. Add to version control

First we needed to export all store procedures from our database and add them as .sql script files to our solution project. This way they can be version controlled together with our project and later be used to update any target database when we make a deploy.

1. Right click the database
2. Choose Tasks
3. Generate Scripts
4. Click Next
5. Select specific database objects
6. Select all stored procedures
7. Click Next
8. Select “Single file per object”
9. Advanced > select “Include if NOT EXISTS”
10. Advanced > select “Script DROP and CREATE”
11. Advanced > deselect “Script USE DATABASE”
12. Choose where to dump the .sql files
13. Click Next
14. Click Next
15. Done!

Add the .sql files to your solution. The sync.sql is where we keep all the schema updates.

-- Example sync.sql

-- 2011-05-03 : Added author to Article
--
if not exists (select 1 from INFORMATION_SCHEMA.columns where table_name = 'Articles' and column_name = 'Author')
	alter table [Articles] add [Author] [nvarchar](255) NULL

-- 2011-03-26 : Added Date to Source
--
if not exists (select 1 from INFORMATION_SCHEMA.columns where table_name = 'Sources' and column_name = 'Date')
begin
	alter table [Sources] add [Date] [datetime] NOT NULL
        alter table [Sources] add constraint [DF_Sources_Date]  DEFAULT (getdate()) for [Date]
end

2. Modify deploy procedure

We need to add steps to our deploy process where these script files are executed towards our deploy targets. Since we are using Phantom I added something like the following to our build.boo script. The reason why I chose to combine all .sql files into one big one was because it takes a very long time to execute 50+ such files one by one using MSDeploy.

//file: build.boo

import System.IO

solution_file = "./example.sln"
configuration = "release"
output_path = "./output"
sql_file_path = "c:/tmp/bigfile.sql"

target default, (build, clean):
  pass

target build:
  msbuild(file: solution_file, configuration: configuration, properties: {"OutputPath": output_path})

target deploy, (build, deploy_codebase_to_some_machine, update_sql, clean):
  pass

target deploy_codebase_to_some_machine:
  ..deploy stuff <snip>

desc "combine all .sql files into one big one"
target build_sql_script:
	file = File.Open(sql_file_path,FileMode.Create)
	writer = StreamWriter(file)
	with FileList("./.sql"):
		.Flatten(true)
		.Include("**/*.sql")
		.ForEach def(file):
			writer.Write("\n\n")
			writer.Write(File.ReadAllText(file.FullName))
	writer.Close()

target update_sql, (build_sql_script):
	msdeploy(verb:"sync", source: {"dbFullSql":sql_file_path}, dest: {"dbFullSql":"data source=127.0.0.2;initial catalog=Hermes;password=god!secure;persist security info=True;user id=admin;packet size=4096"})

target clean:
  rm(output_path)
  rm(sql_file_path)

3. Invoke

This script can be used to perform a deploy, complete with schema updates and stored procedures by invoking:

phantom.exe deploy

- or to only update schema and stored procedures:

phantom.exe update_sql

All that is left is to add this to the build server, add some triggers and you are all set. good luck!

Oh! lets me count the ways!

When I work I use the browsers in the following way

1. Chrome for gathering information and leisure browsing
2. Firefox for development (firebug)
3. IE to see if it fucks everything up or not
4. Safari, rarely

The first part was to be able to install or uninstall a .NET Windows service using InstallerTool.exe in the following way:

Install   >> InstallerTool.exe /name=MyService /account=user /user=domain\username /password=password ./service.exe
Uninstall >> InstallerTool.exe /u /name=MyService ./service.exe

To do this without needing to manually enter credentials in a popup window I needed to modify my installer class. In order for it to accept credentials and stuff from the command line parameters I added the following to my installer.

protected override void OnBeforeInstall(IDictionary savedState)
{
	base.OnBeforeInstall(savedState);

	this.processInstaller = this.processInstaller ?? new ServiceProcessInstaller();
	this.serviceInstaller = this.serviceInstaller ?? new ServiceInstaller();

	this.serviceInstaller.ServiceName = string.IsNullOrEmpty(GetContextParameter("name")) ? this.serviceInstaller.ServiceName : GetContextParameter("name");
	this.serviceInstaller.Description = string.IsNullOrEmpty(GetContextParameter("desc")) ? this.serviceInstaller.Description : GetContextParameter("desc");

	switch (GetContextParameter("account").ToLower())
	{
		case "user":
			this.processInstaller.Account = ServiceAccount.User;
			this.serviceInstaller.Username = string.IsNullOrEmpty(GetContextParameter("user")) ? this.serviceInstaller.Username : GetContextParameter("user");
			this.serviceInstaller.Password = string.IsNullOrEmpty(GetContextParameter("password")) ? this.serviceInstaller.Password : GetContextParameter("password");
			break;
		case "localservice":
			this.processInstaller.Account = ServiceAccount.LocalService;
			break;
		case "localsystem":
			this.processInstaller.Account = ServiceAccount.LocalSystem;
			break;
		case "networkservice":
			this.processInstaller.Account = ServiceAccount.NetworkService;
			break;
	}
}

protected override void OnBeforeUninstall(IDictionary savedState)
{
	base.OnBeforeUninstall(savedState);
	this.serviceInstaller.ServiceName = string.IsNullOrEmpty(GetContextParameter("name")) ? this.serviceInstaller.ServiceName : GetContextParameter("name");
}

private string GetContextParameter(string key)
{
	return Context.Parameters.ContainsKey(key) ? Context.Parameters[key] : string.Empty;
}

I am using my Phantom fork on Github that adds a wrapper for MSDeploy.exe

In this example InstallUtil.exe is deployed together with my service to the remote machine in the folder “./installer/installUtil.exe”

Example script usage:

deploy             >> pantom.exe build deploy clean
deploy & install   >> pantom.exe build deploy install clean
deploy & uninstall >> pantom.exe build deploy uninstall clean

# file: build.boo
# deploys and install or uninstalls services on a remote machine
solution_file = "./solution.sln"
configuration = "release"
output_path = "./phantom.build"

remote_path="E:/Services/service"
remote_installer = deploy_path+"/installer/installUtil.exe"
remote_server = "127.0.0.1"
remote_username = "admin"
remote_password = "god!secure"
remote_uninstall_cmd = remote_installer_path+" /u /name=MyService "+deploy_path+"/service.exe"
remote_install_cmd = remote_installer_path+" /name=MyService /account=user /user=domain\\username /password=password "+deploy_path+"/service.exe"

target default, (build, clean):
pass

target build:
msbuild(file: solution_file, configuration: configuration, properties: {"OutputPath": output_path })

target deploy:
msdeploy(verb: "sync",source:{"dirPath": output_path}, dest: {"dirPath":remote_path,"wmsvc":remote_server,"authType":"basic","userName":remote_username,"password":remote_password},flags:"-allowUntrusted")

target uninstall:
msdeploy(verb: "sync", source:{"runCommand":remote_uninstall_cmd}, dest: {"auto":"","wmsvc":remote_server,"authType":"basic","userName":deploy_username,"password":deploy_password},flags:"-allowUntrusted")

target install:
msdeploy(verb: "sync", source:{"runCommand":remote_install_cmd}, dest: {"auto":"","wmsvc":remote_server,"authType":"basic","userName":remote_username,"password":remote_password},flags:"-allowUntrusted")

target clean:
rm(output_path)

You may need to add some privileges to the WMSVC service running on the remote machine

c:\> sc privs wmsvc SeChangeNotifyPrivilege/SeImpersonatePrivilege/SeAssignPrimaryTokenPrivilege/SeIncreaseQuotaPrivilege
c:\> sc stop wmsvc
c:\> sc start wmsvc

Because they are basically the same configuration files but with different settings, like pointing on different databases or enable/disable debug stuff.

Using my recent Github fork of Phantom I am now able to do this:

1. Deploy a website/application using MSDeploy
2. Backup an existing website/application before deploying, also using MSDeploy
3. Version control configuration files and deploy the correct set to a given environment

The following build.boo show how to configure  backups,  configuration files and deploy targets for the same solution.

this script assumes that there is a directory named “.configurations” in the solution directory and that it contains two sub folders named “staging” and “production”

solution_file = "solution.sln"
configuration = "release"

output_path = "./.output"
published_web_path = output_path + "/_PublishedWebsites/website"
package_path = output_path+"/deploy_package"

remote_backup_folder = "{path on remote machine}/some_name_["+System.Environment.MachineName +"]_"+ date.Now.ToString("yyyy.MM.dd.hh.mm.ss")

msdeploy_authentication_staging = ",wmsvc=\"127.0.0.1\",authType=\"basic\",userName=\"admin\",password=\"god!secure\""
msdeploy_authentication_production = ",wmsvc=\"127.0.0.2\",authType=\"basic\",userName=\"admin\",password=\"god!more!secure\""

target default, (build, clean):
  pass

target build:
  msbuild(file: solution_file, configuration: configuration, properties: {"OutputPath": output_path })

target package:
  rm(package_path)
  with FileList(published_web_path):
    .Exclude("{*.config, *.txt}")
    .ForEach def(file):
      file.CopyToDirectory(package_path)

target deploy_to_staging, (clean, build, package, backup_staging, clean):

	with FileList("./.configurations/staging/"):
		.Include("**")
		.ForEach def(file):
			file.CopyToDirectory(package_path)

	msdeploy(skipfiles: (".*\\.bak",".*\\.txt"), verb: "sync", source: "iisApp="+package_path, dest: "iisApp=\"Default Website\""+msdeploy_authentication_staging)

target deploy_to_production, (clean, build, package, backup_production, clean):

	with FileList("./.configurations/production/"):
		.Include("**")
		.ForEach def(file):
			file.CopyToDirectory(package_path)

	msdeploy(skipfiles: (".*\\.bak",".*\\.txt"), verb: "sync", source: "iisApp="+package_path, dest: "iisApp=\"Default Website\""+msdeploy_authentication_production )

target backup_staging:
	msdeploy(verb: "sync", source: "iisApp=\"Default Website\""+msdeploy_authentication_staging, dest: "archivedir=\""+remote_backup_folder+"\"+msdeploy_authentication_staging)

target backup_production:
	msdeploy(verb: "sync", source: "iisApp=\"Default Website\""+msdeploy_authentication_production , dest: "archivedir=\""+remote_backup_folder+"\"+msdeploy_authentication_production )

target clean:
  rm(output_path)

Example usage:

• “Phantom.exe deploy_to_staging” : builds, makes a backup, configures and deploys
• “Phantom.exe deploy_to_production” : builds, makes a backup, configures and deploys

I recently forked it on github as I wanted to add support for aspnet_compiler.exe and msdeploy.exe for use in one of our bigger projects.

These are just two simple wrappers for msdeploy.exe and aspnet_compiler.exe - basic and crude, but they do work.

With these in my build.boo script I can make a deploy simply by calling “Phantom.exe build publish deploy”

Nothing left but to set it up in Team City with the appropriate triggers

The next step I guess is to throw in the updating of configuration files.

solution_file = "./solution.sln"
configuration = "release"

output_path = "./.output/solution.build"
publish_path = output_path+"/published.solution"

deploy_src = "iisApp=\""+publish_path+"\""
deploy_dest_test = "iisApp=\"website/application\",wmsvc=\"127.0.0.1\",authType=\"basic\",userName=\"admin\",password=\"god\" -allowUntrusted"
deploy_dest_stage = "iisApp=\"website/application\",wmsvc=\"127.0.0.2\",authType=\"basic\",userName=\"admin\",password=\"god!secure\" -allowUntrusted"

target default, (build, clean):
  pass

target build:
  msbuild(file: solution_file, configuration: configuration, properties: {"OutputPath": output_path, "TrackFileAccess": false})

target publish:
  aspnetcompiler(physicalpath: "./", virtualpath: "App", targetpath: publish_path)

target deploy, (deploy_test):
  pass

target deploy_test:
  msdeploy(skipfiles: (".*\\.config",".*\\.txt"),verb: "sync", source: deploy_src, dest: deploy_dest_test)

target deploy_stage:
  msdeploy(skipfiles: (".*\\.config",".*\\.txt"),verb: "sync", source: deploy_src, dest: deploy_dest_stage)  

target clean:
  rm(output_path)