I have a build step in my CI pipeline where I restore the NuGet packages for my solution. I am retrieving my NuGet packages from a NuGet hosted repository on Sonatype Nexus. The package restore itself is running smooth enough, but it hangs in a step where it takes almost 2 to 3 minutes to verify some packages(in this case packages provided by Microsoft). The build agent where I have this restore done does not have internet access. And that's why I am also using a NuGet proxy on my Sonatype Nexus.
For example the step that it gets hanged on is:
PackageSignatureVerificationLog: PackageIdentity:
Microsoft.Owin.3.1.0 Source: ...nuget\packages\
PackageSignatureValidity: True
I have considered adding a list of trusted-signers to the nuget configuration of my builds. But since my machine does not have internet access, this wouldn't be very helpful. As described in the Microsoft documentation:
https://learn.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-trusted-signers
As described in the https://learn.microsoft.com/en-us/nuget/reference/nuget-config-file
I also tried setting the signitureValidationMode to <add key="signatureValidationMode" value="accept" /> which in this case will verify the packages by default. Even though this is the default case, and accepts them if it does not succeeds to connect. But this does not change the speed of my NuGet restore.
Besides opening up network access for all the NuGet verification URLs my solution would need.
Is there a way that I can set the NuGet configuration to not verify the certificates of the NuGet packages in an offline mode for my build agent?
After some digging around I found the following Microsoft document.
Which explains the possible slow down issue that might occur on an offline machine(such as a build agent) and a possible solution.
The issue can be resolved by implementing the Environment variable NUGET_CERT_REVOCATION_MODE to offline.
NUGET_CERT_REVOCATION_MODE = 'offline'
In a tool as Jenkins, you can declare it in the environment variables, or you can run a command on the build machine to set the environment variable.
Related
I have a repo where is several libraries (csproj projects) which are published into a private NuGet feed hosted by Azure DevOps. They are consumed by other project in my company.
Current state
A push pipeline for each library which pushes NuGet into the private feed. These pipelines are triggered by
trigger:
branches:
include:
- master
paths:
include:
- MyCompany.Product.PackageName/*
During PR, another simple build pipeline that checks the build of the new package version. The PR can't be merged if this build pipeline fails. The new package version gets pushed into the feed when PR is merged into master.
The problem is that no version check in the build pipeline. During the PR, the developer doesn't have any information if the push pipeline would be successful or not.
I would like to do an automatic check if the package can be pushed into the private feed.
Desired state
When some developer opens a new PR, the build pipeline tells him/her that the package can't be pushed into the feed because (s)he forgot to update a package version.
My idea was create a project-specific build pipeline and employ PowerShell for some magic version check which fails if there is a duplicate in the feed.
What would be a proper strategy for this task? Does anybody applied some successful solution for this? Some pipeline examples would appreciated.
When you push a package version into the specified feed, if the version is duplicated with an existing version in the feed, normally the push will fail with an error for the duplication of the versions. Then you just need to changed the package version and try the push again.
If you want to check the package versions before the push, in the build pipeline you set to check the package versions, you can try like this:
Get the current version of the package you want to push. Generally you can read the version from the csproj file or the relate NuGet configuration files (such as .nuspec).
Use the 'nuget list' command to list all the existing versions of the specified package in the feed.
nuget list <PackageName> JSON -AllVersions -Source "https://pkgs.dev.azure.com/<Organization>/<Project>/_packaging/<FeedName>/nuget/v3/index.json"
If the Scope of the feed is Organization, omit '<Project>'.
To get the Source URL, open Azure Artifacts in your team project on DevOps, switch to the feed where the package is, click Connect to feed > NuGet.exe, then you can see the Source URL.
Check whether the package version you want to push is included in the listed package versions.
I have created a very simple NuGet package from a .net framework visual studio Class Library project, where the class library source is in C#.
I used this command to create the nuget package:
nuget pack MyProject.csproj -symbols -Properties "Configuration=Debug" -suffix debug
Which creates, as I expect, two nuget package file, namely:
MyProject.1.0.0-debug.symbols.nupkg
MyProject.1.0.0-debug.nupkg
These packages are basically identical other than that the one with "symbols" includes the pdb files in the lib hierarchy and source files in the src folder.
Given the duplication, I rename the file MyProject.1.0.0-debug.symbols.nupkg as MyProject.1.0.0-debug.nupkg, which overwrites one of the files, no big deal there. I now have a conventionally named package with PDB and source files in it.
I deploy this to an internal file share feed with:
nuget add MyProject.1.0.0-debug.nupkg \\InternalShare\FeedFolder
In an entirely different project, and a different solution, I now consume that NuGet package in Visual Studio with the NuGet Package Manager. All works great. And the code works fine too, in my case I made a simple console app that uses a couple of classes in the package and I have demonstrated that it uses them correctly and without incident.
So far so good.
Now I set a breakpoint in the consuming code, and attempt to step into the source to debug the package. It seems to work OK, but actually, it isn't going into the source that was distributed with the package. It actually steps into the ORIGINAL source from the creation of the package, in a completely different and unrelated folder hierarchy on my machine.
OK. So now I recreate my simple console app on a separate computer that does not have the ORIGINAL source. And on that separate computer, which is on the internal network and hence has access to the file share, I consume the NuGet package and again, everything compiles and works fine.
When I try to step into the package source code in the visual studio debugger, however, it simply doesn't work. The debugger can't find the source code even though it is right there in the package folder. (The debugger offers to disassemble the code -- not so helpful).
This seems like it should be a common use case and desire for including symbols and source code in a nuget package, so I must be doing something silly such that the debugger can't find the source.
Various versions of things:
Visual Studio: Professional 2017 15.9.11
NuGet Package Manager installed in VS: 4.6.0
CLI NuGet version: 4.8.1.5435
Targetted .NET Framework for my sample code: 4.6.1
What is my mistake?
Many thanks in advance.
================== ADDED INFO 4/17/2019, 3:30pm Pacific =======================
This isn't quite as bad as I thought. When I try to go into the code and says it can't find it, I am given the opportunity to browse to the code, so I can browse to the package (assuming I know where it is!) and set the debugger loose and everything works fine. The nice thing is that Visual Studio seems to remember where I browsed to and knows to look there next time. Not sure of that mechanism.
AND.... If I go to my original computer (with the actual package source on it) if I change that initial source, like I am getting ready for the next package, the debugger (of course) realizes that the source has changed, and likewise prompts me to look for the proper source elsewhere.
Still, it would be great not to have to jump through hoops like that, so I would still appreciate any further insights.
Back in Feb'2019 it was working. Few things which are not mentioned here and I added to csproj file are
<DebugSymbols>true</DebugSymbols>
<EmbedAllSources>true</EmbedAllSources>
<DebugType>portable</DebugType>
I packaged with nuget and command used is:
nuget pack mynuget.nuspec -Symbols -SymbolPackageFormat snupkg
I was using VS 15.9.4 and nuget 4.9.3 at that time With this I could successfully debug nuget from network path . Not sure what changed in recent releases, its not working now.
Some fundamentals:
the debugger needs PDBs to enable debugging
a symbol package should contain PDBs (it is not merely a package with a different extension)
this symbol package should be published to a symbol repository that Visual Studio debugger can request symbols from
Next:
See this doc for creating and publishing symbols package to nuget.org (.snupkg)
Then, see this doc for configuring visual studio to for using NuGet.org as a symbol source (use this value when adding a symbol server https://symbols.nuget.org/download/symbols)
I have a Visual Studio Solution (multiple projects) which was able to build on another computer in the past, that can't build after being pulled with Git on a new computer. The IDE (VS2017), platform target (Any CPU), .Net Framework (.Net 4.6.1), ... and everything else should be the same, yet it gives a few "The type or namespace name 'nameOfTypeOrNamespace' does not exist in the namespace" errors. There're also a few "Metadata file 'pathToFile.dll" could not be found" errors. Example screenshot:
Most of the missing assembly's are self-written but there are a few which are thrid party, as seen in the solution explorer. I also don't seem to have a reference folder in the solution anymore:
I know there's already a few questions involving missing namespaces, but none seem to match my particular case. I've already checked references and namespaces but can't seem to find the problem (no typo's eithersince it worked before). It's probably really hard for someone to find the problem without the project, which I can't share, so my question:
How should one best search for the solution?
I've also checked my .gitignore file and verified that it shouldn't have caused this issue.
Update as said in the comment section: I'm using Nuget but the Restore Nuget Packages option does not work out.
I currently solved this issue by doing the following:
Remove packages from the .gitignore-file
Open a cmd and type the following Git commando's (be sure to commit all your changes first since you might lose them by executing following commands):
a. git rm -r --cached . (clears the cache so that Git can detect changes)
b. git add . (adds all changed files)
c. git commit -m "Fixing the packages issue" (commit the changes)
Keep in mind that this is only a quick fix or a hack and that this doesn't actually solve the issue.
#Wouter's solution is working but as he said it's not optimal way and cause huge amount of source control storage occupied as well as increase download and upload size in push and pull(Checkin and Checkout in TFS).
To restore packages if 'Restore Nuget Packages' not works, use this solution:
From Tools menu in Visual studio, chose NuGet Package Manager--> Package Manager Console
and run this command:
Update-Package –reinstall
I hope It works.
I have a problem with visual studio 2010. It stopped building projects.
I had a problem with error:
Error occurred while restoring NuGet packages
I did Solution properties -> Enable NuGet Package Restore
And this result that build does not happen. If i click build or rebuild
all I get is:
------ Rebuild All started: Project: MyProject, Configuration: Debug Any CPU ------
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
I have tried:
- cleaning, rebuilding
- restarting VS
- rebooting
- Tools -> Options -> Projects and Solutions -> Build and Run and set MSBuild project build output verbosity to Normal, Detail, Diagnostic each with zero results. The only output is the one above.
It also finishes immediately, usualy it took some time. What is wrong here? How can I fix it?
UPDATE
I have tried command line build and in the output i find:
D:\MyProject.nuget\NuGet.targets(100,9): error : Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, publicKeyToken=b77a5c561934e089'.
It looks like nuget issue.
NuGet automatic package restore has changed in version 2.7+ see NuGet documentation for restoring packages and new approaches. Also take a look at common issues .
Without knowing all the information of your setup based on the documentation they advise to choose one approach to avoid problems.
Common issues with Automatic Package Restore
If you have Nuget 2.7+ installed; it's important to pick one method for managing Automatic Package Restore in Visual Studio.
Two methods are available:
(Nuget 2.7+): Visual Studio -> Tools -> Package Manager -> Package Manager Settings -> Enable Automatic Package Restore
(Nuget 2.6 and below) Right clicking on a solution and clicking "Enable Package Restore for this solution".
These are different methods; and have drastically different outcomes for developing with NuGet.
Otherwise look at not having NuGet perform an automatic package restore.
Update based on comment:
The error you are receiving does not give you a lot to work with except that their are known issues if you are using both approaches to restore packages.
Try a couple of things, so you can find the root cause of the problem and resume building your solution.
Delete your solution folder locally and get the latest from source
control or last known good build. If this is not an option then back up your solution and related folders and look at free version control solutions.
The suggestion to delete the packages folder was because NuGet will
not find the needed references and make an attempt to get the needed
references. Perhaps by deleting the packages folder it will give the
exact reference it cannot restore.
Verify the way your solution is using package restore and make sure
you are only doing one or the other based on the NuGet documentation
provided in the link above.
Test if you can build another solution that has NuGet or create a simple solution and add one to test.
If all else fails remove NuGet and add your references manually. Then
start adding back NuGet packages one at a time.
Try to delete the packages folder and rebuild.
I am trying to set up a project in our CI server (bamboo).
I have an API solution containing multiple projects (data access, service interfaces, WebApi, tests, a few others... you get the idea). I run nuget.exe in a script to pull in the requisite packages at the solution level. The packages go into the solution directory .nuget.
When I use MSBuild to create the binaries, everything is fine. I then use the MSTest runner on the test projects; still everything is fine. I then shut down the destination web service, and then run msbuild.exe against the WebApi project with the parameters /p:DeployOnBuild=true /p:PublishProfile=INTENV.
This is where bamboo barks at me. I get the failure error message like so:
error : This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\(My Solution Folder)\\.nuget\NuGet.targets.
The project is obviously looking for the dependencies in the project folder, in this case and in this case only.
How do I tell MSBuild.exe that this folder is one level up? This is the only place where it gets confused.
So what was happening when I targeted the project instead of the solution with MSBuild.exe is that it considered $(SolutionDir) to be the project directory. It was looking for the the nuget targets at $(SolutionDir).nuget\NuGet.targets, which was an incorrect path if starting at the project level, but perfectly fine at the solution level.
On my MSBuild.exe command line, I added a parameter as follows:
/property:SolutionDir="(path of my solution)"
This did the trick.
I also tried to change the project settings, but NuGet always replaced them; the above manner is the only way I could get it to work.