Category Archives: microsoft

chocolatey package update quick reference

gingerbread2011_18

Chocolatey rocks when it comes to updating a bunch of installed software from the command line. If you’re not doing that often however it can be hard to remember exactly what commands you can use to do that quickly. So here’s a little run-down on the most helpful commands when you are updating your system.

First you might want to check what’s installed on your machine.
You can get the list of the local package Chocolatey installed like this:

chocolatey list -localonly

or in short:

clist -localonly

To check if any package have updates available, we can run the update all statement, but not quite for real yet. By adding the -whatif switch, Chocolatey only pretends to update:

chocolatey upgrade all -whatif

or:

cup all -whatif

Ready to update all packages at once? Nice. So let’s disable those confirmation prompts while we’re at it too by adding the -y switch.

chocolatey upgrade all -y

or

cup all -y

Edited 2017-02-26 : replaced deprecated update command with the new Chocolatey 1.0 upgrade command.

Photo by elidr, cc-licensed.

why an open sourced .NET framework is huge

free

I was already excited about the recent ASP.NET vNext developments. Things like the fact that you can get the ASP.NET source code on Github, that it’s completely FOSS and that it’s disconnected from the rest of the .NET stack are just plain awesome.

A huge step for ASP.NET vNext is that you don’t need Visual Studio to write software with it. You can use your favourite text editor like Vim, Sublime, Emacs or whatever you like, together with a number of open source command line tools.

A second huge thing is that ASP.NET 5 can now run cross-platform using Mono on Linux and Mac. Not only can you use your development tools of choice to write and build your C# code, you can also do it on the OS of your choice. .NET everywhere. Think about it. *mind blown*

Yesterday however, things got even sweeter as Microsoft is now releasing more of the v5 .NET Framework as open source. This means more and easier cross-platform development and Mono compatibility (as the source can be easily integrated in Mono) for .NET code.

On top of that there is now a new Visual Studio Community edition of Visual Studio available for free. This is equal to the Pro version, so you can ditch those crippled free “Express” versions and write code in the tools you’re used to professionally. I love this one. I’ve messed around with SharpDevelop and the Express version, but if you’re used to the “real thing” it feels like having to work with your hands tied behind your back.

As if this wasn’t enough there’s a bunch of other cool improvements too, like getting only the .NET framework components you need for your project and pull them in using NuGet. Scott Hanselman sums them up nicely.

So if you’ve always wanted to check out .NET or C# but didn’t want to because you had to run it on Windows and in Visual Studio, there’s nothing holding you back any more. For .NET developers this is great. It gives us more freedom than ever without having to learn a new language and framework. For people hacking away on OS X and Ubuntu with Ruby, Python etc. because they want to use FOSS, this is an opportunity to dip into the wealth of .NET resources out there and try something new.

The strategy is clear. They want everyone to use the .NET framework, they want everybody to run that code on Azure (even if you’re not using .NET) and they see that making it open is the only way to get there. Great times are ahead.

how to update chocolatey

I use Chocolatey all the time to quickly install software on Windows machines. At some point Chocolatey itself also gets an upgrade, which just happened recently and then I can never remember how to get Chocolatey itself upgraded.

It’s in the documentation somewhere I’m sure, but since Chocolatey is about easily installing and upgrading Windows software, it was bound to work “recursively”.

So here’s how you do that from a Windows shell prompt, for (my) future reference:

    c:\> chocolatey upgrade chocolatey

speeding up your TFS CI builds

Entering Hyperspace

If you’re using TFS as your build server for CI builds of .NET projects, you want your CI build to be bleeding fast so devs don’t sit around waiting until their build completes. This is even more the case if you use a gated check-in on that CI build.

The ideal time frame is less than 5 minutes, but as a solution grows and more projects are added it gets hard to stay below that time limit without tweaking the build. With a CI build in this case I mean a build used to check if all code compiles, is integrated with other code and all unit tests pass on it.
This build is not used for deployment. There should be a separate build for that.

So what are the time sinks here in a standard TFS build?

It helps if you know what’s it’s doing, even though it’s pretty straightforward. First your code is fetched from TFS. A local workspace is used on the build server and all files are retrieved. Then the VS solutions build with MSBuild. Code analysis is performed if requested, unit tests run, outputs are copied to your drop folder and build reports are published.

Here are a number of things you can do to speed this up:

  • Get only the latest changes, not the full code base every time by not completely cleaning up the workspace. If you only clean up the outputs, it takes a lot less time to update the workspace. The more code you have, the more this counts.
  • Code analysis is CPU intensive and slows down your build significantly. Make sure you set this to “as configured” in your build configuration, so it doesn’t run on projects that you don’t want analysed. Then configure your projects in Visual Studio that need CA, and disable it for the rest.
  • In the Source and symbol server settings, set “Index sources” to false for the CI build. This feature includes source information into your PDB files which makes things easier to debug later on, but since we’re building strictly for a CI build we don’t need this data afterwards.
  • Disable copying output files to the drop folder. The output of the CI build shouldn’t be used for any deployments, so this can all be skipped to speed up the build.
  • Look for slow tests. Often these are integration-like tests which will be causing disk I/O by manipulating files or accessing a database etc. You can disable them for the CI build only by adding a TestCategory attribute called “Integration” (or whatever you like) and exclude those from the build in the test settings. Another trick is to put all your integration tests in a separate assembly and exclude the tests from running using the test assembly file pattern.  E.g. With *.Test.dll project Foo’s Foo.Test.dll is included, but Foo.IntegrationTest.dll isn’t.
  • Avoid lots of small projects in your solution. Every project will take a few extra seconds to build, so merging them into a single larger project will build faster. Make good use of namespaces instead. For example one assembly for unit tests (or 2 if you take that integration test project in mind) is better than a test project for each regular project.

Pick and choose as needed, but these should give you a considerable boost.
Remember to analyse your build before starting to tweak it. There’s no point in optimizing what’s fast as hell already. A good tool to check out what’s taking so long is the open source TFS Build Explorer. It shows your build steps in a tree-view, including timing info and is a hell of a lot quicker than the default build output from TFS for big builds. Depending on your TFS server version you might have to use an older executable, but they are all available in the download section.

Photo by Éole Wind, cc-licensed.

cool geek (dev) stuff I ran into lately

... "Mr. Droopy Eyes!"

I’ve had this list around for a while and though that most people would probably have heard of this by now so I didn’t see the point in posting about it.
Until last weekend someone on twitter was happy to find out about Chocolatey. So I guess not everybody knows these little gems yet, hence this blog post!

  • Chocolatey: a Windows packages manager of sorts. A bit like apt-get on Debian. It allows you to install a bunch of Windows software and tools from the command line. It’s pretty cool and is super handy to get a (developer) box up and running in no time. It’s also handy to keep your installed package up-to-date with the “cup all” statement. Sweet.
    There’s lot’s of good stuff in the gallery already, so you’ll probably find your favorite tool in there. If not, you can add it yourself because it’s built on the NuGet package manager system, or browse what’s available and find some new gems you didn’t know about yet.
  • I haven’t really used Boxstarter myself yet, but if you’re planning on using Chocolatey for some serious VM Windows installer magic, it might come in handy. It builds on top of Chocolatey and allows 100% uninterrupted Windows installs. Thought it was worth mentioning.
  • ScriptCS: one of Glenn Block & co little open source coding adventures. He thought it would be cool to use C# and the .NET framework to run scripts on Windows using the Roslyn compiler API. No need for Visual Studio, project files, compilers or anything like that. Just the scriptcs executable and a text file with your C# script code. Much like Node.js or Python for example. You know, scripting languages.
    Turns out this idea took off like a rocket in the community and has all sorts of cool features by now, like Nuget integration and script packs for reusability. It’s awesome.
  • dotnetfiddle.net : It’s jsfiddle for C# code. It’s a web site where you can type some C# code in a console application, run it and see your output instantly. Great of small bits of test code. It even has intellisense support so it’s easier if to use than LinqPad for this kind of tests apps if you don’t know all the statements by heart.
  • devdocs.io: all web dev docs in one place and easily searchable. Contains docs for thing like the HTML5 spec, JS, HTTP, HTML DOM and the most popular frameworks like Ember, Backbone, Angular, Knockout and Underscore. Also language like Python, Node, Ruby etc. In short, useful stuff for any web developer working with a modern stack.

Image by James Vaughan, cc-licensed.

how to get code from tfs from the command line

cmd.exe

Ever wanted to pull an update from the TFS server for all workspaces you have without having to start up the Visual Studio? Well I did. Visual Studio is rather slow in starting up and then you have to navigate to the TFS explorer (clicky clicky) and manually update the workspaces (clicky clicky) and then wait till the whole thing is done and VS becomes responsive again (waity waity).

You have the tf.exe command which you can use from a command prompt, but that requires you to use the VS command line because the right paths are set there. You could set the paths so they are available in all your shells, but that’s not very handy either.

I just wanted a batch script that I could run from any shell, that would just update my workspaces for me. Nice and easy.
Like when I press CTRL-R in Windows (Run) and type getfoo.cmd<enter>, it just makes it all happen for me.

So here’s how I did that:

@echo off

cls

:: Importing VS 2012 command line variables so we can run TF.exe
if exist "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VsDevCmd.bat" (
echo Importing VS 2012 environment variables...
setlocal
call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VsDevCmd.bat"
)

echo.
echo *** Updating TFS workspaces ***
echo.

:: Repeat this for all workspaces you want to update.
d:
cd D:\WS\pathtosolutionfiles\

tf get . /version:T /recursive

echo.
echo *** Workspace updated. ***
echo.

troubleshooting tips for ClickOnce deployment packages

Technologic

Getting a WPF desktop application deployed from a web server like IIS 7 using a ClickOnce package isn’t a walk in the park I’ve noticed. There are tons of little gotcha’s that stand in the way of your automated ClickOnce application generating script and tips to solve those issues are scattered around the web.
Here’s a list of the tips I found and needed to get a working package deployed:

  • To be able to download the ClickOnce package from a web server, the .deploy extension on the package’s files is used to make sure IIS doesn’t block the download because the types are not allowed or unknown (like dll’s, exe’s config files etc). This is to avoid having to add all those file types to the exceptions on the handlers in IIS, which would be a bad idea anyway as you don’t people to be able to download your ASP.NET dll’s anyway. If you don’t have .deploy, you’ll get “file not found” errors from IIS because it refused to allow the file to be downloaded.
  • If you keep getting an error about the application’s entry-point when you download the package, check if your build output has binaries for a mix of platforms. All references should be “msil”. If you see a mix of “msil” and “x86” for the executable or one of its assemblies that could be the issue. You can see that in your manifest file. Fix this by correcting all projects’ build settings in the solution’s configuration manager in Visual Studio.
  • Mage.exe has its limits. Some of the settings in the application file you’ll need to script yourself. For example the auto-update settings, or the mapFileExtensions to download .deploy files. The PowerShell XML type accelerator is great for this.
  • Make sure no manifest or application files are already in the folder you use to create your ClickOnce installer before running Mage. It will result in a non-working installer.
  • Some general troubleshooting tips.
  • You can find some more tips here.

Photo by Hugo Chinaglia, cc-licensed.