The setup: I've created a library targeting .Net Standard 2.0 in VS 2017 and this library uses NuGet to reference a 3rd party driver and manage its dependencies. So far, so good.
The next step is to create an application that uses the (shared) library, in this case a console app targeting .Net Core. I can, of course, add a reference to the DLL(s) that form the shared library. That compiles but doesn't run because the 3rd party stuff is missing. I could of course just copy all required DLLs to the application but for obvious reasons I'd rather use NuGet.
I'm not very experienced with NuGet, never used it in this constellation and having read articles like NuGet cross-project dependency I'm getting the impression I need to fiddle with the application's project file in order to get the library in a complete form but surely that can't be the way forward.
So my question is - is the problem on the side of the library, i.e. do I need to build or export in a particular way, or on the side of the application which, IMHO, shouldn't need to know that level of detail about some library it consumes.
Any help much appreciated!
I'm sharing a large, complicated library this way with several other solutions.
First, set up your library. Right click on the library's project name and choose Properties. About halfway down you'll see a tab labeled Packages. You can use that to auto-generate the NuGet package every time you rebuild the project. Just increment the version number. I use four position version numbering -- the first three are semver-style (major release, minor release, patch release), and the fourth one I increment manually for each new build.
I recommend creating a folder on your drive or network specifically for your local NuGet packages. You can create folders under that for each project. Then you point your debug and release build output to that project folder, and the NuGet package will be generated there, too.
Finally, back in Visual Studio, go to Tools -> Options -> NuGet Package Manager -> Package Sources and add that top-level folder as a package source.
From there it's simple -- open your NuGet dependencies in your consuming app. There's a drop-down at the top right where you can choose the package source. It will automatically search all the child folders and find whatever packages you've created. Now when you tweak your library, it's just a single click to update the client apps.
Related
I want to produce a set of NuGet packages written in C#.
These packages are class libraries, referencing each other in the way like:
MyGreatPackage.Core - no references
MyGreatPackage.Feature1 - references the core
MyGreatPackage.Feature2 - also references the core
MyGreatPackage.Feature2.SubFeature1 - references the Feature2 package and, respectively, the core
During the development stage, there is often a lack of real-world use-cases, so I decided to develop those packages as a part of a real project.
To implement it, I extract those packages as a git submodule(s) and connect them to the repository of the main application.
As a result, there is a .net solution like that:
MyApp.sln
MyApp.Host.csproj
MyApp.ClassLibrary1.csproj - references MyGreatPackage.Core.csproj
MyGreatPackage.Core.csproj - in the submodule
MyGreatPackage.Feature1.csproj - in the submodule, references MyGreatPackage.Core.csproj
MyGreatPackage.Feature2.csproj (references the core csproj)
MyGreatPackage.Feature1.SubFeature1.csproj (references the feature1 csproj)
Everything goes smoothly here, as I can develop both the app and the packages.
But, when it comes to the distribution stage, this configuration doesn't seem to work, as I can't simply push the submodule contents to the NuGet and replace the submodule references with the NuGet references.
The problem is that the Feature1 package when prepared for pushing to the NuGet, should have a reference to the MyGreatPackage.Core package and not a reference to the csproj. Also, the Feature2 package and subfeature1 package.
So how should I prepare this setup for both the development and the distribution stage?
I don't know a trivial answer to your question. But here are some possibilities:
Use some kind of tool that easily allows you to switch between project references (for working locally, being able to easily debug code, etc.) and NuGet references (for publishing your applications). RicoSuter/DNT has a switch-to-projects command that does exactly this.
Always use NuGet package references, and publish new versions whenever you need it: either to a local or to a private NuGet feed. You can debug NuGet packages with the use of tools like SourceLink, or punctually include projects. Depending how tightly coupled your projects are and the stage of development you're at, this option can be more or less viable.
The poor's man alternative to the first one when using the second approach: having a git stash that includes those projects in the solution and replaces the NuGet references with the project ones. If you work on your own, this can be an option to sporadically change to project references and debug something. If used often, this can be a pain due to those change being accidentally commited, etc.
I have created a system which loads dynamically a library and executes it's main class.
Everything works perfect, the problem I have is how to publish this DLL with all it's dependencies. As no executable project is referencing it I have to manually retrieve the dependencies: try to load the library, check the needed DLL's, go to the NuGet cache folder, copy the libraries, try again, check if it complains about more dependencies and so on until it has all the required libraries.
This is a true pain and I haven't found any information on how to do this, is it possible or am I stuck with this?
The library is a .net standard 2.0 library, I did this before with .net classic and the output folder always contained all the required libraries even the ones comming from a NuGet package, but with .net standard something has changed and now only libraries from referenced projects are being copied, no referenced NuGet package is being copied to the output folder.
Cheers.
Try:
dotnet publish
All the dependent libraries should be copied to the publish output folder.
At the time of writing, it looks like it's by design and there's quite some fuss and confusion about it, see logged issue on GitHub.
Moreover, when publishing a NuGet package for project A referencing project B,
B becomes a NuGet dependency in A; B's assemby is not included in A's NuGet package.
I deal with it by publishing my own NuGet packages.
I only don't like it to have a NuGet package for project B if that one is only relevant to be used with/by project A, as it will appear seperately in my NuGet feed.
TLDR: Convert your Class Library project into an Application, publish the application, and use application DLL as a library.
The long of it:
I tested this approach by deploying a full build with a plugin with many external dependencies to Ubuntu 18.04 and it ran perfectly.
Create a new project of type Console Application instead of Class Library. Put all your library code files into the Console Application and add the dependencies. Get rid of your original Class Library project (you don't need it anymore). Finally, publish the Console Application. You will get a DLL with all of the dependencies. You can use this DLL like any other DLL.
I suggest naming the console app project with "Library" on the end of it and adding a README just to document its not really an application even though the project is configured to build as one.
We've got about two dozen projects, which all use different NuGet-packages and a bunch of Telerik WPF libraries, the latter are usually added by GAC, which on its own does not add a hint path to the csproj-File. (Good)
As soon as we use Telerik's upgrade wizard to simultaneously upgrade the references of all projects, Telerik starts copying the files to a local lib folder next to the bin folder and adds hintpaths, which do not exist on other developers machines AND need to be discarded before pushing to Git every time. (Bad)
BTW: We regularly get the same problem (regarding hintpath) with the Spire NuGet-Package.
Now we came up with some suggestions, which we internally valued differently and therefore did not come to an accord:
Keep discarding the chunks containing the hint path
Ask Telerik to fix the wizard
Check the libraries into Git
Add Telerik libraries using their NuGet server
Create a Libaries-Path we manage by hand, maybe as a network drive
What's other peoples approach to handling those issues?
I'd go for "Check the libraries into git".
Rationale: when a developer (or CI system) checks out your project from source control, he should be able to build it right away without having to install dependencies like GAC assemblies.
You need to use NuGet for that, it's the easiest and most organized way, you should not have a problem for other developers when you install a new package as long as you are committing package.config file, in this case any one will do a build of the solution visual studio will automatically restore NuGet Package.
Make sure to set your NuGet settings as below image shows:
Don't use the Telerik wizard. Add the Telerik dependencies using NuGet. They have a private NuGet repository. See the tutorial here.
I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?
.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?
I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).
I'm using a NuGet package called Hangfire in my VS project. However I'd like to be able to step thru each Hangfire API which is not possible as these files are under the "References" folder, so I've downloaded a copy of the Hangfire source code from Github. However, how do I integrate this code into an existing Visual Studios Project? Or maybe even simpler, instead of installing a NuGet Package, how do I reference the methods in the HangFire source code in my VS Project?
In order to reference these files, you'll need to...
Add the Hangfire project (or projects!) into your Solution. This can be done by right-click -> add existing Project on the solution.
Make sure that you're referencing the Hangfire in the Solution. This can be ensured by removing all references, and then readding them, making sure to draw from the Solution section in the Add Reference dialog.
Make sure the Hangfire projects are set to build in the dependant configurations. This can be done by selecting the Configuration Manager either in Solution settings or via the configuration or platform drop-down. Make sure the Hangfire projects are checked for any configuration/platform combinationin which your projects are selected
Assuming you have a repo for you project (and you always should), you may also be able to embed Hangfire as a subrepo in your repo, so updating and keeping versions synced is easier.