perhaps Im getting old but Im really confused on how to use a nupkg on Linux. Resolving and installing dependencies/adding libs for C is easier for me (never would thought I would say so).
I got a package from a vendor (YYYYY_linux.3.0.77.nupkg) and want to run their example code (version for windows with visual studio worked out of the box) but they told me their linux pack would also work.
What I did:
dotnet init
... coding ...
dotnet restore
dotnet build
/home/tobiass/code/XXXX/Program.cs(27,11): error CS0246: The type or
namespace name 'YYYYY' could not be found (are you missing a using
directive or an assembly reference?)
Afterwards I tried two things:
1.
I edited NuGet.Config
dotnet restore
The nupkg shows up as a feed.
But I still get the same error.
2.
I also tried to create a local feed
mono nuget.exe add ../YYYYYYY_linux.3.0.77.nupkg -source ./
but it always results in
The requested feature is not implemented.
What is the correct way on Linux to add a library? Must it be also a part of project.json? Some config in .nuget?
Best,
Tobias
I suspect your project is not a .NET Core project so you should be using nuget.exe instead of dotnet.
So first I would take a look at the example code. Does it have a .csproj file? Does it have a packages.config file? Does it have a packages folder with the .nupkg file in it already? If so then nothing needs to be done and it should just compile.
From the error message one or more of the above are not correct. If the project file (.csproj) has references to the files in the NuGet package and there is an existing packages.config file then all you need to do is restore the package. To do that you need to put the NuGet package somewhere so it can be restored. You could simply just copy the .nupkg file into ~/.local/share/NuGet/Cache/ which is the machine cache for all NuGet packages and then restore it into the project by running nuget restore Path/To/YourSolution.sln.
If the project does not have a packages.config file then you would need to install it into the project. The simplest way would be to use MonoDevelop. That has built-in support for adding NuGet packages to projects.
Otherwise you could just unzip the .nupkg file and copy the files where they need to go into the solution's packages directory based on the information in the .csproj file.
Related
I've been fighting with nuget all morning, trying to get a solution that builds in the UI AND from the command line. Here's the latest problem, which I haven't made any headway on:
I'm running nuget restore on the solution file. This works, all referenced packages are restored - I can see the files in the /packages folder under the solution folder.
I'm building with devenv command line - I have to because this solution contains project types that msbuild doesn't support.
The first project that references a nuget package, fails to compile with ...cs(3,7,3,17): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
The project builds (and rebuilds, and rebuilds with the package folder cleared out) just fine in the UI, but the command line build isn't seeing the restored packages.
The build that's failing is in a CLEAN folder on the same computer where I'm doing the UI build, so it's get from source control, nuget restore, devenv build.
Things I've tried
Looking for bad hint paths in the project file (saw this in another question/answer). These references don't appear in the project file at all - trying to add them produces an error saying that the reference can't be added because it's already added automatically by the build system.
Verifying that files do exist after restore.
Doing the same steps from a command line in the SAME folder where the UI is building. This works fine.
What am I missing? this shouldn't be so hard..
UPDATE: The solution consists of 14 projects: 9 C# class libraries, 2 c# applications, 1 reporting services project and 2 WiX installer projects. All C# projects target Net472, NOT Core. The key part of the solution structure appears to be:
Project A references
Newtonsoft.Json via nuget
Project B references
Project A
Newtonsoft.Json via nuget
Other packages via nuget
During build, project B fails to compile due to the lack of a reference to Newtonsoft.Json. Project A and all of the other nuget packages are supplied to the compier as references. Again, all nuget packages are in fact restored - Project A finds Newtonsoft.Json, project B does not.
In the detailed msbuild log output, this is the only mention of Newtonsoft.Json in the build of project 10 (Project B above):
10> Dependency "Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed".
10> Resolved file path is "...ProjectA\bin\Release\Newtonsoft.Json.dll".
10> Reference found at search path location "...ProjectA\bin\Release".
10> For SearchPath "...ProjectA\bin\Release".
10> Considered "...ProjectA\bin\Release\Newtonsoft.Json.winmd", but it didn't exist.
10> Required by "...ProjectA\bin\Release\ProjectA.dll".
10> Required by "C:\...ProjectA2\bin\Release\ProjectA2.dll".
10> Found related file "...ProjectA\bin\Release\Newtonsoft.Json.xml".
10> The ImageRuntimeVersion for this reference is "v4.0.30319".
(Folder and project names have been obscured)
A couple things going on here, finally got a solution that works. Why this built in the IDE is anyone's guess - it's adding some extra secret sauce to make things work (more than just the automatic nuget restore).
I tried changing all projects to use PackageRef instead of packages.config. That caused nuget restore to fail with an obscure msbuild error that I didn't try to diagnose.
I noticed that SOME of the nuget packages were referenced in the .csproj files with ordinary Reference elements, but some of them were not (specifically, Newtonsoft.Json in "Project B" - and some others that I hadn't noticed due to B failing).
To correct the situation:
Remove ALL use of PackageRef elements - change back to packages.config in ALL projects
Make sure the each of the nuget -provided DLLs is referenced in the .csproj files. You have to do this by editing the csproj file by hand - the IDE won't let you add the missing references.
I'm assuming that this is a temporary situation and that in the long run the solution will be to use PackageReference everywhere.
you already checked the files app.config and packages.config, and the dotnet framework version?
Nuget package not found after restore VS 2019 16.5.0
devenv /build command line does not have the job to restore nuget packages by default. However, there are such options in VS IDE so that it will restore packages first and then build. But these do not work in command line.See this similar issue.
But you still want to use devenv to build your project and since you use a framework project with packages.config, I suggest you could use nuget.exe.See this.You can try these:
1) download nuget.exe from this link and then configure its local address to PATH in the environment variable and make sure that you can call nuget from CMD.
2) open vs command prompt, cd the path of the solution and then type this first:
nuget restore
Then you can type your devenv command line and I am sure that this will execute without any errors.
devenv xxxx.sln /rebuild
Besides,you can add a custom target in any xxx.csproj file of your solution like this:
<Target Name="restoresolution" BeforeTargets="BeforeBuild">
<PropertyGroup>
<nugetpath>C:\tools</nugetpath> /////the local path of the nuget.exe
</PropertyGroup>
<ItemGroup>
<slns Include="$(MSBuildProjectDirectory)\..\**\*.sln" />
</ItemGroup>
<Exec command="$(nugetpath)\nuget restore %(slns.Identity)" />
</Target>
Then you can run devenv xxxx.sln /rebuild directly.
I have a C# project in my local and it is working perfectly in my local machine. When I try to build the same project through Azure DevOps it gives the following build error
[error]d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln.metaproj(0,0):
Error MSB3202: The project file
"d:\a\1\s\packages\System.Net.Imap4.0.1.0..\example\example.csproj"
was not found.
d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln.metaproj
: error MSB3202: The project file
> "d:\a\1\s\packages\System.Net.Imap4.0.1.0..\example\example.csproj"
was not found.
[d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln]
Project
"d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln" (1) is
building
"d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.csproj"
In the IMAP4 library, it specifically says that the following file was not found. When I added the package through Nuget Package Manager it installed perfectly but does not download the mentioned file example/example.csproj in the packages/System.Net.Imap4.0.1.0 folder.
d:\a\1\s\packages\System.Net.Imap4.0.1.0\System.Net.Imap4.sln.metaproj : error MSB3202: The project file "d:\a\1\s\packages\System.Net.Imap4.0.1.0..\example\example.csproj" was not found.
System.Net.Imap4.0.1.0 package structure
System.Net.Imap4.0.1.0/lib/net35 (inside the lib there are no files and it contains only net35 folder)
System.Net.Imap4.0.1.0/properties
What I am missing here to build the project successfully?
Note: I tried to view the hidden files also but the example.csproj file was not found.
Facing build error with System.Net.IMAP4 in Azure DevOps
This issue should comes from that nuget package. I have download that nuget package from nuget.org, then I unzip it, I found that the package did not contain the file example.csproj:
So, this issue related to the package, I am not sure if you are the Owners/Authors of that package, if yes, you need to re-create that package.
In addition, I have a long time to use/support nuget. According to my experience, this package is not correct. As we know, nuget:
An essential tool for any modern development platform is a mechanism
through which developers can create, share, and consume useful code.
Often such code is bundled into "packages" that contain compiled
code (as DLLs) along with other content needed in the projects that
consume these packages.
But that package packaged the entire project, which is not the correct way, it should only include the dll files.
You can check this document for some details.
Hope this helps.
The build error resolved with the following changes.
Navigate to this folder path /../System.Net.Imap4.0.1.0
Open the System.Net.Imap4.sln file and remove or comment the example/example.csproj line from the file.
Build the project
Build is successful
This is what I did:
went to
https://www.twilio.com/docs/authy/tutorials/account-verification-csharp-mvc
downloaded the code and built the code using VS2017 community edition.
I get the following error in IdentityConfig.cs
Severity Code Description Project File Line Suppression State
Error CS0246 The type or namespace name 'TwilioRestClient' could not be found (are you missing a using directive or an assembly reference?) AccountVerification.Web C:\Users\admin\Downloads\account-verification-csharp-master\account-verification-csharp-master\AccountVerification.Web\App_Start\IdentityConfig.cs 21 Active
What is the problem?
I changed nothing. Just downloaded and built the code. Shouldn't you guys give a working copy of the code?
I've managed to get this working by following these steps:
Close the solution in Visual Studio if you have it opened.
Ensure you have a nuget CLI in your path. So you can run a restore from a command prompt. This is pretty straightforward. Instructions here.
Open a command prompt at the solution directory. (C:\Users\admin\Downloads\account-verification-csharp-master\account-verification-csharp-master for you.)
Run a nuget restore. nuget restore and wait for it to finish.
You should get all the packages downloaded at the packages directory under your solution folder.
UPDATE - Looking at the code it appears that there's a mix of features from the latest version 5.x and the now deprecated version 4.x, and that's causing compilation errors. Details here.
Follow the below steps to downgrade the version to 4.7.2:
Open the solution file now.
Right-click the web project and select Manage Nuget Packages.
Search for Twilio and downgrade the version from 5.x to 4.7.2.
a) Or from the Package Manager Console Install-Package Twilio -Version 4.7.2
Solution should build successfully now.
Please bear in mind that you must setup the parameters in Local.config file before the app can work. It'll run though, but you'll not be able to go through it until the parameters are properly set.
Note: The solution contains a file named Local.config.example. When you open the solution you'll notice that Local.config file is missing.
Renaming the existing Local.config.example file to Local.config solves that issue. I had to copy the Local.config file to the test project too. This doesn't prevent the solution from building, though.
Hope this helps!
I try to build a solution stored in an external GIT-Repository on Visual Studio Online.
It has the following steps:
1: Git Restore - Works
2: NuGet Restore - Works
3: Build - Does NOT work
My first guess when looking at the logs is that MsBuild is not looking for the Packages where NuGet had stored them.
Some Lines from NuGet Restore:
2018-03-14T21:10:11.0352862Z Completed installation of AngleSharp 0.9.9
2018-03-14T21:10:11.0353230Z Adding package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0353563Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0354972Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages' from source 'https://api.nuget.org/v3/index.json' 'Microsoft.SharePointOnline.CSOM.16.1.7317.1200' to folder 'D:\a\1\s\packages'
Some lines from MsBuild:
018-03-14T21:10:21.2105399Z PrepareForBuild:
2018-03-14T21:10:21.2105793Z Creating directory "bin\Release\".
2018-03-14T21:10:21.2424947Z Creating directory "obj\Release\".
2018-03-14T21:10:30.3569560Z ResolveAssemblyReferences:
2018-03-14T21:10:30.3570425Z Primary reference "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL".
2018-03-14T21:10:30.3670272Z ##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2041,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
My solution/packages structure is:
....\mysolution\myproject\myproject.csproj
....\mysolution\myproject\packages.config
Current Config:
So how can I change the Nuget and/or msbuild-behavior to make this work?
(Update): To clear this up: I have this problem with every package. They all are in the packages.config, each one is downloaded from Nuget, but each one also isn't found from MsBuild
(Update2) The Commands generated are currently the following:
NUGET:
D:\a\_tool\NuGet\4.4.1\x64\nuget.exe restore D:\a\1\s\AweCsomeO365\packages.config -PackagesDirectory D:\a\1\a\packages -Verbosity Detailed -NonInteractive -ConfigFile D:\a\1\Nuget\tempNuGet_22.config
MSBUILD:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" "D:\a\1\s\AweCsomeO365\AweCsomeO365.csproj" /nologo /nr:false /dl:CentralLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=(GUID)|SolutionDir=D:\a\1\s\AweCsomeO365"*ForwardingLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=D:\a\1\a /p:ReferencePath=D:\a\1\a\packages /p:platform="anyCPU" /p:configuration="Release" /p:VisualStudioVersion="15.0" /p:_MSDeployUserAgent="VSTS_(GUID)_build_4_22
I replaced the GUIDs; tempNuGetConfig is something that seems to be generated by VSTS dynamically
Still. even if the log states that nuget stores the packages
Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\a\packages'
MsBuild does not seem to find them there:
For SearchPath "D:\a\1\a\packages".
2018-03-16T13:57:42.4625155Z Considered "D:\a\1\a\packages\AngleSharp.winmd", but it didn't exist.
2018-03-16T13:57:42.4625456Z Considered "D:\a\1\a\packages\AngleSharp.dll", but it didn't exist.
2018-03-16T13:57:42.4625730Z Considered "D:\a\1\a\packages\AngleSharp.exe", but it didn't exist.
VSTS-Configurationvalues:
MsBuild: /p:ReferencePath=$(Build.StagingDirectory)\packages
Nuget-DestiantionDirectory: $(Build.StagingDirectory)\packages
(update3): I have no solution file, but only a csproj-file in that repository
The issue was that inside the project there was a hintpath for the packages directing to a location that was not within the GIT-Repository (and shouldn't):
<Reference Include="AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL">
<HintPath>..\..\AweCsome365Test\packages\AngleSharp.0.9.9\lib\net45\AngleSharp.dll</HintPath>
</Reference>
My original approach was to define a target directory to NuGet and a Source Directory for MSBuild to use another location to the packages that both understand.
The issue though (as far as I understand) is, that NuGet always creates a subfolder-structure "./packages/{PackagesName}/lib/net45/{file}" and MSBuild does not look recursivly when setting "./packages" as source path.
The above is just an explanation for the future guy running into the same problem
So my solution was to mimic the local behavior for nuget and changing the output directory to match the HintPath (even if there is no "AweCsome365Test")-directory in the repository:
(I will leave this question open as this solution smells fishy. If anyone has a better solution that allows to chain nuget and msbuild without using the HintPath I am happily willing to spend my bounty on it)
I believe that your MSBuild "ReferencePath" parameter is not correct. you are telling MS Build that all your references (nuget packages and their dlls included) are going to be located at "D:\a\1\a\packages" but that is not where nuget will download and store the packages and dlls. Nuget will download and extract files into D:\a\1\a\packages\{packageName}\{version}\lib\{environment}\package.dll. I think you need to remove that last parameter (ReferencePath) from your MSBuild arguments.
I also noticed that your PackageLocation parameter is not the same as the destination for the NuGet restore task, do you need to add the "\packages" to that parameter like the destination in the restore task?
Change the nuget restore destination directory to $(Build.SourcesDirectory)\packages and remove the msbuild ReferencePath parameter.
The answers here are largely right. However it's worth noting another cause that can result in this behaviour. My toolchain was using Azure DevOps which is basically the same as Visual Studio Online, just a few years later.
Cause:
Reference your project from a different solution (cross-repo), for instance for debugging purposes
Update NuGet references in the problematic project from the external place you referenced it from
What this does is make use of the solution location for packages when the package gets installed.
For .Net core/standard projects, using Update-Package -reinstall appears to fix things. However, for .Net Framework projects, even though packages.json may get rebuilt, the <HintPath /> node in the .csproj gets left as is - with a reference to a packages folder that Azure will never create.
Simple fix:
Right click on the offending solutions locally, and choose Unload
Right click on the unloaded project, choose edit .csproj
Find any hintpaths that look like ../../OtherRepo/packages (the slash in use may vary), and change them to ../packages
Confirm the solution does build locally still
Push the changes to Azure, and cross your fingers
This approach will fix the issue caused by consolidating / updating packages from the wrong place rather than requiring a change to the build pipeline to spoof that location (which in may case, wasn't working very well either).
I am trying to write a C# interactive script (.csx) that needs to use a NuGet package, but I must be overlooking something fundamental because I can't get it to work.
I tried adding a project.json that refers to the package, and it gets installed into the global packages dir when I nuget restore, but it seems the #r directive does not look there. I failed to find a relevant documentation on how the #r directive work (most docs seem to deal with the similar but different project called ScriptCS).
How do you write a csx script that references NuGet packages?
Dotnet Script has support for referencing Nuget packages in CSX files:
#r "nuget: AutoMapper, 6.1.0"
https://discoverdot.net/projects/dotnet-script#nuget-packages-1
C# Interactive can't reference NuGet packages, but scriptcs can.
This wiki entry has a note for the Interactive Window saying that you need to reference directly the NuGet DLL. So you could use the absolute path to the DLL in the global packages directory. It's not ideal, but should work.
Very simple from Visual studio UI:
Right click the project, Click Manage NuGet Packages
Selected the NuGet Package from the list in Browse or Installed tab and click the nuget.org URL
URL will lead to this webpage, Go to Script and Interactive tab, then simply click the copy button and paste it in your CSI in Visual studio or *.csx file
The solution is quite simple if you have ever worked with FSharp before, but the main
solution is:
#r "nuget:Newtonsoft.Json"
Above gets the latest package version. But if you want to specidy a version this works.
#r "nuget:Newtonsoft.Json,1.20"
If you happen to be working with external nuget sources, you should initialize that source with.
#i "nuget:http://example.com"
for sources on the web and
#i "nuget:C:\Nuget"
```for sources on your local file system