There is 20 sec delay each time I am running unit test in Visual Studio 2019. I have diagnostics test log turned on and I can see the delay is caused by many of those entries.
Failed to determine installation location for NuGet package <PackageName> referenced in project <ProjectName>. Check to make sure that a NuGet restore operation has been performed for this project and that no errors were reported during this operation.
I am using:
NunitTestAdapter 3.17.1 and custom nuget.config located in the same directory path as .sln file.
When I run the test in Visual Studio 2017 there is no delay
Why the test run trying to determine nuget package location? How to prevent this?
Related
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'am trying to create a build pipeline in Azure DevOps which contain a "vs test task". Nothing fancy here. I want to get the code coverage to send it to sonaQube. However, after the pipeline went through the task there is not .Coverage file created.
There is some errors that might be the issue but i'm not sure.
there is a big "Data collection : Could not find data collector 'Code Coverage'", This might be related to the fact that my UnitTestProject.dll is built for Framework 4.6.2 and Platform AnyCPU(for this issue I tried to forced: otherConsoleOptions:/Framework:NETFramework,Version=v4.6.2').
My agent is running on Windows server 2012 and Visual Studio Enterprise everything is up to date:
VS version
[command]"C:\Program Files (x86)\Microsoft VisualStudio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" #C:\Agent_AzureDevOps_1_work_temp\22f8bb11-e53e-11e9-95d5-5bdab8c29281.txt
Microsoft (R) Test Execution Command Line Tool Version 15.9.0
My .trx file is created, however, my .coverage file is nowhere to be seen.
I made sure Code Coverage was Enabled.
My package contain those NuGet
NuGet in my package.config
I'am blocked and don't know where to look anymore if you guys have an idea.
Thanks for the time. If you guys want more information don't hesitate to ask.
I do not have enough reputation to add a comment, so I hope this post will not be deleted (although it is not a direct answer, I think). I wanted to suggest you the following:
Do you have an own *.runsettings file (where you might have specified a specific entry? If you do not specify a *.runsettings file by yourself, the Azure DevOps vstest#2 Task will use a "default" runsettings file. At least this is what I could observe in the log (debug=true)
Hope this helps
BR Michael
I have a similar problem. I run this command :
>dotnet test --logger trx "--collect:Code Coverage"
Determining projects to restore...
All projects are up-to-date for restore.
MyAPI -> ...\MyApi\bin\Debug\net47\MyAPI.exe
MyAPI.Tests -> ...\MyAPI.Tests\bin\Debug\net47\MyAPI.Tests.dll
Warning: Update the Microsoft.NET.Test.Sdk package reference to version 15.8.0 or later to collect code coverage.
Test run for ...\MyAPI.Tests\bin\Debug\net47\MyAPI.Tests.dll (.NETFramework,Version=v4.7)
Microsoft (R) Test Execution Command Line Tool Version 16.10.0
Copyright (c) Microsoft Corporation. All rights reserved.
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Data collection : Unable to find a datacollector with friendly name 'Code Coverage'.
Data collection : Could not find data collector 'Code Coverage'
Results File: ...\MyAPI.Tests\TestResults\***_2021-09-03_12_02_21.trx
Passed! - Failed: 0, Passed: 22, Skipped: 0, Total: 22, Duration: 201 ms - MyAPI.Tests.dll (net47)
The .trx is generated, but not the .coverage.
The solution is to add the NuGet package Microsoft.NET.Test.Sdk in the test project.
The VSTS msbuild task seems to keep executing CoreCompile, despite the Clean option being disabled and the source files untouched (nothing changed in the source fetch).
Yet locally when I run msbuild locally or directly on the build machine, it behaves as expected - all unmodified projects are not rebuilt; CoreCompile does not run csc.exe.
I found that this was because the "TargetFrameworkMoniker" file that MSBuild generates and injects into the compile silently is written to the temporary directory, i.e. what you get when you run System.IO.Path.GetTempPath().
The VSTS agents however, specify their own temporary directory (_temp) and seem to clear it after every build. This seems like good behaviour - it's MSBuild that should fix it (IMO).
A quick and dirty fix, that may not work if your projects use mixed frameworks, is to add this MSBuild option:
/p:TargetFrameworkMonikerAssemblyAttributesPath=$(Build.Repository.LocalPath)\temp.moniker.cs
Alternatively, you can disable the file generation with:
/p:GenerateTargetFrameworkAttribute=False
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
I am trying to deploy Visual Studio 2012 SSDT project to Sql Server using TeamCity 8 and MSBuild Publish task but the deployment fails.
When I look at TeamCity logs and use /v:diag switch in my build configuration I see that for unknown reason MSBuild searches for MyProject.sqlproj.publish.sql and for MyProject.sqlproj.dacpac files.
The exact error:
[SqlPublishTask] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(1233, 5): File "C:\Program Files\TeamCity\buildAgent\work\abf8bc05a2cfe7f\*MyProject*\bin\Debug\*MyProject*.sqlproj.dacpac" does not exist.
The correct .sql and .dacpac files get generated (without the .sqlproj in the middel) in buildAgent/work/identificator/*MySolution*/MyProject/bin/Debug folder.
My TeamCity build step is configured as follows:
Runner type: MSbuild
Build file path: MyProject/*MyProject*.sqlproj
MSBuild version: 4.5
MsBuild ToolsVersion: 4.0
Run platform: 4.0
Targets: Publish
Command line parameters: /p:SqlPublishProfilePath="Debug.publish.xml" /p:Configuration=Debug
If I execute this from commandline I get no errors.
Any ideas on how can I configure TeamCity to search for correct files or configure my project to generate the files that TeamCity is searching for.
Or is my plan to use MSBuild's Publish task futile and I should utilise sqlpackage.exe instead?
UPDATE
After spending almost three days trying to figure this out I gave up and used sqlpackage.exe which works like a charm.
But I would still be interested in an answer though, passing paths to executables in build servers seems a bit crude way to accomplish things.
I had a similar issue and came to the conclusion that the way TeamCity produces "pseudo-project" files with *.teamcity suffixes is confusing something in the MSBuild/SSDT target chain.
I simply replaced the MSBuild runner build step with a pure Command Line step and the problem went away.
We lose the user friendliness of the TeamCity MSBuild runner configuration, but if it works, it's a compromise I'm willing to make.
Note - we are running TeamCity 7 - I am not sure if this has been addressed in later versions.
I found out you can set a System Property named "system.SqlTargetName" on the build configuration to override the default value.
Setting this to your project name without the ".sqlproj" makes the error go away.