VSTS Task to install DotNet Core SDK failing for 2.1.403

[NetTecture]

2018-10-02T18:20:40.4342027Z ##[warning]Could not download installation package from this URL: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.1.403/https://download.visualstudio.microsoft.com/download/pr/28820b2a-0aec-4c24-a271-a14bcb3e2686/5e0ad8ae32f1497e8d0cace2447b9e01/dotnet-sdk-2.1.403-win-x64.zip Error: {}
2018-10-02T18:20:40.4368746Z ##[error]Failed to download package for installation
2018-10-02T18:20:40.4533485Z ##[section]Finishing: Use .NET Core sdk 2.1.403

But it should be there:

https://www.microsoft.com/net/download

shows 2.1.403 as download.

[luchenatwork]

Based on the build log: the download link is wrong.

https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.1.403/https://download.visualstudio.microsoft.com/download/pr/e85de743-f80b-481b-b10e-d2e37f05a7ce/0bf3ff93417e19ad8d6b2d3ded84d664/dotnet-sdk-2.1.403-linux-x64.tar.gz

[luchenatwork]

According to release json file: https://github.com/dotnet/core/blob/master/release-notes/releases.json.
The 2.1.403 SDK section has full download URL instead of just file name which is different from previous release version.

[luchenatwork]

Issue submitted to .NET Core group
dotnet/core#1973

[bishal-pdMSFT]

@NetTecture I have created a new issue dotnet/core#1977. We will also be handling this from our side.

[NetTecture]

Please. This is now day 2 we can not run modern builds on the agents because we ant to check upgrades to the current SDK. This also need to be tested - can not be that this is an unstable part.

[NetTecture]

And now it has another days passed and we STILL can not build using the current framework.

[bishal-pdMSFT]

@NetTecture we are working on this and the fix will soon be rolled out, but this is not a very high priority item for us as this issue appears only for one version of .net core. I would suggest you to take some work-around in the meanwhile: either use a different version or if you really need this particular version, then use a private agent having this installed. it might take a couple of days for us to do a safe roll out of the fix.

[NetTecture]

Here is what you said: We are microsoft. We do not support our own product in the current version. We gladly take your money (for private agents), though, so you are not able to build it because - lack of competence and we consider you not building not important because we get paid anyway. Something like that correct? Does your manager know how you sabotage Azure DevOps?

Damn, low priority? Anyone on your team on drugs? What about your low priority pays my team's loss of income? And "use a private agent" - seriously? This is one advice I would personally FIRE you for incompetence. There are reasons we use the current agents, they do not go just because you are not able to actually support current dotnet versions. WHOW. AMAZING. In the past I was used to this level of competence and customer service from Oracle. Customer oriented companies run different. What happened to the Microsoft of Steve?

We are rolling back for now. Let's try the CURRENT framework again on monday and see whether your company considers supporting it then...

[kant2002]

@bishal-pdMSFT our question, is the we should not assume that LTS version is not considered by LTS by Azure devops team? Whole resolution of the issue, assume that .NET Core is not considered as priority platform by MSFT and Azure Devop product should not be used if teams want to make sure that always on latest LTS patch.

Whole process of handling issue is opaque. We have no idea what MSFT people has to do to properly fix issue without affecting existing customers.
From technical point of view, looks like change is just URL generation, and it could be

• trivially fixed
• trivially tested
  Then maybe we should wait until full test suite will be run, then you probably have some window for deployment updated tasks, and such and such.
  But this is all speculations on my side, and opaqueness of the responses does not help those of us who want LTS bit on the AzureDevOps pipelines.

Whole situation that .NET Core team sometime change their internal bookkeeping format to something else is entirely predictable. If current .NET Core Tool Installer task allow manually specify URL for downloading .NET Core, that help us a lot more.

[cyberprune]

This is now a blocker for us too and is stopping our pipelines from building since the latest version has been rolled out. This should be a high priority item, as it's now blocking our team from deploying new versions of the software and we do not wish to manually hard code all of the framework versions in each project.

Surely deploying the new version of the task or editing the config to use the filename, rather than URL is a quick fix and will get Azure DevOps customers building their solutions again.

[bishal-pdMSFT]

We have started rolling out hotfix for this issue. It should reach all customers by tomorrow.

[cyberprune]

Thanks very much

[NetTecture]

Ah, good. Sensible decision. Good. So, let's say before weekend (europe based, so time delay) we can update and roll out 403. Thanks.

[kant2002]

Thanks, a lot!!!

[luchenatwork]

@bishal-pdMSFT Thank you and VSTS team for the quick fix.

The dotnet team should really be blamed with this breaking changes. How could they not knowing to notify the other internal Microsoft team?

[shelomovskiy]

How do I know that the fix is there? My cloud VSTS build is still failing at the SDK install task

[bishal-pdMSFT]

The fix has been rolled out completely. You can retry the task.

[shelomovskiy]

It works, thank you!

…

On Fri, Oct 5, 2018 at 5:43 PM Bishal Prasad ***@***.***> wrote: The fix has been rolled out completely. You can retry the task. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8472 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEOTCVmm6j4dC0DNzufvZ7ppPBVPbLjiks5uhw2XgaJpZM4XEmkj> .

[kant2002]

@bishal-pdMSFT thanks!