I am developing an ASP.NetCore web application using Visual Studio 2017. Previously when I ran dotnet publish --configuration Release --output "path to output directory" I simply got the Project DLL and the Views DLL. All of a sudden I now get all of my dependency DLLs, such as Microsoft.EntityFrameworkCore.dll and AutoMapper.dll. Now my deployment folder is much larger as a result.
dotnet --version returns 2.1.500. I tried setting --self-contained false but it made no difference. Can anyone explain this behaviour please?
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 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'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 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.