We recently updated our Azure SDK to 2.8.
Now when building our solution on VSO hosted build we get build errors.
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Windows Azure Tools\
2.8\Microsoft.WindowsAzure.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I've found another one with similar issues with a question posted on MSDN but without any answers. Support for Azure SDK 2.8 in hosted build
Anyone know how to get around this issue? Do we have to downgrade?
We are working on the update now. Azure 2.8 should be on the build machines week of Nov. 30.
Update: We ran into a couple of issues and still hope to have this completed this week, but it may slip into next week.
Update Dec. 17: We finally got the updated image with Azure 2.8 into production yesterday. Sorry for the long delay.
The latest Azure SDK supported on Hosted build is 2.7. Refer to Hosted build controller for details.
To build your solution, you'd either downgrade Azure SDK version to 2.7 or deploy your own build agent and install Azure SDK 2.8 on it.
Related
I am receiving an error in Azure CI pipelines. While trying to run a DotNetCoreCLI restore task.
Been scrapping the net for hours to no avail, no solution from related questions have helped me understand the problem.
Basically, we have added a new project to a repo. This project requires a dotnet restore command to be run to create the project.assets.json file.
Please see script below and log snapshot for each task.
Script:
UseDotNet snapshot:
DotNetCoreCLI error message:
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
##[error]No files matched the search pattern.
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts.
Have looked around quite a bit. Nothing seems to help me understand what is going wrong here.
Any assistance would be appreciated.
Turns out the issue was in the folder location referenced as $(UtilityLibrary).
Took me a while to figure out as I didn't have access to the actual variable set.
info message is caused by the fact the .NET version is out of support https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core
Please always check the path of the solution , proj
I'm migrating from VS2015 to VS2017, and updating a repo's solutions to be able to be compatible with VS2017. In the process, I'm also updating the Azure SDK version from 2.7 to 3.0.
I'm setting up a fresh dev environment, and installed Azure SDK 3.0 via VS2017's Azure development workload.
When I opened the solution file in the repo, I got one notice per cloud service project that its Microsoft Azure Tools version was getting upgraded from 2.7 to 2.9...
...and the ProductVersion tag in the corresponding .csproj files was updated from 2.7 to 2.9.
Questions:
Why wasn't this updated to 3.0?
Is there anyway for me to update it
to 3.0 without manually editing the csproj file? I don't see an
option to do so in Properties when I right click the cloud service
projects in Solution Explorer.
Is there some reason I shouldn't be
doing this?
"Microsoft Azure Tools - v2.9" mentioned in your screenshot is just a little misleading.
Underlying reason is that Microsoft hasn't really changed the version number of most components as part of 3.0 SDK release. Even the binaries get installed in the same folder as 2.9.
Good news is that you don't need to do anything special apart from converting the project to target latest version, which you're already getting prompted for.
So once you do convert your project as per the prompt, you're essentially working with SDK 3.0, even though version string says v2.9, because as the links explain, most of the components haven't changed major version number as part of SDK 3.0 version (when comparing with 2.9)
Here are some of the links which talk about this -
Azure SDK for .NET 3.0 Release Summary
No breaking changes to the Azure SDK 3.0 have been introduced in this
release. There is also no upgrade process needed to leverage this SDK
with existing Cloud Service projects. To allow use of the Azure SDK
3.0 without requiring an upgrade process, Azure SDK 3.0 installs to the same directories as Azure SDK 2.9. Most the components did not
change the major version from 2.9 but instead just updated the build
number.
Visual Studio 2017 latest installer does not install Azure SDK 3.0
In this link look at the response from Devin Breshears - MSFT
Azure 3.0 SDK Install Weirdness
An independent blog talking about the same issue.
According to https://www.visualstudio.com/en-us/get-started/build/hosted-build-controller-vs
and
https://twitter.com/tfsbuck/status/595263582327025665
the tfs online build services should be updated. I just upgraded projects to 2.6 and checked them in to get the following:
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Windows Azure Tools\2.6\Microsoft.WindowsAzure.targets" was not found.
Have something changed with 2.6 or is it because my build service not yet has been updated?
The VSO Host Build Controller has now been updated with Azure SDK 2.6.
You can see all the supported software here.
Since upgrading to Azure SDK 2.5 our CI build is failing. We have an automatic build on Visual Studio Online.
Here's the exception that is being thrown:
C:\a\src\WebService\WebService.ccproj (82): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Windows Azure Tools\2.5\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Any ideas?
We are deploying 2.5 on the build machines now. We have it on all of the scale units but one, where we hit an issue. That's under investigation now, and we'll get the roll out finished asap.
Update: We've just finished deploying the new image with 2.5 to all build machines.
Note: You can see a full list of exact versions installed: http://listofsoftwareontfshostedbuildserver.azurewebsites.net/
I am deploying Orchard to Azure cloud services (webrole) without any code changes to the official stable release. However, when I navigate to that freshly deployed Orchard cloud service (webrole), I see a YSOD with Could not load file or assembly 'Microsoft.WindowsAzure.ServiceRuntime, Version=1.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
As a work around, if I enable Local Copy=True (i.e. modify source), then this specific YSOD goes but is replaced by another one for msshrtmi). But more importantly, I'm able to deploy the pre-built downloaded Orchard Azure (1.7, prebuilt off same GIT src tag), without issues, so I'd rather fix the root issue than go down a rabbit hole of workarounds and drift further from the official sources.
How I'm running into this issue:
Download source from GIT (http://orchard.codeplex.com/SourceControl/latest, I used commit 5e0c26f73cf5, )
Run ClickToBuildAzurePackage.cmd script
Edit buildazure\Stage\ServiceConfiguration.cscfg to put in connection string's to point to the real Azure storage account (vs Local Storage).
Deploy both the files in buildazure\Stage to Azure via the windowsazure.com portal
Navigate to site (eg: http://OrchardTest.cloudapp.net)
Enjoy the yellow-screen-of-death :(
Our local build system:
Windows 8, x64
VS2012.3
Azure SDK 1.7, 1.8, 2.0
Question:
Has anyone deployed to Azure successfully? Any ideas how to resolve this issue?
There should never be a need to CopyLocal True on the Azure Service Runtime. That is automatically included in the package, defined by your Cloud Services project (In this case, Orchard.Azure.CloudService). And actually, I could imagine that CopyLocal True might cause issues if the bin contains a different version of the Service Runtime than the Azure package was built under.
Orchard Azure uses the Azure 2.0 libraries. It shows that you have the 2.0 SDK installed because you can compile the Orchard.Azure.CloudService project to make a package. Cloud Service projects have different a project guid for each version of the Azure tools, so without the v2.0 SDK, it would be an unknown project type. However, with your Orchard website picking up ServiceRuntime v1.7, it seems that something is amiss with your local environment, as it should still identify with v2.0.
When you open Orchard.Azure.sln, check the Properties on the Microsoft.WindowsAzure.ServiceRuntime reference within the Orchard.Azure.Web project. What is the version that Visual Studio lists on that reference? It should be 2.0.0. If it does not, my best recommendation would be to reinstall the 2.0 Libraries.
The deployment steps as you have defined work just fine with no YSOD. I successfully tried it just before writing this; it did not reproduce your issue.