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.
Related
Our development team implemented Pdfsharp in order to generate the pdf at website
they installed the pdfsharp package in a local environment with using this command at VisualStudio "Install-Package HtmlRenderer.PdfSharp -Version 1.5.0.5" it working fine
comes to production environment code is deployed through Azure DevOps CI/CD
when the build process creation we are implemented Nuget, NPM, and other steps.
now we added same line command in with .Net-CLI " add package HtmlRenderer.PdfSharp --version 1.5.0.5"-----> when I doing like it through the error message
Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
Dotnet command failed with non-zero exit code on the following projects :
I tried to install a pdfsharp package directly in webapp (API) using PowerShell
but I don't have an idea about installing the pdfshap in backend server level is it the right way or not is still ??
Please see the overview on how to use packages.
In short, you only install/add the package to the project once. This modifies the project, and you save the modified csproj into source control. Then on the CI machine, you run dotnet restore on your solution (if your solution contains only SDK style projects, nuget restore otherwise).
And for future reference, telling us that dotnet.exe returned exit code 1 is insufficient to understand the problem. dotnet.exe's output will contain additional error information about why it failed.
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'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
I have migrated my MSBuild-Integrated solution into Automatic Package Restore. It works on Visual Studio but when I try running the command
nuget restore Path/To/MySolution.sln
(I try doing that in my Package Manager console as well as in my Jenkins "Windows batch command" build step)
but in those cases I get an error The solution file has two projects named "1_2".
I cannot find these projects in my solution. Any ideas?
Sorry for not answering before but I ended up finding out that the solution had two websites created from the local IIS and they ended with a version number that was the same. Visual Studio named the project with this end only, which made this solution with two 'projects' with the same name. I could see it by looking in the sln file. Looks like VS does not treat this edge case :-/
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.