I have several questions related to project.json, dependencies and the use of dotnet restore :
Where are located the packages when doing dotnet restore according to dependencies declared in project.json?
I have seen that one can dotnet restore --packages "myPackagesPath thus specifying where to locate its packages, but how can `dotnet build' knows where to fetch the dependencies afterwards? I have not seen any part of the project.json that specifies it.
is project.json the way to go when creating new project in dotnet core?
1: depending on your OS, it is in $USERDIR/.nuget/packages/
2: sorry, no idea on this one
3: yes, try it by doing: dotnet new it'll create a project.json
Related
I have a solution of a hundred plus .NET Core projects. Not all of them needs to be packed, but only those which are transitive dependencies of a few special projects.
However, when I run dotnet pack it attempts to pack all kinds of projects that it should not and there are errors here and there. I would like instead to run pack on the special projects only in a recursive fashion, so that only them and their transitive dependencies (project references, of course) are packed.
I figured I can implement it by scripting around the dotnet list reference command, but it does not sound right. There must be a better way to do it.
EDIT 1
The solution must work on the command line where we have dotnet and msbuild and possibly nuget, but no VS IDE.
You can modify your project settings to generate *.nupkg file during dotnet build, without explicit dotnet pack call. And as soon as dependencies get builded automatically when "parent" project builds - you will receive nuget packages prepared for all dependencies too when you run dotnet build for "parent" project only.
For each project that should produce nuget package add this lines into csproj file:
<PropertyGroup>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
Or, instead, you may enable checkbox "Generate NuGet package on build" from Visual Studio, in project properties ("Package" tab) - this will add same line into project file.
I have been trying to build the following project structure with dotnet cli on netcoreapp3.1:
project_root:
project.sln
projecct1
--------project1.csproj
project2
--------project2.csproj
third_party
--------third_party1
------------third_party1.csproj
The third party project is referenced in one of the projects and it is in its self a netsandard2.0 assembly
running dotnet build produces the following error:
error NETSDK1005: Assets file '...\third-party\third_party1\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v3.1'. Ensure that restore has run and that you have included 'netcoreapp3.1' in the TargetFrameworks for your project.
Building the third party on its own works fine.
I realize that the error stems from the structure of the project. Any ideas how I can build the project with getting this error?
Ok so answering my own question. The problem was not the structure. When I built the project in command line I use dotnet build -c Release -f netcoreapp3.1
Since the project is a mix of netcoreapp3.1 and standard2.0 assemblies the standard2.0 assemblies failed to compile. If your framework is set in the csproj file not need for -f apparently.
Where does dotnet core look for a nuget executable when running restore commands?
Is there a separate executable, or are the nuget functions built directly into the cli tools?
If I already have a nuget executable on my path, can dotnet be configured to use this?
NuGet is no longer an executable that runs for a restore operation, it has become an integrated part of the build tooling and the dotnet CLI.
NuGet operations have been turned into MSBuild tasks which are run during a build. This task would then load some NuGet libraries as needed. There are other tasks that use some NuGet components as well - such as the Pack target or some tasks used to determine framework compatibility (because NuGet knows which net* / netcoreapp* / netstandard* "frameworks" are compatible with another).
The dotnet CLI also uses some library functions of NuGet to execute commands such as dotnet add package or the dotnet nuget commands.
So instead of a single nuget.exe, you will find some NuGet related DLL files inside the SDK's directory and various components used during the build or command line operations will use functionality of these.
This also means that you can't easily replace them with any nuget.exe you have on your PATH.
Since VSTS has sought to bend to the popular Git source control, I have yet to see a good description of building .Net projects located in Git repositories, having project dependencies on one another.
For instance, in Visual Studio, I build a solution that includes projects with dependencies on each other. Then, in VSTS each of those .Net projects are versioned in separate Git repositories.
How, then, do you get a build on VSTS? How do you get the artifacts (read: DLLs) from one project into the project of the other?
UPDATE: 12/18/17
I took #VonC's suggestion and followed-through on a VSTS (Visual Studio Team Services) hosted Nuget package. I was able to make this work. This process makes .Net solution files and project dependencies OBSOLETE.
If you want to reuse a library, you can save the binaries as a NuGet package.
In the downstream project, you simply assign the VSTS url reference to the Nuget package to get the Nuget Restore to find/place the binaries in your build project.
You will have to download and install a Credentials tool that will allow you to push your binaries to VSTS's package location. Additionally, tell your admin to add the Packages functionality from the VSTS Marketplace.
Thanks, #VonC for the great suggestion!
Here are some helpful links:
Create and Publish the Private Nuget Package here
VSTS Marketplace Package Manager here
The idea is, for binary dependencies (DLLs) to not involve a source control tool (like Git) but a binary referential one (like Nuget)
See for instance:
"Package: NuGet"
"NuGet is now fully integrated into MSBuild"
With Visual Studio 2017 and .NET Core, we have improved the NuGet package management experience by introducing the PackageReference feature in MSBuild.
PackageReference brings new and improved capabilities such as deep MSBuild integration, improved performance for everyday tasks such as install and restore, multi-targeting and more.
First, it’s unnecessary to manage the build artifacts (such as dlls) in source control since they're the output files from the source code.
Then to add dependencies (dlls) from other repos to the parent (main) repo’s project, there usually has below options:
Option 1: manage the build artifacts as packages
As Vonc mentioned, you can manage the dlls as nuget packages, and then add nuget packages to your main repo’s project.
Option 2: git submodules
You can also treat other repos as the submodules for the main repo, and both build the projects from the submodules repos and the main repo in the build, then the main repo project can get the dependencies from the submodule repos’ build artifacts.
Commands to add a submodule for the main repo:
# In local main repo
git submodule add <URL for a submodule repo>
git commit -m 'add a submodule'
git push
Note: in VSTS build definition, you should select checkout submodules in Get Sources step.
Details about git submodules, you can refer Submodules.
Option 3: git subree (alternative way for git submodules)
Treat a branch from another repo as a subtree (a folder) in the main repo. Then build the projects both in the main repo and the subtrees, and get dependencies from subtrees for the main repo’s project.
Commands to add a subtree in the main repo:
git submodule add --prefix=submodule1 <URL for sub repo> master
git push
Then it will add a folder submodule1 with the files in the sub repo master branch, and commit the changes in the main repo.
Details about git subtree, you can refer
Git subtree: the alternative to Git submodule.
At any time, if your branch has working code with any version of dependent assemblies, I can't see any reason you need to do anything.
For example of dependencies here:
You can set dependencies in project like:
Also you can add dependencies in solution like :
You can set build order in solution too if your project has multiple project with dependencies.
As long as your current code in branch from which you are build is working (with any version of different assemblies, e.g. Classlibrary1 has version 1.0.0.0, Classlibrary2 has version 1.2.2.1 & so on but is working fine with each other after referencing) this approach will work.
Project dependencies exist for ages in Visual Studio & .Net. As long those project exist in same TFS branch You can add project dependency right in dependent project. Also you can manage Project build order in Solution.
For more complex scenarios like different repositories or branch dependencies you need to modify build workflow but it is also quite possible.
You can also refer
http://dailydotnettips.com/2015/11/25/how-to-identify-the-project-dependencies-in-visual-studio/
what I saw long time ago when I created same sample for test.
I tried to create a simple .net core using commandline
dotnew new
in a certain folder called netcoreExample and I could see that there are two files created which are program.cs and project.json. Then I add Microsoft.EntityFrameworkCore to dependencies entry in project.json
When I try to run the command
dotnet restore
it shows the package is restores successfully. However, when I inspect the folder where I run dotnet restore from, I didn't see the "packages" folder which is usually created when with the old C# projects running Nuget restore.
I wonder where the dotnet restore output all of the dependencies to.
On Windows by default its %userprofile%\.nuget\packages. I wish dotnet restore -verbosity <verbosity-level> printed out where it was restoring to.
On other OSes its like <HOME-environment-variable-location>/.nuget/packages