After a user does a dotnet add package <SomePackage>, the DLL will be installed to a path similar to:
C:\Users\USER\.nuget\packages\SomePackage\1.0.2\lib\netstandard2.0\SomePackage.dll
How can I find this path programmatically? I see there's some information in the obj/project.assets.json that I could parse, and also an interesting DependencyContextJsonReader class under the dotnet github organization.
However, there's no documentation or discussions about this that I can find, and I'm not sure if that's because I'm taking the wrong approach.
Some background:
I'm writing a tool that can scaffold C# projects. It uses a combination of the dotnet command line tools, and the Roslyn Workspace APIs to interact with the generated project. I'd now like to allow the user to install Nuget packages into this generated solution. I invoke dotnet add package SomePackage which works fine, and now I'd like to add the DLL to the Roslyn Project object using the AddReferences API, which requires the actual DLL.
I found a way to do this using the nuget client libraries.
Essentially, rather than shelling out to the dotnet add package command, I can use the NuGet client libraries directly from my application to install packages. I then have access to the full path via the PackagePathResolver.GetInstalledPath method.
Martin Björkström's post, Revisiting the NuGet v3 Libraries, goes into much more detail, and a fully working code sample from Martin is available in this gist.
Related
I'm using cake to build my csproj projects. Since package usage via NuGet is very simple, you'll end up with multiple dependencies to third party NuGet packages. Since the code is used in a commercial manner, I want to extend my build script via a license checker. Does anybody knows if there is a license checker available for Cake? For Maven there is a plugin available here.
I checked the cake online reference but was not able to find a "module" like this.
I also queried stackoverflow and found this answer, which doesn't help me, because it uses the Visual Studio build in package manager, that is a seperate PowerShell host and can't be created/started from default PowerShell host.
Thx.
I want to write that C# code convert-nunit-3-nunit-2-results-xml-file, but despite the added nuget package i'm missing the dll in my project.
I see it in the tool's directory of the package cache, but missing it in my project.
What do i overlook?
My project is at present for .Net Core 2.1. Is my issue therefore related to this: Add support for net standard ?
I'm new to .net and don't understand all the differences so far.
As zivkan explained, the package is a tool. In fact, it's an extension to another tool, the NUnit engine package. The NUnit engine knows how to find and use the extension.
NUnit does not publish a package that is intended for use by your code as a library, because we would then have to support it as a library in addition to it's use as an extension to NUnit.
However, NUnit's MIT license allows you to use the source code, which you can find at https://github.com/nunit/nunit-v2-result-writer
Since the code has not yet been ported to .NET Core, you would have to do that yourself.
You didn't overlook anything. Not all NuGet packages are libraries.
NuGet has conventions on how files must be packed in order to use various features. For example, files in the content or contentFiles get copied into the project directory, or build output, depending if the project using the package uses packages.config, or PackageReference. If the package author wants to give you a library that you can use in your code, they must put the library in the lib directory in the nupkg (technically it could be in ref, but those don't get copied to build/publish output, they're only used at build time). The tools directory is, unsurprisingly, intended for tools packages. It's often used by unit test runners, or in this case, a report generator.
So, since the package puts the dlls in the tools directory, this means the package author intends the package to be a tool to assist you during development, but not as a library for you to use in your code. You could try contacting the package author to see if they have published another package with the same dll, this time in the lib directory, so that you can use it your project.
Otherwise you'll need to find a solution that doesn't rely on NuGet bringing you this dll as a library. One option is to have a packages.config file that extracts the package in a solution packages directory, and then you use a dll reference to the dll. Your build script would then need to first restore the packages.config file before building your project. Another option is to check in the dll into your source control management tool, if the dll's license allows that, and again have a dll reference to it.
There doesn't seem to be an installation guide in the PushSharp readme or the wiki link. I noticed that there's a NuGet installation for it, but I am not sure how it works. How would one incorporate it into an existing c# asp.NET project?
Edit:
It seems like the one from the NuGet package does not support dotNet core 1.1.
I found this that might support it: https://github.com/geeklearningio/PushSharp-Core
But I'm not sure how to incorporate this into my existing project.
Nevermind^ there's a NuGet package for the above, but it looks like its only support for dotnetcore2.0
I have a project with some protobuf files. I want to compile these files to C# as a pre-build step.
So I add Grpc.Tools as a NuGet package to the project. And lo and behold, the tools are downloaded inside the solution's packages folder: packages/Grpc.Tools.1.6.1/windows_x86/protoc.exe.
Our CI server, on the other hand, uses a linux docker container (microsoft/dotnet). Is there a portable way to specify where to find the protoc compiler? Preferrably I would like to just ask the system: dotnet where Grpc.Tools or something.
I had a similar issue, in my case I wanted to pack C# code using ExcelDNA tools that come with the package. The post build event was added as part of the package install, but depended on the package folder been located in the solution folder, as you say. Porting the code to Net Standard we realised that the new version of nuget cannot deal with this specific issue of post build events which require the package tools to be in some folder relative to the solution or project. So to directly answer your question see here.
However you may not find that very useful if you want to do a post build event from the solution? If you are using jenkins et al and have a seperate step for packaging then the above should work fine.
There are a couple of ways around it. Most simply you can add the tools to source control, and then manually edit the post-build events. Depending on how you feel about that.
Secondly you can force nuget to resotre the packages locally and not in the system wide cache folder. You can do this through the Nuget.Config file. I have not got the specifics to hand, but if you cannot figure it out I can look in my old code.
I have a VS2015 solution with 6 projects in it. I'd like to create a nuget package out of it but:
the project is for internal use only, so I don't want to publish it online
It should include the source code (is it possible?, not a strict requirement)
It should be the final artifact, can I choose a directory where to have such package?
thanks
You can publish nuget in your private host with https://github.com/themotleyfool/Klondike.
you can use nuget Package Explorer to create nuget package. https://github.com/NuGetPackageExplorer/NuGetPackageExplorer
You have multiple options. Either you can use command prompt or Nuget Package Explorer.
In order to publish you can use Nuget official server or private Nuget server. I recommend Nexus Nuget server.
For publish official one, you need to create account and obtain api key.
You can find detailed usage in here.
For including source code, there is no such a thing in official one. Because it aims ready to use artifacts.
You can add your dll, dependencies, extra files such as configs, html etc