i'm trying to setup appveyor with my .net project which is using devepxress the 3rd party library. unfortunately, i got this error message when i click build button.
Properties\licenses.licx(1): error LC0003: Unable to resolve type 'DevExpress.XtraCharts.ChartControl, DevExpress.XtraCharts.v16.1.UI, Version=16.1.4.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a' [C:\projects\pda-2000\MotionFake\MotionFake\MotionRealFake.csproj]
Command exited with code 1
I guess this is caused from no existence of devexpress dll file. how can i add/upload theses dll files to appveyor?
I believe this is nuget package. If yes, please run nuget restore at install or before_build stage.
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 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 install ASP.NET Identity 2 samples project. I open Visual Studio 2013, create an empty ASP.NET project, open Package Manager Console and type:
Install-Package Microsoft.AspNet.Identity.Samples -Pre
After some time of installing it returns an error:
Unable to uninstall 'jQuery 1.10.2' because 'bootstrap 3.0.0' depends on it.
Ok, I type the installation command again. This time the error is:
Failed to add reference to 'System.Net.Http'. Please make sure that it is in the Global Assembly Cache.
All subsequent attempts to install finish up with the same error.
UPD: I have installed the samples successfully using "Manage NuGet Packages" UI. Still interested why it have not worked in console? Have I done something wrong?
I downloaded the TFSBranchTool VS Extension Project.
Rebuilt and Installed, but when I try to apply Initial Structure I get the following Error:
Exection Error:
Exection of Action 'ConnectSourceControl' Failed. Details: Could not load file or assembly Microsoft.AlLMRangers.BranchTool.SourceControlWrapper......
Any idea what might be causing the problem ? I tried on 2 different Servers! , I got the latest Update of VS2012.
I got VS2012 SDK installed and Vs2012 ObjectModel too, not sure what I'm missing!
We have posted an update to the sample code on http://vsarguidance.codeplex.com/releases/view/96222, which addresses this bug.
The issue was that Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll was missed in VSIX package. As action execution engine using MEF to load actions, it has no direct references to actions implementation assembly.
Vladimir from the team fixed the issue by specifying assembly as the MEF asset in the VS extension’s manifest file. Now it’s redistributed inside the extension package.
Can you verify that you have the file Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll
in the following folder:
%LOCALAPPDATA%\Microsoft\VisualStudio\11.0\Extensions\Microsoft. ALM Rangers\TfsBranchToolVSExtension\1.0
If its not there - try deleting the TfsBranchToolVSExtension and re-install the VSIX.