We recently had some trouble with AppVeyor, running post-deployment actions after web projects are deployed on our Deployment Agent servers. A good example of this is that I wanted to go ahead and warm up an ASP.NET site after a Deployment Agent finishes deploying the web package. (Why should a user be the first one to wait for ASP.NET to spin up, right?)

AppVeyor has great pre-deployment and post-deployment script support built in. But "post-deployment" to AppVeyor means something completely different when using a Deployment Agent; it really means after the deployment agent job has been queued.

To actually run post-deployment actions on the server that did the deploying, a deploy.ps1 PowerShell script has to be in the root project folder of the deployed web package. See http://www.appveyor.com/docs/deployment/agent#running-powershell-scripts-on-target-server-during-deployment for that.

To get it into the web package, MSBuild has to build it into the web package. For MSBuild to do that, it has to be a part of your project. This means that you would have to add a deploy.ps1 file to your project root in your Visual Studio project. That's great, but it's a bad mix of deployment dependencies and application code. No bueno. And, sometimes you don't control the project, so this must be done during the build process - within AppVeyor.

So, here's my current solution (until AppVeyor supports this as a feature):


This PowerShell script, when run like so...

deploy-script-inject.ps1 -scriptUrl http://something.com/mydeployscript.ps1

... will do the following:

  1. Download the post-deployment script from the -scriptUrl address.
  2. Search for all *.csproj and *.vbproj files recursively in the current folder.
  3. Write post-deployment script as deploy.ps1 to the project's root folder.
  4. Modify the Visual Studio project XML to include the deploy.ps1 file.

After that, it will be carried through to the web deployment package, and AppVeyor's Deployment Agent will see it and run it post-deployment.

To put it all together, add the following lines to an AppVeyor "Before Build Script":

appveyor DownloadFile https://raw.githubusercontent.com/BrandonPotter/AppveyorDeployScriptInjection/master/deploy-script-inject.ps1 -FileName .\deploy-script-inject.ps1

powershell ".\deploy-script-inject.ps1 -scriptUrl YOUR_DEPLOY_SCRIPT_URL_HERE"

That's it - AppVeyor deployment script injection into Visual Studio projects at build time.



The folks developing SharpDX do a fantastic job of a .NET Managed DirectX layer. I’m an impatient person, and I think XBox Controllers are awesome input devices. So, here’s a library available as a NuGet package that builds upon SharpDX and boils it down to super-simple code; scientific studies have shown that the average developer can now use an XBox Controller in under 60 seconds.

Like, if you wanted to find out if Button A was pressed on the first connected controller:

var myController = BrandonPotter.XBox.XBoxController.GetConnectedControllers().FirstOrDefault();
if (myController.ButtonAPressed)
// do something if button A is pressed

Now that I teased you, go get it off NuGet here:


… or go fork it and improve it here:


But wait, there’s more. XBox controllers are tricky. This little library addresses the following common issues when dealing with them…

Percentages instead of raw values – In reality, the thumb pads have values between –32,767 to +32,768. The triggers have values of 0 to 65,000. For all practical purposes, these are pretty meaningless, so these types of ranges are converted to percentages (as a double with crazy precisions). When each thumb pad is at its center position, this is 50% X / 50% Y. So from here on out, we’re going to be talking percentages, mmkay?

Trigger On/Off – Left and right triggers (the little, well, triggers that resemble the trigger of a gun) on the front of the controller) are, in reality, never actually “on” or “off”, they’re in between 0-100%. However, you may notice that the XBoxController class has two boolean properties called TriggerLeftPressed andTriggerRightPressed. These are inferred based on the current trigger percentage value, and two more properties (TriggerLeftPressThreshold / TriggerRightPressThreshold), which define the minimum percentage values the trigger needs to meet in order to be considered pressed. Defaults to 10%, as I found this was a pretty comfortable place to consider it “pressed”.

Dead Zone – The thumb pads do have springs to snap them back to “center”. However, with 65,535 positions on each axis, rarely will “center” ever mean the same thing twice. If you’re counting on 50/50 being “no thumb on the thumbpad”, this will drive you insane. So, I needed some kind of a ‘dead zone’ to go ahead and assume 50/50 when it’s in the “close enough to be considered the center” area. Through sheer trial and error I determined that a reliable center is anywhere from a 40% to 60% position. If you want this to be more or less sensitive, just set theSnapDeadZoneTolerance property. The tolerance is the percentage value that we consider to be in the “dead zone” on either side of 50%. So, for a Dead Zone Tolerance of 10, this means “10% on either side of 50%”, so 40% – 60%. A tolerance of 5 would mean the dead zone is between 55% – 65%, and of course a tolerance of 0 would disable the assumed dead zone.

Controller Polling / Refresh – To get new controller state information, we have to poll the XBox Controller. This little library will handle it automatically, so you can just grab properties and go. By default, this will poll the device a maximum of every 30 milliseconds. This felt comfortable to me, but if you need faster or slower polling, just adjust the RefreshIntervalMilliseconds property.

Controller Connect/Disconnect – At some point, your user will disconnect the controller while your application is using it; nothing should crash, and the controller’s IsConnected property should return false once it’s disconnected with no blow ups. Reconnection happens automagically.

Vibration Motors – The XBox Controller has 2 vibration motors, a left and right. The left motor (let’s call it “the big vibrations”), when set to 100%, will send your XBox controller walking across whatever surface it’s on. The right motor resembles what’s in your cell phone. You can set the motors (again, with percentages here) by calling SetLeftMotorVibrationSpeed() and SetRightMotorVibrationSpeed().

That’s about it. If you use this library and there’s anything I have forgotten, I’d love to hear. Happy coding!