I'm owner of framework.
my framwework is published via cocoapods.
but when I want to migrate it to SPM, I find some difficulties.
In fact, my framework has some dependencies.
how can I fix it ?
targets: [ // Targets are the basic building blocks of a package. A target can define a module or a test suite. // Targets can depend on other targets in this package, and on products in packages this package depends on. .binaryTarget(name: "frameworkA", path: "frameworkA.xcframework")]
as you can see my framework is distributed via binary target.
but how can i add dependencies to this framework A?
Related
I have a C# solution which contains 3 projects; Application.Server, Application.Client, and Application.Common. Both server and client have a project reference to common.
I want to pack server and client up so that they can be used by other teams in my organisation. I have some automated build pipeline set up that do so, and they publish the nuget packages for server and client. They do not package or publish common. When I inspect the nuget packages, I can see that they reference the common package.
Is there a way that I can get them to build that project into them self? Ideally I don't want to publish the common package as it's pretty specific to my application, and it doesn't really make sense that it's something that's independently consumable by other departments. I also don't want to have to worry about wrangling extra nuget packages if I can help it (as in reality, Common is actually several projects).
If your projects are "old style"/non-SDK/traditional csproj, AND if any project uses a NuGet package, if all those NuGet references are defined using packages.config, then use you can use nuget.exe pack -IncludeReferencedProjects. However, if any of your projects use PackageReference to define their package references (new, SDK-style projects can only use PackageReference), then nuget.exe pack will not correctly create NuGet dependencies for those packages. For SDK style multi-targeting projects, nuget pack will probably completely fail.
The only supported way to pack projects that use PackageReference, or any SDK style project, is to use NuGet's MSBuild pack target (either dotnet pack or msbuild -t:pack). However, this does not have an equivalent to nuget.exe's IncludeReferencedProjects.
If your projects are SDK style, it really shouldn't be any more difficult to create and publish one package or many packages. Simply run dotnet pack on your solution, and every packable project gets packed (remember to mark any class library project you don't want to become a package as not packable). Then use your favourite scripting language to find and publish all nupkg files. For example (Get-ChildItem -Recurse -Filter *.nupkg $SLN_DIR | ForEach-Object { & dotnet nuget push $_ }, or copy/move all nupkgs to a single place (or use the appropriate setting to make NuGet create the packages there in the first place) and use dotnet nuget push *.nupkg.
The NuGet team recommends one package per assembly, and the tooling automatically creates NuGet dependencies for project references, so it all "just works" out of the box. To create a package with all the assemblies included, instead of NuGet dependencies, requires you to do a bunch of work.
I've tried to add a new reference to my .NET Core project.The strange thing is that I can access also the projects that are involved in my reference. For this example, i should be able to see the Repository project from service, but should not be able to access Entity Project.However , I can still access the entities object from Service.
How comes ?
References in SDK-based projects are fully transitive so - similar to many other package managers like npm or maven - you all the transitive references are available in the project to make sure the app compiles and runs cleanly, e.g. there are no unresolved references when the dependency is referenced and all assemblies are part of the build output and ready to run. (there may even be conflict resolution applied to conflicting version of assemblies resulting in the generation of binding redirects.)
In previous versions, you would need to install NuGet packages or add additional project references to other projects as well to not get build errors or type load exceptions.
Currently there is no perfect workaround if you want your project to do all the things needed to be able to run and resolve conflicts correctly but not pass transitive references to the compiler.
If you only need a dependency to build a project, but not to run it, you can mark a package or project reference as PrivateAssets="All" (add as attribute to the reference in the .csproj file).
If you want to enforce API usage - e.g. for layered APIs, consider writing a roslyn analyzer that will emit warnings if you reference APIs from places you don't want to. this may be suitable for large projects where tooling is needed to maintain the desired architecture.
I have a library, that target NETSTANDARD2_0 that used by full NET461 and NETCOREAPP2_0 clients.
I want to add to the library some Core2.0 specific code.
I am going to add APPNETCORE2_0 target and wrap the section with
#if NETCOREAPP2_0
#endif
It will create 2 separate target DLLs.
When I will refer my library from client Core2.0 application , will it refer NETCOREAPP2_0 DLL and ignore NETSTANDARD2_0 dll?
Is the order of selecting the version predefined and documented?
I will appreciate a link to the documentation.
Here is the official doc on creating these multi-targetted dlls. That explains how a different dll is generated for each target (such as net461 and netcoreapp1.0).
The official doc on how nuget resolves these to find the matching library covers how the right dll is selected:
When NuGet installs a package that has multiple assembly versions, it tries to match the framework name of the assembly with the target framework of the project.
If a match is not found, NuGet copies the assembly for the highest version that is less than or equal to the project's target framework, if available. If no compatible assembly is found, NuGet returns an appropriate error message.
Side note: you want NETCOREAPP2_0, not APPNETCORE2_0.
I am trying to create Team City build template which requires minimum customisation, and I want it to play nicely with legacy projects and projects developed with .NET Core/Standard and .NET CLI.
I am stuck with NuGet as there were some considerable changes in how things work.
Earlier we had to create nuspec file to pack project as a NuGet package. At least in that file we could define various package-related properties.
New csproj file format allows us to define all package properties inside itself. That's fine, but how then do we know which projects should be packaged and which should not?
So far our TeamCity's build step Pack NuGet just contained **.nuspec for Specification files: field. The very fact of nuspec file presence served like a flag pack & publish this project.
However, for dotnet pack we need to specify the project. There is no simple way to distinguish 'main' projects from 'auxiliary' ones on which mains depend. (Let us ignore that project-to-project references are currently not supported.)
We either could pack all projects specifying **.*proj (yet in that case we are to know which packages to publish) or we might specify projects explicitly in a build configuration, but I don't like this approach because you must edit build configuration each time new project is added to the solution.
I also considered the option Generate package on build and omit dot net pack step as package is created on build. The only thing left is publishing the packages with dotnet nuget push specifying **/%BuildConfiguration%/*.nupkg.
Unfortunately when starting build against solution without projects with enabled Generate package on build makes TC fail complaining that
Target files not found for pattern "**/Release/*.nupkg"
Hence, I either need another recipe for achieving the required result or an advice how to make TC consider empty result just as a NOP and mark build as successful.
Yet another option is to use nuspec even for new csproj...
Since TeamCity 2017.2 will be available option to associate build configuration with multiple templates. So you will be able to create different templates to create packages for old projects and new .NET CLI projects.
To specify paths for target .NET projects, which should be packaged, you could use build configuration parameters.
To set such parameters during the build you could send in the preceding build step service message. The value of this parameter could be set to the list of target project files which could be selected via script like that: https://stackoverflow.com/a/8153857/305875
All:
I need advise on how to use Nuget to make my project dependencies (libraries) available to other developers who will in turn have my project as dependency. See scenario below for details:
I have created a Visual Studio 2013 project (ProjA) in a solution (SolA) which has a dependency on a Library (LibA [which I do not commit into source control]). I have used Nuget to manage/fetch the dependencies of project ProjA (i.e. library LibA) via Nuget.Config in .nuget folder at solution SolA level and everything is working ok. Developers are able to checkout solution SolA and build/deploy with Nuget fetching LibA from a local server.
My issue is that I now need to have developers build their project (ProjB) in another solution (SolB) but which will import/use ProjA as a dependent project. Issue is that I cannot find a way to make Nuget fetch the dependencies of ProjA (i.e. LibA) when built as part of solution SolB. I tried putting the Nuget.Config File in the level of ProjA, but VS build seems to ignore it.
Any ideas????
You seem to be mixing two different but not-very-compatible approaches to code sharing here:
Code-level dependencies
Package-level dependencies
Code-level dependencies between different solutions are generally A Bad Thing, and you should avoid them. A solution should encapsulate and build all the source code it needs to, relying on 'library' DLLs (whether provided as raw DLLs or via NuGet).
I recommend that you re-work your solutions using the 'Package-level dependency' pattern, so that you have a separate 'library' solution which provides a NuGet package (or set of NuGet packages) which the other two solutions can consume:
Here is the current (awkward) dependency graph:
Solution A Solution B
Proj A -----------> Proj B
^--------------------'
Here is what I propose with the separate library solution:
+----> Solution L <----+
| |
Solution A Solution B
Solution A and Solution B thus consume the NuGet packages produced by Solution L (the library project). This is the dependency relationship which probably underlies your code anyhow, based on what you describe.