I have a C# solution containing several projects. Some of projects has referenced nuget packages. Whole solution (but no downloaded dlls) is tracked by git repository.
After cloning it to other place and trying to build nuget asks if it should download missing packages. After downloading there are still several referenced library missing.
I can fix it one by one doing following steps:
Remove reference
Remove package in packages.config file
Install this package again by nuget
Is there any better way to do this? I tried reinstalling all nuget packages, but my Visual Studion crashes. After restarting and retrying it left me with more missing packages.
Another way to do this is running:
PM> Uninstall-Package {Name}
PM> Install-Package {Name}
for each missing package. By missing package I mean all packages with yellow mark. I can't install it without uninstall command, becasue nuget says it is already referenced.
If you try running the following from the command line does it restore all the packages?
nuget.exe restore YourSolution.sln
If not then it sounds like there's some packages that are missing from your project's packages.config file.
You could try the updating the packages with the reinstall parameter from the PowerShell console.
Update-Package –reinstall <packageName>
You can also restrict this to one project if you want to by using the -ProjectName parameter.
This is probably because of the incorrect path of the .dll in your .csproj. The package restore downloads the packages to the local directory.
It doesn't change the reference path of the assembly in the .csproj, meaning that the project will still try to locate dlls on the local directory. The yellow mark means the project is unable to locate the assembly.
Unload the project, right click on project and select "Edit .csproj", and verify the path of missing dlls.
For example - If you have NUnit,
<Reference Include="nunit.framework">
<HintPath>..\packages\NUnit.3.6.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>
verify if the dll is present inside "\packages\NUnit.3.6.1\lib\net45" directory.
Related
I have a fairly messy website project in C#
It has the layout of
Foo-EUR
Foo-EUR-Web
Where Foo-EUR has a csproj file and Foo-EUR-Web does not. It's just a website.
To get this to build locally I need to go to the Package Manager console for nuget and enter:
Update-Package -reinstall -project Foo-EUR-Web
This then copies all the dlls to the folder Foo-EUR-Web\Bin
If I don't do this, I get the error:
error ASPCONFIG: The CodeDom provider type "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=3.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" could not be located.
My problem is I'm trying to build this on github actions. I don't have Update-Package available.
I've tried
nuget restore src/Foo-EUR.sln
nuget restore src/Foo-EUR/packages.config
nuget restore src/Foo-EUR-Web/packages.config -PackagesDirectory packages
Nothing is working.
I think the issue is because there is no csproj, but adding one would be problematic.
Is their a way to install the Nuget Package manager into powershell as a github action to allow me to run Update-Package to get this to build ?
Or is there something else I'm missing here with nuget?
The framework version is 4.6.1
I followed this blog post and I expected Nuget to just work. It obviously has not. I get errors on all of my third party dll's that I expect NuGet to update automatically:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\
Microsoft.WebApplication.targets (182): Could not copy the file "bin\AutoMapper.dll"
because it was not found.
I have set everything up correctly and I have ensured that the solution has Package restore enabled. If I delete a package locally and build, NuGet restores that package for me.
I am not sure why it is not fuctioning on the build server though.
Any Suggestions?
Try to add NugetRestore Activity to the TFS workfolw
Note:
For Team Foundation Build 2013 on-premises and Visual Studio Team Services (formerly Team Foundation Service), the default Build Process Templates already implement the NuGet Package Restore workflow without any special configuration.
I came across a similar error for log4net nuget package and I solved it in a different way. May be this will be useful to someone some day.
The error from TFS Team Build 2015
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\
Microsoft.WebApplication.targets (182): Could not copy the file "bin\Log4net.dll"
because it was not found.
Cause
The path to the nuget package in the .csproj file for referencing the package in the project cannot be found
Resolution
Edit the .csproj file of the project that has the error.
Look for the node ItemGroupin the .csproj file
You will see the HintPath pointing to a folder, most like the folder contain the name of solution as where it will file the DLL.
Replace the HintPath with <HintPath>..\..\Assemblies\3rd party\log4net\1.2.10.0\2.0\log4net.dll</HintPath>
You nuget package library may not be log4net but a different library. A very easy way would be to be edit the .csproj file of a project in the solution that contains the same nuget package library, copy the reference of the nuget in the ItemGroup and replace in the project that has the error. The reference should start contain ...\Assemblies\3rd party\ ... instead of a physical file location on your machine
I am running a private Nuget Server locally on IIS.
I am creating packages and uploading them all via commadline using nuget.exe (Later on I have to put this on build server, hence the command line). However there is one issue I am stuck at.
I am trying to declare dependencies. I generate the nuspec file in the folder where the .csproj file is there. Then I manually edit the nuspec file to add this under the metadata tag:
<metadata>
<dependencies>
<group targetFramework=".NETFramework4.5">
<dependency id="DemoProject" version="2.0.0.0" />
</group>
</dependencies>
</metadata>
DemoProject, version 2.0.0.0 is present on the Nuget Server.
The project I am creating package for, MyProj.csproj does not have the reference to the DemoProject added to it via Visual Studio. It is just at the packing time I want to create the dependency. It sounds strange but is needed for some initial validation.
Then I run pack command:
"C:\nuget\NuGet.exe" pack MyProj.csproj -IncludeReferencedProjects -Prop Configuration=Release
Then I push it to NuGet server using command line.
When I do an install via command line, then only MyProj package is present at the install location.
When I use Nuget Package Explorer and create a package, I can use the Package Dependency Editor to specify the dependency. It asks for the URL of my local Nuget Server and then adds the dependency. And when I install that package, it works !!
There seem to be no difference in the generated nuspec file in both the cases.
Obviously Nuget Package manager is doing something which I am missing out on.
Any hints?
More details: When I create a lib folder in the Package manager console and put my dll manually, lib->net45->MyProj.dll, then when I install the package thus created also "does not" install the dependency. Back to reading documentation again.
I know this doesn't directly answer your question but I had an issue with NuGet dependencies and my solution may possibly provide a hint.
DLL#1 was had no NuGet Dependencies. Pushed that to my private repo.
DLL#2 referenced DLL#1 NuGet package. Pushed that to my private repo.
All fine and dandy except from the Application project when I go to "Manage NuGet Packages...", the NuGet Package for DLL#2 is listed on the Browse tab but it shows no dependencies. I was forced to install both DLL#1 AND DLL#2 nuget packages. I desired to install DLL#2 nuget package and get DLL#1 automatically.
The way I fixed this was uninstalling all NuGet packages from DLL#2 solution.
Then going to Tools > Options > NuGet Package Manager > General. Then set the Default package management format to Packages.config and then unchecking the option "Allow format selection on first package install".
Then i installed all the needed NuGet packages. Now when i pack it up and push it up to the server, it shows the proper dependencies when going to "Manage NuGet Packages...".
nuget pack doesn't see the dependencies because its looking for them in the \packages folder. That folder didn't exist because I was using PackageReference for package management.
All worked after switching to Packages.config for package management.
I know the problem I had wasn't the same as yours but if you're not using Packages.config for package management, perhaps its related.
Late answer but the issue with this nuspec is <group targetFramework=".NETFramework4.5">. I feel confident that ".NETFramework4.5" is an invalid targetFramework. A full list of the available Target Frameworks is here.
When working with the Dependency section, you may not need to use the group tag. Any users who encounter similar errors would do well to read through that section. They have samples of proper usage.
I'm using Visual Studio Online with Visual Studio 2013. The build fails with
You are trying to build with OctoPack, but the NuGet targets file that OctoPack depends on is not available on this computer. This is probably because the OctoPack package has not been committed to source control, or NuGet Package Restore is not enabled
According to this link https://octopusdeploy.com/blog/octopack-3.0 I need to make some changes to get package restore working properly, but another link within the previous one says that no configuration is required if using VS2013 and Visual Studio Online Nuget.org
When I build in VS all of the packages get restored first and then the project builds. Also if I build the project and invoke Octopack via command line everything works fine. Thoughts?
If you do run NuGet Package Restore before building, this should work. However, make sure the path in your project file referring to OctoPack.targets is correct - you might have moved your packages folder or the project file and the relative paths no longer match. Easiest way to fix it would be to run Update-Package -Reinstall Octopack.
NuGet Package Restore was recently changed so you wouldn't need to include NuGet in the solution to do a package restore. However, OctoPack still needs NuGet on the path so it can find it. You can try explicitly specifying the path to NuGet by adding this parameter when calling OctoPack.
/p:OctoPackNuGetExePath=<path>\nuget.exe
You just need to check in the Octopack targets file.
\packages\OctoPack.2.0.26\targets\OctoPack.targets
I'm trying to get nuget package restore working in a solution that is looking for packages in the regular, public nuget feed and in a local feed located on a shared network drive.
What I've tried so far is enabling nuget package restore on the solution, then editing the Nuget.targets and changing the PackageSources variable, but that doesn't seem to work. Is this possible?
My Nuget.targets file looks like this for the package sources section:
<ItemGroup Condition=" '$(PackageSources)' == '' ">
<!-- Package sources used to restore packages. By default, registered sources under %APPDATA%\NuGet\NuGet.Config will be used -->
<!-- The official NuGet package source (https://nuget.org/api/v2/) will be excluded if package sources are specified and it does not appear in the list -->
<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="\\mynetworkshare\Development\NugetPackages" />
</ItemGroup>
The error I get on build is "Unable to find version '1.0.0' of package 'MyCustomPackage'. I have verified that the nupkg exists at \\mynetworkshare\Development\NugetPackages\MyCustomPackage.1.0.0.nupkg.
The fix for me was bhuvak's answer plus I had to rename some packages.
I had been creating symbols packages (named similar to MyCustomPackage.1.0.0.symbols.nupkg) and using those from my local package feed folder. However, package restore doesn't seem to pick those up. I had to rename them, removing the .symbols portion of the file name.
After I did that, package restore works great.
Updating the sources in NuGet.targets should work.
Make sure you have added both official NuGet source and local feed explicitly in the targets file.
What error are you noticing ?
We had a similar issue to #evan. We're using the CreateNewNuGetPackageFromProjectAfterEachBuild package to create our NuGet packages on a TFS 2013 build server. We have a local, share based package source and copy the nupkg files from the build output to this share. We found that builds that reference these packages fail because NuGet package restore fails to find the packages in the local source.
Running NuGet from the command line on the build server we get strange behaviour:
nuget.exe list <search-term-for-our-packages> -allversions
always succeeds and lists each version of our packages. However, when we go to a failed build's \src folder and run
nuget.exe restore .\oursolution.sln
we always get:
Unable to find version '1.0.6.341' of package 'our.package.name'.
I tried all sorts of things to resolve this, playing with nuget.config and swapping between versions of nuget.exe but the fix was simply to do with the naming of our nupkg files. By default CreateNewNuGetPackageFromProjectAfterEachBuild names the nupkg that it generates as the package Id plus the build configuration and target. E.g.
our.package.name.1.0.6.341.Release.AnyCPU.nupkg
With this file in our package source nuget list works but nuget restore fails. When I rename the package to
our.package.name.1.0.6.341.nupkg
then nuget list and nuget restore work as expected.
Our fix is simply to modify the config file of CreateNewNuGetPackageFromProjectAfterEachBuild to prevent it including the build configuration and target. But why does nuget restore depend on the package file name whereas nuget list doesn't?