The art of simplicity

A customer contacted me this week explaining that they noticed very long wait times before a build or release was triggered when using CI. These kind of triggers are scheduled using the TFSJobAgent queue, so I expected that for an unknown reason the queue was saturated with too much work. I asked them to collect some data using the TFS administration pages . Here is snapshot of the data we collected: These charts tell us clearly there is an issue with the TFVC_RepositoryCodeIndexing job responsible for indexing our source code and making them available for search through ElasticSearch. This is a clear indication that there is something wrong in ElasticSearch itself. Time to dig into the ElasticSearch logs…but we’ll leave that for another post.

By default when you add Swagger (through SwashBuckle ) in your ASP.NET Web API project, the swagger UI is available on following url: https://localhost:44300/swagger . However because this project was only hosting this API, we wanted to show the Swagger UI on the root page. To get this working we added another route to our WebApiConfig.cs file:

While doing a code review I noticed some complex query constructions using a combination of temp variables, CTE’s and ROW_NUMBER to implement pagination in our application. The good news was that the query worked, the better news is there is a much simpler alternative that can be used to implement pagination in your queries by using the OFFSET-FETCH clause. An example: SELECT First Name + ' ' + Last Name FROM Employees ORDER BY First Name OFFSET 10 ROWS FETCH NEXT 5 ROWS ONLY; Remark: OFFSET-FETCH can only be using in combination with an ORDER BY clause. More information: https://technet.microsoft.com/en-us/library/gg699618(v=sql.110).aspx

One of the tricks I applied when creating .NET applications was introducing a GlobalAssemblyInfo.cs file. This class contained all the shared assembly information and was referenced in the AssemblyInfo.cs file of all my projects. It allowed me to update the general settings like AssemblyVersion in one place. However in .NET Core/.NET Standard, the AssemblyVersion.cs file no longer exists.Instead you can specify these settings using the Package tab of your project settings. But what if you want to still share some settings among your projects? You can still do this by adding a shared project file: Step 1 – Add a solution folder to your solution. Step 2 – Right click on the solution folder, choose Add –> New Item –> Text File. Rename the text file to GlobalAssemblyInfo.proj. Step 3 -  Open the proj file and add the settings you want: Step 4 – Add the settings to your other projects. For each project, right click on your project, choose Edit ProjectNam

Yesterday I lost some time searching the exact parameters to publish a specific publish profile using Web Deploy. To help me get this done faster in the future, here are the correct parameters I used (with some explanation): /p:DeployOnBuild=true –> Triggers web deploy /p:PublishProfile=Development –> The name of the Publish Profile that should be used /p:AllowUntrustedCertificate=True –> This is only necessary if the server certificate doesn’t match the server name(which normally shouldn’t be necessary) /p:username=WebDeployUser  --> The IIS user account used to connect to the IIS Web Management service(WMSVC) /p:password=WebDeployPassword –> The password of the IIS user account

Microsoft released a free e-book   about cloud native development of applications using serverless. From the About page : This guide explains the components of the Azure serverless platform and focuses specifically on implementation of serverless using Azure Functions . You'll learn about triggers and bindings as well as how to implement serverless apps that rely on state using durable functions. Finally, business examples and case studies will help provide context and a frame of reference to determine whether serverless is the right approach for your projects.

WebAssembly.Studio is an online IDE that helps you learn and teach others about WebAssembly, the new hotness in town. It is a great way to tip your toes in the new standard. You can write  an application in C/C++/Rust in your browser and compile it down to .wasm(WebAssembly binary modules) files. An introduction video explains the supported features and functionality:

Note: This is a continuation of a previous post found here: https://bartwullems.blogspot.com/2018/06/tfs-build-agent-ssl-certificate-problem.html In the previous post I suggested a solution which disables the SSL verification check. Of course, this is more a dirty heck and not a great solution at all. Let’s have a look at a better solution: Step 1  - Extract the root certificate Browse to your TFS portal. Inside the browser go to the SSL certificate(exact steps can differ depending on your browser of choice; here are the steps for Chrome: https://bartwullems.blogspot.com/2017/05/how-can-i-view-used-ssl-certificate-in.html ) Once you have the certificate window open, go to the Certification Path tab and select the top-most certificate in the chain. Click View Certificate, go to the Details tab and click on the Copy to File… button. The export wizard will be started start the export wizard for certificates. On the second page of the wizard, you will be asked what for

Compiling and running an Ionic application on your Android device is a whole lot of fun, requiring a big list of tools and a little bit of good luck. It seems that I was out of luck as I got the following error message during the startup of Gradle: Could not reserve enough space for object heap To solve it, I specifically downloaded and installed the 64bit version of Java: After the installation completed, I updated my JAVA_HOME environment variable to point to the 64bit version:

After upgrading to TFS 2018 and reconfiguring our build servers, some of the TFS Version Control based builds started to fail with the following error message: Exit code 100 returned from process: file name ‘tf’, arguments ‘vc workspace /new /location:local’ The line above we noticed the following informational message: The path {pathname} is already mapped in workspace {workspacename} During the migration we switched URI’s which seemed to confuse TFS. To solve it, we removed all existing workspaces for our build account: tf vc workspaces /collection:https://tfs/DefaultCollection /remove:* We also had to delete the TFS client cache, which can be found here: "%localappdata%\Microsoft\Team Foundation\7.0\Cache\"