Azure-DevOps

Using private NuGet feed with dotnet publish

Posted on by trailmax

In Azure DevOps you can have your own private NuGet feed and I’m using that extensively. But sometimes authentication there is a pain.

This time I run into authentication issue while executing dotnet publish for a probject that used that private feed:

Unable to load the service index for source https://mycompany.pkgs.visualstudio.com/DefaultCollection/_packaging/MyFeed/nuget/v3/index.json. [D:\a\1\s\src\MyProject.csproj]
error :   Response status code does not indicate success: 401 (Unauthorized). [D:\a\1\s\src\MyProject.csproj]

The reason for that is that dotnet publish does restore by itself, even though all the packages have been restored previously via dotnet restore.

The solution for this is to do the obvious thing: don’t restore on publish vis --no-restore.

But that gave me more errors:

error NETSDK1047: Assets file 'D:\a\1\s\src\MyProject\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0/win-x64'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers.

Solution for that was to add <RuntimeIdentifier>win-x64</RuntimeIdentifier> in my csproj file.

The overall process goes like this:

dotnet restore MyProject.csproj --configfile D:\a\1\Nuget\tempNuGet_2089.config --verbosity Detailed

Where tempNuget file is configured by Azure DevOps and contains the credentials for the private feed.

dotnet build MyProject.csproj
dotnet publish MyProject.csproj --configuration Release --output D:\a\1\a\MyProject -r win-x64 --no-restore

And my csproj file looks like this:

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>netcoreapp2.0</TargetFramework>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  <StartupObject>MyProject.Program</StartupObject>
</PropertyGroup>

GitVersion vs dotnet pack on VSTS

Posted on by trailmax

Last night I run into a problem with GitVersion and dotnet pack command while running my builds on VSTS

The probem came up when I tried to specify a version number I’d like the package to have. There are answers on SO telling me how to do it and I’ve used it in the past. But this time it did not work for some reason, so I had to investigate.

Here is the way it worked for me.
To begin, edit your *.csproj file and make sure your package information is there:

<PropertyGroup>
    <OutputType>Library</OutputType>
    <PackageId>MyPackageNaem</PackageId>
    <Authors>AuthorName</Authors>
    <Description>Some description</Description>
    <PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
    <PackageReleaseNotes>This is a first release</PackageReleaseNotes>
    <Copyright>Copyright 2017 (c) Trailmax. All rights reserved.</Copyright>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

Continue reading →

Another reason not to use TFS

Posted on by trailmax

TFS source control system has got some strange meaning of “Workspace”. I’ve run into this numerous times and tonight again. This time I’m trying to migrate a project from TFS into git and keep the project name intact. So I’ve renamed my old project in VSTS to be ProjectName.TFS. And created a new one called ProjectName. But was faced with this great error:

The Team Project name ProjectName was previously used and there are still TFVC workspaces referring to this name. Before you can use this name, the owner of each workspace should execute the Get command to update their workspaces. See renaming a team project for more details (https://go.microsoft.com/fwlinkip?Linkld=528893). Found 2 workspace(s) using this name: ws_1_1;b03e2eb0-22aa-1122-b692-30097a2fa824, ws_dd5f57e41;b2345678-98a0-4f29-13692-30097a2fa824

Well, yes. Thanks for letting me know that this project name was used before. And I obviously don’t care about these workspaces – the PC where these were used no longer exist.

Following the link I was advised to execute this command to delete the dead workspaces:

tf workspace /delete [/collection:TeamProjectCollectionUrl] workspacename[;workspaceowner]

Yeah, no problem. Only it took me a while to find tf.exe. It is in the most obvious place in VS2017:

c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\

And WTF is TeamProjectCollectionUrl? and what about workspacename[;workspaceowner]? took me a while to figure out the correct format expected. Here what worked for me:

.\tf workspace /delete /collection:mycompanyname.visualstudio.com\DefaultCollection “ws_1_1;b03e2eb0-22aa-1122-b692-30097a2fa824”

The last bit is coming from the error message in VSTS: ws_1_1;b03e2eb0-22aa-1122-b692-30097a2fa824, ws_dd5f57e41;b2345678-98a0-4f29-13692-30097a2fa824 Name from the owner is separated by ; and different namespaces are separated by ,.

All that bloody obvious!

Publish Core XUnit Test Results in VSTS

Posted on by trailmax

Following my previous post, I’m building Asp.Net Core web application and I’m running my tests in XUnit. Default VSTS template for Asp.Net Core application runs the tests but it does not publish any results of test execution, so going into Tests results panel can be sad:

And even if you have a task that publishes test results after dotnet test, you will not get far.

As it turns out command dotnet test does not publish any xml files with tests execution results. That was a puzzle for me.

Luckily there were good instructions on XUnit page that explained how to do XUnit with Dotnet Core properly. In *test.csproj file you need to add basically the following stuff:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="xunit" Version="2.3.0-beta2-build3683" />
    <DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0-beta2-build3683" />
  </ItemGroup>

</Project>

Continue reading →

VSTS Private NuGet Feed and Building Dotnet Core Application

Posted on by trailmax

Honestly, VSTS private NuGet feeds will be a most blogged topic in this blog! I’ve already mentioned them at least twice. Here goes another post:

This time I’m building in VSTS Core application and the build literally goes:

  • dotnet restore
  • dotnet build
  • dotnet test
  • dotnet publish

And this worked really well for the basic application – I had it set up in minutes and got the resuilt I was looking for.

But during the life of the application I needed NuGet packages from my private feed and dotnet restore had no idea about my private feeds.

Even if supplied with nuget.config file I was getting 401 Unauthenticated – this is because I was not keeping my password(token) in this file.

Solution was to add this feed globally on the agent for every build. And this turned out to be easier than I thought.

In your build add a new task called Nuget Command:

Continue reading →

VSTS vs NuGet vs CakeBuild – again!

Posted on by trailmax

I keep migrating my build scripts into CakeBuild system. And I keep running them on VSTS. Because mostly VSTS build system is awesome, it is free for small teams and has a lot of good stuff in it.

But working with NuGet on VSTS is for some reason a complete PITA. This time I had trouble with restoring NuGet packages:

'AutoMapper' already has a dependency defined for 'NETStandard.Library'.
An error occurred when executing task 'Restore-NuGet-Packages'.
Error: NuGet: Process returned an error (exit code 1).
System.Exception: Unexpected exit code 1 returned from tool Cake.exe

This is because Automapper is way ahead of times and VSTS uses older version of nuget.exe. If I run the same code locally, I don’t get this error. So I need to provide my own nuget.exe file and rely on that. This is how it is done in Cake script:

Task("Restore-NuGet-Packages")
    .Does(() =>
    {
        var settings = new NuGetRestoreSettings()
        {
            // VSTS has old version of Nuget.exe and Automapper restore fails because of that
            ToolPath = "./lib/nuget.exe",
            Verbosity = NuGetVerbosity.Detailed,
        };
        NuGetRestore(".\MySolution.sln", settings);
    });

Note the overriding ToolPath – this is how you can tell Cake to use the specific .exe file for the operation.

Cake Build vs VSTS

Posted on by trailmax

Cake Build system has an integration point with most build systems like Team City, AppVeyor, Bamboo, etc. But there is not much for Visual Studio Team Services (VSTS). There is a Cake Build Task that facilitates execution of Cake script on VSTS build agent, basically a wrapper around build.ps1.

But if you need to reach into any of the VSTS build process variables or call any of their API – you are on your own. And we are migrating our grand-project to be built on Cake and with VSTS.

And one of the pain points were NuGet feeds. We are consuming private nuget feed from VSTS and we are pushing a NuGet package into a private VSTS feed. Both of these actions require feed authentication. And VSTS authentication is painful.

Continue reading →

Build Service in Visual Studio Team Services

Posted on by trailmax

First time I have tried TFS Build feature a few years ago and that was on hosted TFS 2010 version. And I hated it. It all was confusing XML, to change a build template I had to create a Visual Studio Project. I barely managed to get NUnit tests to run, but could not do any other steps I needed. So I abandoned it. Overall I have spent about 3 days on TFS. Then I installed Team City and got the same result in about 3 hours. That is how good TeamCity was and how poor was TFS Build.

These days I’m looking for ways to remove all on-prem servers, including Source Control and Build server. (Yep, it is 2016 and some companies still host version control in house)

Visual Studio Team Services Build – now with NuGet feed

Recently I’ve been playing with Visual Studio Team Services Build (used to be Visual Studio Online). This is a hosted TFS server, provided by Microsoft. Good thing about it – it is free for teams under 5 people. At the end of 2015 Microsoft announced a new Package Management service. So I decided to take it for a spin. So today I’ll be talking about my experience with VSTS build, combined with Package Management.

Disclaimer

I’m not associated with Microsoft, nor paid for this post (that’s a shame!). All opinions are mine.
VSTS is moving fast with new features popping up every other week. So information in this post might become out-of date. Please leave a comment if things don’t work for you as expected here.

C# package in private NuGet feed

Today I actually need to create a C# library for internal use and publish it to a private NuGet feed. So I’ll write down my steps for future generations.
For the purposes of this guide, I presume you already have VSTS project and have some code in it. You also know what CI is and why you need a build server.

Continue reading →