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.
Related
I'm creating a NuGet package (let's call it Lib) that also has analyzers in a separate package (Lib.Analyzers).
By default I want Lib.Analyzers to be installed to the the project when Lib is installed. I can achieve this by listing Lib.Analyzers in the dependencies of Lib (in the .nuspec file).
But I also want users to be able to uninstall Lib.Analyzers again when they don't want them.
AFAIK package dependencies are not listed as individual packages in the package manager and the following wouldn't work in the package manager console:
PM> Install-Package Lib
...
PM> Uninstall-Package Lib.Analyzers
Uninstall-Package : Package 'Lib.Analyzers' to be uninstalled could not be found in project 'ClassLibrary1'
Is there a way to achieve this? I couldn't find anything in the docs.
Rationale
I want to minimize friction for new users, i.e. they should get the help Lib.Analyzers provides without having to remember to install the analyzers every time they install Lib.
But I also want Lib.Analyzers to not be forced onto experienced users that might not want them anymore.
Workaround
My current workaround would be to rename Lib to Lib.Core, remove its dependency to Lib.Analyzers and create a third meta-package named Lib that bundles the two, arriving at the following dependency graph:
Lib
|- Lib.Core
'- Lib.Analyzers
New users would then always install Lib and experienced ones could install only Lib.Core instead.
However, Lib is actually a rather small library so this solution feels a little "over-engineered".
There is a GitHub Issue about optional dependencies here, which is closed.
So unfortunately it is not supported currently, and does not seems to be in the future.
rohit21agrawal gave the following close reason:
Couple of reasons - we are closing bugs that have not been active for
over a year, and two, this doesn’t fit in with the plans we have for
NuGet in the near future.
You can open a new issue if you have a strong case for this feature
and we would consider it.
Maybe your issue is a "strong case".
That being said, your workaround seems pretty good. More a documentation/introduction problem.
There is also an option to suppress specific analyzers, if that is the root of your question.
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.
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.
I'm creating a private NuGet package for my company and I want to distribute two different versions of my .dll. The release .dll was for some developers who can call this dll for development. And the debug .dll id for some developers to develop the dll itself for the second version.
So my question is that if I wanted to accomplish this by using only one NuGet package, is this possible? Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?
Any suggestion? Thanks in advance.
Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?
To my knowledge, you may overcomplicating this things. That means you want to use one dll for debug mode to test and another dll for release mode to develop, so those two dll files should be independent, which should be distributed to different packages. Because a NuGet package will normally hold just a single set of assemblies for a particular target framework. It is not really designed to ship a debug and release version.
Besides, when we publish nuget package, the release version of your dll is the best choice since users wont debug into your dll, they will only care about if it works fine and how it works.
In addition, NuGet supports use any string as a suffix to denote a pre-release version, as NuGet treats any such version as pre-release and makes no other interpretation. So you can use -beta to specify a new version of that dll for develop.
https://learn.microsoft.com/en-us/nuget/reference/package-versioning#pre-release-versions
Basically per my understanding, use a different version of the package should be better. Of course, if you persist on using one package, Nekeniehl provided the correct direction.
Hope this help you.
You can create the same dll and each team can get the dlls like yournuget -release or yournuget -debug.
I normally use a buildscript to create the nugets, paket and FAKE will help you do the job.
And here a related answer to your question:
How to create a nuget package with both release and debug dll's using nuget package explorer?
I have some 3rd party DLL's i need migrating into a TFS Nuget Feed, and I haven't been able to find many articles on the internet about installing specific versions of a given Nuget Package at runtime, could anybody link me to some relevant material and/or provide some pointers to this effect?
Ideally this would be done as an MSBuild Target I think?
Thanks in Advance :)
To promote a cleaner development environment and to reduce repository
size, NuGet Package Restore installs all referenced packages before a
project is built. This widely-used feature ensures that all
dependencies are available in a project without requiring those
packages to be stored in source control (see Packages and Source
Control on how to configure your repository to exclude package
binaries).
This should help NuGet Package Restore
One of the topics
MSBuild-integrated restore in Visual Studio, for NuGet 2.6 and
earlier.