I am trying to run an MSBuild task in atlassian bamboo for a test run of a Bamboo plan on my local device. I have created the plan and it will retrieve the code from Github successfully, as well as being successfully running the default scoure control checkout.
The first problem I have is that the system will fail because the MSBuild task cannot get the referenced files. So when I looked into the Manage Nuget Packages, It says some of the packages are missing, and when I click Restore most of them restore but some of them have errors.
I think the main reason is because of this package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -Version 1.0.0 is not being installed correctly. The error message says that it is because the path, file name or both are too long, but I have not named anything the project is already build and running successfully from Github. I have tried to install as well by using the Package Manager Console but I get the same result. I also tried creating the folders that it said the file was meant to be located but this is not working either.
I think that the problem is that the package is not found during package restore so I tried to add a NuGet.config file.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
But this is not working how can I fix this?
According to the error message screenshot, the mentioned package "Carfinance.Authorization.Core.Mvc" is not found in nuget.org site. Please make sure this package's source URL has added into your Visual Studio NuGet Package Manager Source list (Tools -> Options -> NuGet Package Manager -> Package sources).
And please add the node in the global NuGet.Config file which stored in C:\Users\UserName\AppData\Roaming\NuGet folder. After change the config file, please remember restarting your Visual Studio.
For the Microsoft.CodeDom.Providers.DotNetCompilerPlatform path too long issue, please make sure the stored path folder is not too long. You could create a new project and store it on desktop and install this packages to check whether it could be install correctly. Then please copy your current project on desktop too, it could make sure its stored path will not too long.
Related
I had a package source named MyMyGetFeed, I changed its URL but it still looking at the old one, even after deleting it I can still see that visual studio is looking into it as shown in the error message below, I'd also tried to create new package source with the new URL and it is still showing the same error neglegting my new source. Cleaning project, restarting Visual Studio and even deleting NuGet.Config file didn't help. Any Ideas please?
Severity Code Description Project File Line Suppression State
Error NU1102 Unable to find package Synergix.WE.Security.Cryptography with version (>= 2.1.3)
- Found 3 version(s) in MyMyGetFeed [ Nearest version: 2.1.2 ]
- Found 0 version(s) in nuget.org Synergix.ADCE.Client.Service.Commands C:\Users\MOHAMMAD\source\repos\adce.client\src\Service\Synergix.ADCE.Client.Service.Commands\Synergix.ADCE.Client.Service.Commands.csproj 1
Visual studio 2019: Adding, Updating or Deleting Package Source Has No
Effect
First, if you add the new package source by Tools-->Options-->Nuget Package Manager-->Package Sources(global nuget.config file), you should make sure that there is no other custom nuget.config in your solution explorer to affect the global nuget.config file. See this.
Besides, you can follow the below steps to troubleshoot your issue:
you should make sure that the new package source url is enable and the old package source url is deleted or unchecked like this:
In global nuget.config file(C:\Users\<User>\AppData\Roaming\NuGet\) like this:
<packageSources>
<add key="new package source" value="C:\xxxxxx" />
<add key="old package source" value="C:\xxxxxxx" />
</packageSources>
<disabledPackageSources>
<add key="old package source" value="true" />
</disabledPackageSources>
From the error message, it searches for version 2.1.3, so make sure that Synergix.WE.Security.Cryptography 2.1.3 is in the new package source url and you have the right to access the new package source. To test it, you can copy the link in website to see whether it can return any request.
clean nuget caches under Tools-->Options-->Nuget Package Manager-->General-->Clear All Nuget Caches or just delete the packages folder under C:\Users\xxxx\.nuget.
And run nuget locals all -clear under Tools-->Nuget Package Manager-->Package Manager Console
disable any third party extensions under Extensions-->Manage Extensions in case it causes this abnormal behavior.
close VS instance, delete .vs hidden folder, bin, obj folder, 'Nuget.Config' file under C:\Users\<User>\AppData\Roaming\NuGet\(will recreate automatically when restart VS)
and then run VS as administrator to test whether the issue persists.
In addition, try to create a new default project and then install this package to test whether the issue is your project itself or is the nuget tool.
How do I disable "transitive package management"?
I wish to do so, so that I can install a package that I "packed" locally and have in a .nupkg file. When I attempt to do so, I get a messaging stating that The 'Source' parameter is not respected for the transitive package management based project(s) {csproj file}. The enabled sources in your NuGet configuration will be used.
Complete Context
When developing a NuGet package that's not ready for distribution via our NuGet feed, I often create a local .nupkg file like this from the package manager console:
nuget pack {path-to-csproj-file}
This generates a {project-name}.nupkg file, which I can then install in another project by opening it in Visual Studio, navigating to the package manager console, and entering the command
Install-Package {path-to-nupkg-file}
This has worked great and once the NuGet package is ready for distribution, we push it up to Azure DevOps and let the build pipeline there push it into our feed.
However, I just recently inherited a project where the prior developer apparently setup "transitive package management" that prevents this workflow. Here's what I get when I try to install directly from a .nupkg file:
Install-Package C:\Users\Josh\source\repos\SpeakerDiscountManager\SpeakerDiscountData.1.0.5.nupkg
The 'Source' parameter is not respected for the transitive package management based project(s) MembershipApplicationWidget\MembershipApplicationWidget.csproj. The enabled sources in your NuGet configuration will be used.
<snipped several lines of unsuccessfully searching configured package sources>
Install-Package : NU1102: Unable to find package SpeakerDiscountData with version (>= 1.0.5)
Obviously, it doesn't find the package I've specified via file, because it is searching online feeds and it doesn't exist in any of our online package sources--the package is in a testing state, not ready for anyone to use but me.
Based on the error message, I need to turn off "transitive package management" so that I can specify a file source for the package, but I've been unable to turn up any information online about how this is configured.
I did try installing this exact same .nupkg file in another project, using the same Install-Package {path-to-nupkg-file} procedure. This works.
How to disable “transitive package management” for a Visual Studio
project
I think this problem transitive package management is related to your current project structure which has some intricate dependencies, custom rules and so on. Therefore, turning off transitive package management is unpractical. If you create other projects and then install this package by your way, I think it probably will not occur.
As a best workaround, as you said(hint from the message The enabled sources in your NuGet configuration will be used.), add the the local nuget package's path into Nuget Package Source.
In your side, I think you specify -Source xxxxx(the path of the nuget package) to install this package in the package manager console, if so, this function actually is inconvenient.
You can just add the folder path which SpeakerDiscountData.1.0.5.nupkg exists into global nuget package source. Once you have done it, it will applies to any projects in this machine.
It has two ways:
1) VS IDE UI
Tools-->Options-->NuGet Package Manager-->Packages Sources-->add a new key and input the path of the nuget folder. Also, check its option.
2) global NuGet.Config file
(C:\Users\xxxx\AppData\Roaming\NuGet\Nuget.Config and step 1 is just add the path into this file by VS UI Control)
add these:
<packageSources>
<add key="Local Packages Source" value="C:\Users\Josh\source\repos\SpeakerDiscountManager\" />
..........
</packageSources>
After that, you can use your command to install this nuget package.
Note: If the root directory of your solution also has a file named nuget.config, the parameters in it will override the global file. It has the highest priority.
Just go to Vs IDE Tools/Nuget Package Manager/Package Manager Setting And Check The address of Package Sources.
it's something like "C:\Program Files (x86)\Microsoft SDKs\NuGetPackages".
Then Copy your package file into that folder and at last run this command in Package Manager Console:
install-package packagename
I have a set of Nuget Libraries that I compile and modify myself.
I build them without publishing on any Nuget server. (It is not my library)
On the other side, I have a project that use such Nugets, but I wish to debug them...
In the best situation I wish to:
use my local .dll and .pdb
debug by using local .pdb and (updated) source code
I'm looking for the best possible solution, if possible by loading all local symbols,
but I'm not sure it is possible.
Maybe I have to build on my own local Nuget server and use a local Symbol server too, but it looks overkill?
Maybe I have to build on my own local Nuget server and use a local
Symbol server too, but it looks overkill?
As far as l know, when you want to debug a nuget library in a new project, you must add the required nuget.pdb and related xxx.cs source files in the new project.
According to your description, the nuget package is created by yourself which is more easiler to realize it:
1) If you have the nuget.pdb file and the corresponding cs file on the local, you just need to put the PDB file in the output file of the project which references the nuget, and then right-click on the Solution-->Properties-->Common Properties-->Debug Source Files-->to add the folder path which the cs files exist into it.
2) If you do not have the current nuget.pdb file and related cs source files for debugging on the local, you need to include these files in nuget.nupkg when creating the nuget package by using nuget.exe cli with xxx.nuspec, so that these files can be added to the current agent when you install the nuget package.
**Note:**This is the special steps for creating your nuget package:
A) please make sure that you have downloaded the nuget.exe and then set its path to environment variables so that it can be called in CMD. You can refer to this.
B) Open CMD, type cd xxxxxx(the path of the project which contains xxxx.csproj)
C) type nuget spec to generate the xxx.spec file
Then open it and add like these:
<?xml version="1.0" encoding="utf-8"?>
<package >
<metadata>
........
</metadata>
<files>
<file src="bin\Debug\ClassLibrary11.pdb" target="lib\target framework version (like net472 or netstandard2.0)" />------ClassLibrary11.pdb is the nuget.pdb
<file src="Class1.cs" target="src" />------Class1.cs is the source file
</files>
</package>
D) then type nuget pack to generate the nuget package which contains these debug files.
E) when you install this nuget package in a new project, please do not forget to clean the nuget cache first. After that, you should add the path of the resource files into Debug Source Files.(the resource files exists in the C:\Users\xxx\.nuget\packages\package name\src or C:\xxxxx\ConsoleApp(project folder)\packages\package name\src)
Edit
F) When you start debugging it, please do not forget to disable Just My Code In Tools-->Options-->Debugging-->General-->uncheck Enable Just My Code.
Also, you can consider source links as source control so that you won't configure the source path by Solution=>properties.
In addition, you can refer to this similar issue.
OK,
So i recently reinstalled windows 10 and upgraded vs2013 -> vs2015. At this point i tried to grab a couple of nuget packages.
The problem i am having is that i have a .nuget/packages folder at the same level as my solution file (set via NuGet.config) but i also have exactly the same folder getting created in the root of my user folder.
the packages folder for my solution contains the packages installed for that solution, while the one i don't want in my user directory contains all the packages for all the projects and solutions i am working on.
Is there a way i can prevent this .nuget folder being created in my user directory? it seems useless when i already have package folders for my solutions
Thanks
You can clear the .nuget\packages directory under your user profile however the packages will be downloaded again if you install them again.
Package retrieval
%USERPROFILE%\.nuget\packages is the local machine cache used by NuGet v3 when installing NuGet packages for new project types, such as Universal Windows projects.
For a C# console project NuGet will use the %LOCALAPPDATA%\NuGet\Cache directory which is also what NuGet v2 uses.
ASP.NET Core projects currently use their own %USERPROFILE%\.dnx\packages directory for NuGet packages.
Specifying a custom NuGet package location
To prevent NuGet from copying the packages to your user profile you can create a new %NUGET_PACKAGES% environment variable pointing to the location where you want NuGet to copy the files e.g. C:\git-repositories\.nuget\packages.
To prevent NuGet from copy the packages to the solution folder too you can create a new NuGet.config file either in the solution folder or at any higher level up to the root. As content you can specify following XML.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="C:\git-repositories\.nuget\packages" />
</config>
</configuration>
As help for configuration inheritance please follow this link: NuGet Configuration Inheritance
We have successfully set up a couple of local package repositories using the NuGet.Server package and hosted them on a local IIS webserver. We are able to connect from the Package Manager and install no problem. So these are working fine.
In order for us not to have to check in our packages folder we have included the following command line in each project file that includes NuGet references. This works, if the NuGet.exe is in the path on the CI build agent.
However, I would like to move the source configuration form the command line in every project file and put it in just one place, preferably where other pesky developers can't change it ;)
<Target Name="BeforeBuild">
<Exec Command="nuget install $(ProjectDir)packages.config -s
http://domain:80/DataServices/Packages.svc/;
http://domain:81/DataServices/Packages.svc/
-o $(SolutionDir)packages" />
</Target>
Is there a better way?
Yes there is ;-)
Take a look at NuGetPowerTools. After running Install-Package NuGetPowerTools, it adds a .nuget folder to your $(SolutionDir) containing nuget.exe, nuget msbuild targets and settings (which you will need to check in).
After that, you simply run Enable-PackageRestore and it sets up msbuild targets into your visual studio project files which will make sure that packages will be fetched in a prebuild step, even on your build server, without checking in any packages. (don't forget to check in the .nuget folder though!).
This way, you simply manage the nuget package sources in a nuget msbuild settings file (in the .nuget folder) central to your solution, instead of in each project.
Cheers,
Xavier
I finally got NuGetPowerTools to install after the advice from digitaltrust on http://blog.davidebbo.com
Although NuGetPowerTools solved my problem, it was overkill for what I wanted. It requires that you check in to version control a .nuget folder that it creates in your solution root. The folder contains NuGet.exe, and a couple of target files. I don't like this as I think version control is for source code, not tools.
I came up with the following solution.
Save NuGet.exe to a folder on your local drive, both on dev and continuous integration machines. I chose C:\tools\nuget\
Add that filepath to the Path Environment Variable in all environments
On continuous integration machines, find %APPDATA%\NuGet\NuGet.Config and enter the following
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="LocalRepositoryName" value="http://Domain/DataServices/Packages.svc/" />
</packageSources>
You can add more than one entry to packageSources and NuGet will search them in the order that they appear
The after build code from my question can now be amended to the following.
<Target Name="BeforeBuild">
<Exec Command="nuget install $(ProjectDir)packages.config
-o $(SolutionDir)packages" />
</Target>
The end result of this is that whenever the approved repository location is changed, the config has to be changed in only one place rather than in every csproj file. Also, it is the continuous integration server administrators who determine that location, not the developers in their command line calls.