I've installed the VS 2017 Build agent and registered it in the 'Default' agent queue. The project I'm trying to build is a VS 2017 class library project, targeting .Net Standard 1.0.
When building from Visual Studio, build succeeds. However the build on the build agent fails.
T16:05:59.0389362Z ##[error]C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp.NETStandard,Version=v1.0.AssemblyAttributes.cs(4,20): Error CS0400: The type or namespace name 'System' could not be found in the global namespace (are you missing an assembly reference?)
By comparing the build logs with my local build I can see that the build agent calls the csc.exe with missing 'reference' attributes.
My project has no any explicit references - it just requires .NetStandard 1.0 libraries (SDK).
The command line the build agent uses is:
\MSBuild\15.0\Bin\Roslyn\csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702,1705 /nostdlib+ /errorreport:prompt /warn:4 /define:TRACE;RELEASE;NETSTANDARD1_0 /debug- /debug:portable /filealign:512 /nologo /optimize+ /out:obj\Release\netstandard1.0\Geo.Common.dll /ruleset:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Team Tools\Static Analysis Tools\Rule Sets\MinimumRecommendedRules.ruleset" /target:library /warnaserror- /utf8output /deterministic+ Distance.cs DistanceExtensions.cs GeoCoordinate.cs Unit.cs "C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp.NETStandard,Version=v1.0.AssemblyAttributes.cs" obj\Release\netstandard1.0\Geo.Common.AssemblyInfo.cs
I know I can just hardcode the 'reference' list as command line attributes to the build step in build definition, but that's a workaround.
What is the right way to fix this ?
Thanks!
UPDATE
Turned out that the reason for the failure was that the earlier step in the build definition, the NuGet Restore was using the 3.5 version of nuget.exe. Because the project file was in VS 2017 format, nuget.exe was unable to find any referenced packages, so was completing successfully without actually pulling anything in. Thus, on the next step, the build was failing as no NuGet packages (hence any assemblies) were found.
SOLUTION
I downloaded nuget.exe 4.0 (found here) and place it in the agent's work directory (D:\VsAgentWork\nuget.exe in my case). Then, I customized the NuGet Restore step, to reference the nuget.exe from the provided location (....\nuget.exe).
You need to restore you package for your solution. For .NET Core you need to either do this with the dotnet cli or with the MSBuild /t:restore target or you can download NuGet 4 from the nuget site and put that on your build machine and specify it in the path on the NuGet installer task.
Had this exact same issue, and switching from
nuget restore xyz.sln
to
dotnet restore
nuget restore xyz.sln
before the build itself fixed it.
I experienced this with VS2017 too, it seems to be a bug.
In the first instance just restart VS, but I did find the full steps are sometimes needed to resolve the issue:
Close VS
Delete the .vs/ folder
Delete any bin/ and obj/ folders
Reload VS and run a rebuild
If you want to use the hosted VS2017 agent pool for your .net core app, you can run 'dotnet restore', and that should work too: https://www.visualstudio.com/en-us/docs/build/apps/aspnet/ci/build-aspnet-core
Related
I've got .NET 7.2 WEB API project, which was build with x64 Visual Studio 2022 v17.2 - v17.4. Now I try to set up CI/CD pipeline, for what I use .yml with following code:
- 'C:\nuget.exe restore server.csproj'
- '& "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\MSBuild" server.csproj'
Constantly getting error:
error NETSDK1064: Package Microsoft.EntityFrameworkCore.Analyzers, version 7.0.2 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
What I've tried is:
I enabled Win32 long paths as it suggested here
I've created new WeatherForecast project and new repo with name tst, so path certainly cannot be shorter
Nothing gives any success
As far as I understand, the problem is that I use x32 NuGet CLI with x64 VS 2022 builder. Bit depth does not match. As far as my project uses .NET 7, I cannot use VS 2019. Also I cannot find x64 NuGet CLI - official site provides only x32 versions
I need some way to restore packages and then build the project from YML file. What surprised me is that I can sequentially run all commands from .yml in cmd.exe and as a result I will get build with no errors. I tried to $ whoami prior to any of .yml command and it gives me that it's SYSTEM user, which by the way got full access to IIS's wwwroot folder, but the error triggers prior deployment step, so I have no clue how it could be related
I'm stuck, got no idea what to do, but guess that solution is quite simple, I'm to blurry now. SOers please help me
Solution
Great thanks to #mu88!
In accordance to his suggestions yml took that form:
- 'dotnet restore service.csproj -v n'
- 'dotnet service.csproj'
And everything works as it supposed to
After some investigation (see the comment section) we found out that using dotnet build instead of msbuild solves the problem.
I have a Azure pipeline with a MSIX Build and Package step for a WPF solution that started occasionally failing last week (with no changes to the pipeline definition) and is now failing every time with the error:
C:\Program Files\dotnet\sdk\5.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1004: Assets file 'D:\a\8\s\xxxxxx.Packager\obj\project.assets.json' not found. Run a NuGet package restore to generate this file. [D:\a\8\s\xxxxxx.Packager\xxxxxx.Packager.wapproj]
The project in question is the UWP packaging project and has no nuget references and I've had many runs of the pipeline which were successful.
The difference I can see in the logs is the failed builds (before the error above) seem to be missing a line:
Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Roslyn
I seem some other questions and answers around the error above but none specifically pointing to the issue above. The wapproj is included in the solution. Carrying out a nuget restore for the .wapproj does not fix the issue.
It's very odd that it was working and suddenly isn't with no changes to the pipeline.
First, you should make sure that you have add nuget restore task under pipeline. The restore should generate the guidance file project.assets.json file under obj folder. And that is necessary for build process.
And, you should moidfy your xxx.wapproj under azure repos and change Microsoft.Windows.SDK.BuildTools nuget package to version 10.0.18362.3-preview. From this document, the other versions are abandoned.
<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.18362.3-preview" PrivateAssets="all" />
I have a build pipeline configured for a Service Fabric solution on Azure DevOps like this:
Everything was fine until a few days ago when the build started failing on a particular build agent (private), with the following error (for a few projects):
C:\Program Files\dotnet\sdk\2.1.200\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(327,5): Error : Assets file 'F:\Agent03\w\84\s\src\MyProject.Sam.Tiles.Domain\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
The failing task is the Build solution $(PathToSolution) one.
The weird thing is that the build fails when running on some agents but with others the build is fine.
Some details:
Use NuGet 4.x task started using NuGet v4.9.1 very recently, I think. I tried using v4.8.1 with no luck;
Most of the projects use the PackageReference format, but the .sfproj project uses the packages.config file
I tried using the dotnet restore task but there is an error when trying to restore the packages for the .sfproj project:
`Error : Unable to find the
'....\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props'
file. Please restore the
'Microsoft.VisualStudio.Azure.Fabric.MSBuild' Nuget package
Any idea on what might be causing this issue?
Some of the projects use the PackageReference format but the .sfproj project uses the packages.config file.
I still don't understand why the build started failing, but I was able to find a workaround. Given that PackageReference is not yet supported in Service Fabric projects, my workaround was to use both restore tasks as follows:
My problem turned out to be a solution that didn't include all the necessary projects.
I have a master solution file that includes all my projects, and a number of smaller solution files with only some of the projects. The master solution built fine in Azure DevOps, but the partial solution failed.
I realized that the missing project.assets.json file belonged to a project that needed to be included in this failing solution.
Trevor's comment on 2/20 gave me the clue. You likely don't have the complete set of projects referenced by the solution. (ProjectReferences may go to other projects, which are not in the solution).
Here is why this crazy workaround (run dotnet.exe and nuget.exe restore tasks) worked:
dotnet restore will walk project references by default to ensure they are restored also.
--no-dependencies switch can turn that off.
nuget.exe restore has the opposite default, because we didn't want to break old users.
-recursive can turn this on.
The right solution is to make your solution contain all the projects.
-Rob Relyea
NuGet Client Team, Engineering Manager
I am trying to get SourceLink to work with a private NuGet package.
I am running a netcore2.1 web application which references a netstandard2.0 NuGet package hosted on our Azure Devops NuGet feed.
Question 1: Does Source Link support .NET Standard packages?
I have followed the instructions in the guide here https://learn.microsoft.com/en-us/azure/devops/artifacts/symbols/setting-up-github-sourcelinking?view=vsts, which is basically:
Add the Index Sources and Publish symbols package to my Azure Devops build.
In Visual Studio, add our VSTS server as a symbols server
In Visual Studio, enable Source Link support. I also tried enabling Source server support.
The Build pipeline Publish symbols path appears to be working - in the logs I see:
Succeeded processing D:\a\1\s\src\MyCompany.Core.Services.SnapshotClient\bin\release\netstandard2.0\MyCompany.Core.Services.SnapshotClient.pdb:
When I start debugging my application I see a bunch of output in the VS Output window:
'dotnet.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.1.4\Microsoft.AspNetCore.Hosting.dll'. Cannot find or open the PDB file.
For my NuGet package I see "Symbols loaded" which seems promising.
FWIW I do not see the prompt from Visual Studio that "Source Link will download from the internet".
When I debug and attempt to Step-In to my NuGet package, it just steps over it.
I then tried:
Headed over to https://github.com/dotnet/sourcelink and followed their instructions and installed the Microsoft.SourceLink.Vsts.Git package (Question 2 is that necessary?)
When that didn't work, I upgraded every darn package in my application, which forced me to install .NET Core SDK 2.1.403
Tried adding some stuff to the .csproj of my NuGet package, after trawling GitHub issues
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
and
<DebugType>portable</DebugType>
<ci>true</ci>
Now my .nupkg includes .pdb files too, which weren't there before. Still doesn't help me step in debug though.
installed the sourcelink cli tools from https://www.nuget.org/packages/sourcelink/ and ran sourcelink print-urls on the .pdb from my .nupkg. Looks correct, I think? URLs are present.
Disabled indexing after seeing a comment https://github.com/MicrosoftDocs/vsts-docs/issues/1336#issuecomment-414415049 from #mitchdenny . Still doesn't work.
And now I'm stumped as to why it's not working.
I wrote a complete blog on how to do this using .NET Core & AzureDevops, but the steps should work for .NET Standard projects as well.
That said, some key takeaways that are missing from Microsofts documentation that you should know are:
The project's debugging information needs to change from "Portable" to "Full"
The AzureDevOps Nuget(restore, build, pack & push) need to use the .NET Core task.
The .NET Core build task should have an argument "--configuration" that passes in the value "debug". Doing so generates the .PDB file
The .NET Core pack task should use the "custom" command, with the custom command being "pack" and have the following arguments: "--include-symbols -v d" and a "-c" that passes in the value "debug". Doing so tells the pack command to include the .PDB file in the package.
Question 1: Does Source Link support .NET Standard packages?
Yes. I successfully built a .NET Standard 2.0 library on Azure DevOps Pipeline, after which it was pushed to our private Azure DevOps Artifacts NuGet feed. Then, in a local project, I was able to step into the library (Visual Studio prompted me with a pop-up about downloading remote source code).
Here are the changes I had to make in the library's .csproj file:
<PropertyGroup>
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
<AllowedOutputExtensionsInPackageBuildOutputFolder>
$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb
</AllowedOutputExtensionsInPackageBuildOutputFolder>
</PropertyGroup>
...
<ItemGroup>
<PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0-beta-63127-02" PrivateAssets="All"/>
</ItemGroup>
Question 2: is that [PackageReference to Microsoft.SourceLink.GitHub] necessary?
I'm not sure. The docs suggest it is. But I removed the reference, re-built on Azure DevOps, and was still able to step through the library. Perhaps it's necessary for different environments (I'm keeping it just in case).
FWIW:
I'm debugging using Visual Studio 15.8.9
My latest installed .NET Core SDK is 2.1.403
My library's consumer is a .NET Core 2.1 executable
I compiled my library using Cake, which I have call into dotnet msbuild
I'm trying to build a .net core 1.1 project on vsts. The project is developed in vs2017 and it uses the csproj instead of project.json. I have tried multiple options to build id on vsts with the hosted agents (windows and linux).
i have tried the following build steps
Visual studio build
Set to use vs 2017 but i get a warning "Visual Studio version '15.0' not found. Looking for the latest version." And then i get errors because it cant include .net core packages.
.NET Core (PREVIEW)
Cant find project.json. When i set it to use csproj file it gives an error "The file type was not recognized"
Command build step
I tried to run the commands with command build steps. "dotnet build" gives the error that it cant find the project.json file.
Anyone building dotnet 1.1 with csproj on vsts that can help me how to do it?
In Visual Studio Team Services, go to Build & Release > Builds and click Edit for the build definition you want to update
Navigate to the Options tab, change Default agent queue to Hosted VS2017, and save.
You can download dotnet SDK manually and run dotnet build from command line.
So it could be something like this:
Inline PowerShell step (I've used Inline Powershell extension by Peter Groenwegen):
Invoke-WebRequest https://go.microsoft.com/fwlink/?linkid=837977 -OutFile $(System.DefaultWorkingDirectory)\dotnet.zip
Extract files step:
From: $(System.DefaultWorkingDirectory)\dotnet.zip
To: $(System.DefaultWorkingDirectory)\dotnet
Restore packages:
$(System.DefaultWorkingDirectory)\dotnet\dotnet.exe restore
... and so on
But there is some limitation — you still haven't had .Net Core 1.1 installed at build agent machine so some features may not work. At least dotnet test will fail because it requires appropriate .Net Core runtime. Maybe some other features as well.
extending on #Nikolay Balakin's answer, it's true the .NET Core projects using *.csproj are not supported yet.
You can work around this by installing the latest .NET core on the hosted build environment yourself.
This will allow running dotnet restore, dotnet build, dotnet publish, and dotnet test.
Use the Inline powershell extension to run a script. You can link to a script, or paste the text in inline. I am running a script which is checked in to the project.
It seems each powershell script will be run in it's own environment, so paths etc. will not persist between scripts, so the installation steps and the build steps need to be combined into one script.
You need to copy the dotnet installation script from github and add your own build commands to the end.
I know this is not a long term solution, but we justified it by assuming the VSTS will in the near future support the *.csproj files, and we will convert to use the official build task.
Here is an example powershell script, showing the last line of the installation script, and the custom build commands on the end.
...
...
Say "Installation finished"
# this is the end of the downloaded script, add your steps after here.
Say "Running dotnet restore AdminPortal\AdminPortal.csproj"
dotnet restore AdminPortal\AdminPortal.csproj
Say "dotnet publish AdminPortal\AdminPortal.csproj --configuration Release"
dotnet publish AdminPortal\AdminPortal.csproj --configuration Release
Say 'Zipping publish file'
$source = $env:BUILD_REPOSITORY_LOCALPATH
$source = $source + '\AdminPortal\bin\Release\net461\publish'
$destination = $env:BUILD_REPOSITORY_LOCALPATH
$destination = $destination + '\AdminPortal\bin\Release\net461\publish.zip'
Add-Type -assembly "system.io.compression.filesystem"
[io.compression.zipfile]::CreateFromDirectory($source, $destination)
Say "Publish finished"
dotnet test "AdminPortal.Tests\AdminPortal.Tests.csproj"
Say "Test finished"
exit 0
According to this issue .NET Core projects using *.csproj files are not supported yet:
https://github.com/Microsoft/vsts-tasks/issues/3311
"if you are using hosted agent - then the tooling there works only
with project.json files"
I've tried the tutorials here, but they also seem to be outdated (I couldn't even get tfx-cli installed on my machine):
http://mattvsts.blogspot.nl/2016/11/start-building-aspnet-core-11-with-tfs.html
In my case, I have a .NET Core web app and four library projects, all targeting the full framework since I'm using EF 6.
I tried all of the suggestions here and none of them worked. Building with Visual Studio Build on Hosted Agent 2017 does build the project, but doesn't output any binaries. And all the options above did build as well but didn't generate the output files.
Reading around I found the only way to get the output files was by running dotnet publishbut this generates a build error because nuget isn't restoring well the packages and msbuild can't find them. After being tired of trying to make it work during a whole day, casually I enabled the "Restore Nuget Packages" on the VS Buid task, and though it says it's deprecated, that seems to have solved my isse.
In VSTS you need to add netcore exists as a demand.
Go to your build definition
Click on the options tab
Add the demand netcore exists