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?
Related
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.
I have a library written in full .NET and I am porting it to .NET Core. I intend to make it target the .netstandard1.1 (in order to be also compatible with .NET45).
When I create the project with visual studio, it automatically depends on the NETStandard.Library nuget package.
My library only needs two packages:
System.Runtime
System.Runtime.InteropServices
Two questions :
Do I need to restrict my project dependencies to only these two packages? Rephrased: may be nuget (or visual studio or another magic stuff) manage to restrict on its own to only the needed packages and not the full NETStandard.Library?
If the answer to the first question is no, is it a good idea to perform that restriction?
Thanks in advance.
(Sorry for my english, I am not a native speaker)
There are some aspects in your question...
The netstandard1.1 framework choice will limit your available API surface in the editor (here VS Code) to what is available that version. Just tested with File.OpenRead on VS Code for netstandard1.1 (not available) and netstandard1.6 (available).
The NETStandard.Library dependency (version 1.6 is good for both cases) is a package dependency. Once the assembly is compiled, the assembly itself will declare external assemblies (aka referenced assemblies) which were actually used (e.g. System.Runtime and System.Linq) and not all assemblies found in the NETStandard.Library meta package.
As long as you are not packaging it up for NuGet, assembly reference restrictions are anyway done for you. NuGet packaging however would refer to the NETStandard.Library package
If you use NuGet and that reduction is important to you, I guess the correct term is NuGet dependency trimming, a manual process explained here (short version: copy all references from the meta package and remove all you do not use).
I am not sure if it's a VS bug, however seems like VS doesn't like building a library and not having a NETStandard.Library package included :) So, no.
Unless you use Visual Studio Code or Notepad etc. this will slow down your development, since VS will prevent you from building the project etc. So, no again.
The bottom line.
Premature optimization might cause more issues than benefit. Port your library first, and only then check if you need to optimize it.
I'm making a complex application and I would create more little packages to include. I have installed a nuget package "CreateNugetPackageFromProjectAfterEachBuild" that create or update automatically a package of my application. In this moment I create two types of package Debug and Release but from VS15 I see only one package to install. Why? Is the correct way to work?
Thank you!
It's not clear from your question, what exactly you want to create NuGet packages for.
In any case, it makes no sense to have separate Release and Debug versions of packages. You could separate them by version, though:
have stable releases built as Release
have prereleases built as Debug
Make sure that each NuGet package you build has a different version, otherwise you'll cause yourself a lot of grief. NuGet has no way to differentiate between different packages with the same version. You can only update a package to a different version and individual versions are cached. It's best you create and publish new package versions from a build server, not directly from a development environment to avoid confusion.
Also, keep in mind that you should really only be using NuGet packages for libraries which have an independent lifecycle and are used in multiple projects. You will want stabilize a library before creating a new version of the package and then stick with this version in your application until you have a new stable version of the library ready.
If your libraries are more tightly coupled to the application - they don't have a separate lifecycle and you tend to modify them together with the application, then referencing them in the application as a NuGet package is not that good of an idea. You're better off just having both the libraries and the application as part of the same solution.
There is a project that wraps V8 engine into C# library. Its nuget package is broken and i'd like to fix it. Creating a package seems easy and there is documented way to pack different C# dlls for different .NET versions. However, i have no idea how to package .dll with C++ and C# code which could be built with different options:
x64 or x86 and not "Any CPU"
MS Visual C++ 2010/2012/2013
debug or release
.NET 4.0/...
I've found this thread and it seems that one can use .targets file with MSBuild commands inside. Then i've read in the docs that MSBuild way is old and not recommended. So what should i do?
One more question is: if this package depends on MSVC++, how to specify this? How to let package consumer select a specific version of dll (built against MSVC++2010, 2012 or 2013)? I suppose it is not a good idea to package msvcr*.dll.
Take a look at how the SQLite packages deploy their DLLs. With the 2.x and earlier versions of NuGet you need to write some powershell code to inspect the version of Visual Studio and apply your changes to the project manually.
We are working towards a more elegant solution for this exact problem with the updates that are to be deployed in NuGet v3
We have 1 solution that contains all of our shared assemblies. Currently we are referencing these assemblies based on relative path (../../../../../SharedSolution/bin). It would be nice to create a nuget package (or a few based on various dependencies) to reference these assemblies so I can get easily update and I don't have to worry about having the exact same directory structure as everyone else on the team and all the other benefits of nuget.
However, let's say that when I'm working in my ProjectASolution, I realize that I need to make a change or add a shared class to SharedSolution. In my ProjectASolution if I have referenced the assemblies from SharedSolution with a nuget package, but I want to test my changes to SharedSolution before committing them, is the only way to copy the assemblies from the SharedSolution bin to ProjectASolution's packages folder?
Since we are frequently editing classes in SharedSolution, I'm beginning to think that nuget might not be the right way to share these assemblies.
Another possible solution is to add the projects from SharedSolution as links to any of my ProjectSolutions that need to reference them. Is this a better alternative?
Is there a better way to share these assemblies than relative path? Is there an easy way to test changes made on a dev machine to a nuget package?
You can build a pre-release package. Only developers who set their nuget to use pre-release packages will see them, everyone else will be still using the latest stable.
A good explanation and How-To can be found on the NuGet Pre-Release Package page.
To address the questions you raised in your comment:
You can build nuget packages locally, based on the .nuspec file which is usually next to the .nupkg file in the packages folder. You can use NuGet Package Explorer to do so in a GUI.
To distribute them, you can store the pre-release packages on a network folder. Any developer interested in the pre-release package can add this network folder to their nuget sources and can then use the Visual Studio-integrated nuget as usual. Or you can just copy them the .nupkg file.
You should be using as much self-contained testing as possible for an assembly before publishing a new package. Ideally, anything you would be putting into a NuGet package would be fully covered by unit tests and, if necessary, some kind of test app.
Also, if you're going to use NuGet, I would look at splitting up some of those assemblies if possible. It's easier to maintain references and track real updates to packages if they're in logically separated sets rather than one mega package.