The art of simplicity

Although good naming and a set of well written tests  can bring us so far, good documentation is sometimes indispensible. Before releasing a component I was documenting a public API using the Visual Studio XML documentation. The exposed API was using generics, but I didn’t know what the correct documentation structure was. MSDN brought the answer:

Don’t forget! Today it’s AzureCon 2015 , a free, virtual event about Microsoft Azure. Hear from the experts about the latest Azure innovation and easy-to-adopt solutions. Listen as customers take the stage to share their stories. Join live Q&As and interact with the architects and engineers who are building the latest features. Choose from more than 60 technical sessions—and accelerate your journey to the cloud.

While preparing a release I was cleaning up some build warnings that sneaked into the code. One of the warnings I got was the following regarding Unity, Microsoft’s IoC container: Warning              11           'Microsoft.Practices.Unity.InjectedMembers' is obsolete: 'Use the IUnityContainer.RegisterType method instead of this interface'                C:\Projects\Services\ServicesConfiguration.cs           136         38                Services The warning was coming from the following code: Using this code I’m configuring the constructor parameters when a ServiceAgentConfiguration class is resolved from the IoC container. I was doing this through the InjectedMembers object from Unity. However this class is obsolete, so I had to update my code to the following:

Thanks to contributions from the community MDN.io (Mozilla Developer Network) is THE place to be for anything regarding JavaScript and web development in general. It’s a great learning resource and reference for all the ins and outs of the web platform, its tools and technologies. Web developers, add this to your favorites!!!

While debugging the issue with the Microsoft Fakes framework I had yesterday, one thing I tried was to regenerate the Fakes assemblies. First thing I did was remove all generated fake assemblies from the references: Afterwards I right clicked on the original assembly and choose ‘Add Fakes Assembly’: But this failed with the following error message: What I forgot to do was to remove the generated Fakes folder as well. After doing that I was able to regenerate the Fakes assemblies.

After upgrading to Team Foundation Server 2015, some of our builds started to fail. Inside the build log, I found a long list of errors. All similar to the following: f.cs (17985, 0) The type or namespace name 'EventIgnoreAttribute' does not exist in the namespace 'System.Diagnostics.Tracing' (are you missing an assembly reference?) [c:\b\1\App\Daily Release\Sources\App\Test\Test.Mailing\obj\Release\Fakes\m\f.csproj] This test project is using the Microsoft Fakes framework to mock the usage of the SmtpClient. But for an unknown reason the fakes framework cannot generate code for some of the namespaces inside the System DLL. I found some forum posts where people had similar issues. I couldn’t find a real solution, but I was able to fix the issue by applying the following workaround: Inside Visual Studio open the project where you are using the Fakes framework Go to the Fakes folder inside this project For each fakes file, clear the existin

Last week I had a situation where I wanted to replace a NuGet package. The problem was that the NuGet Package version was not updated but the content was changed (I know, not a good idea). So what I wanted is that the system remove the existing package and reinstall it from the NuGet repository.  First thing I tried was the following command: Update-Package –reinstall <package name> The command succeeded but when I checked the content of the NuGet Package it contained still the old content. Afterwards I tried a different approach: I deleted the reference from my project Edited the packages.config to remove the reference to the NuGet package Removed the NuGet package from the file system After removing everything manually, I did a new install: Install-Package <package name> But again, no luck. When I checked the content of the NuGet Package the old content was still there… In the end I was able to solve the issue by clearing the package

Team Foundation 2015 introduces a new build system where they move away from the XAML based build templates. Instead you get a new system offering the following advantages: Easy customization(at least easier than customizing XAML workflows) Cross platform support TFS web portal integration Simpler build agent deployment(xcopy install) Better control of agent routing(through the definition of agent capabilities) Azure continuous deployment And many more… Microsoft offers a set of build tasks out-of-the-box but it’s easy to create your own. Best place to get started is the VSO-Agent-Tasks GitHub repo:  https://github.com/Microsoft/vso-agent-tasks . This repo contains the tasks that are provided out of the box with Visual Studio Online and Team Foundation Server. This provides open examples on how we write tasks which will help you write other tasks which can be uploaded to your account or server. See writing tasks below.

After using a local Git repo for a while, it was time to push all changes to a remote repository. On my local repository, I also created a few branches. Before I pushed each branch one by one. But there had to be a better way? Of course there is! To push all your branches at once, you can run the following command: git push REMOTE --all

After my post from yesterday where I talked about a problem with X.509 certificates, I did some extra research. One great blog post that I would recommend to read is “ Eight tips for working with X.509 certificates in .NET ”. In this post Paul Stovell, the creator of Octopus Deploy (a great tool by the way), shares some of the lessons he learned when using X.509 certificates to secure communication between the central Octopus server in Octopus Deploy and the remote agents.

Aaah, security errors, you have to love them. When deploying a new service on IIS, I got the following error: Server Error in '/SampleService' Application. The profile for the user is a temporary profile. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Security.Cryptography.CryptographicException: The profile for the user is a temporary profile. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [Cryp

The Microsoft ALM rangers are on a roll. With the release of Team Foundation Server 2015, they have created 2 checklists to help you prepare a TFS upgrade: The Short Lead Checklist: http://blogs.msdn.com/b/visualstudioalmrangers/archive/2015/08/07/short-lead-checklist.aspx The Long Lead Checklist: http://blogs.msdn.com/b/visualstudioalmrangers/archive/2015/08/10/long-lead-checklist.aspx Definitely useful to guarantee a smooth migration process…

Before upgrading/migrating a TFS environment, I make the environment unavailable first. As I always forget the exact instructions, I’ll write them down in this (short) post: Log in on your TFS Application Tier Open a Command Prompt in Administrator mode Browse to the installation folder of your TFS instance. Open the Tools subfolder. Run the following command: TFSServiceControl quiesce This will stop all the services and application pools of TFS To undo this, you can always run the following command: TFSServiceControl unquiesce More information: https://msdn.microsoft.com/en-us/library/ff470382.aspx