My question is, it seems like difficult to get the framework cartfile name in Carthage whereas in CocoaPods it is too easy by using this like https://cocoapods.org/ we just copy and paste it.
Is there any websites or place to get all the frameworks cartfile name for Carthage dependency tool?
CocoaPods is a centralized dependency manager, which is why you have cocoa pods site listing out all of the available pods ready to be integrated into your awesome project.
Carthage is exactly opposite of that,
By contrast, Carthage has been created as a decentralized dependency
manager. There is no central list of projects, which reduces
maintenance work and avoids any central point of failure. However,
project discovery is more difficult—users must resort to GitHub’s
Trending pages or similar.
Related
I have a project, made up multiple smaller projects. I manage this mess generally through Carthage, but for development, I make use of a xcworkspace, to make it easier and faster to make changes, and Xcode to build the child and master projects via the workspace.
I've recently started updating all the projects to make use of the new XCFrameworks format (instead of the "fat frameworks" which Carthage/Xcode use to generate).
If I'm just working on the root project (xcproject) and linking the XCFrameworks directly, it all works fine. The moment I switch to the xcworkspace and replace any of the XCFrameworks with it's XCProject, the build fails
Multiple commands produce '/Users/.../Library/Developer/Xcode/DerivedData/gnuwolzggqlzhlfiipjzbigitmvu/Build/Products/Debug-iphoneos/....framework':
1) Command: ProcessXCFramework /Users/.../Development/.../.../Carthage/Build/....xcframework /Users/.../Library/Developer/Xcode/DerivedData/gnuwolzggqlzhlfiipjzbigitmvu/Build/Products/Debug-iphoneos/....framework ios
2) Command: ProcessXCFramework /Users/shanew/Development/.../Libraries/.../Carthage/Build/....xcframework /Users/.../Library/Developer/Xcode/DerivedData/gnuwolzggqlzhlfiipjzbigitmvu/Build/Products/Debug-iphoneos/....framework ios
The sub project frameworks DO NOT embedded their dependencies (as if I recall, this caused other issues) and dependency management is managed through Carthage, so the root project AND the child project will share dependencies, which I think is the cause of the issue.
I had some "minor" luck, if I built the sub project first and then remove its "Frameworks, Libraries, and Embedded Content", I could get the root project to work, but when I tried to do this with multiple sub projects I started to run into issues.
I did note that when I remove the xcframeworks and replace it with the project, it displays the project with the "fat framework" icon, instead of the xcframeworks icon ... I doubt this part of the issue, but thought I'd mention it...
So, the question...
How do we include "sub projects"/"frameworks", which have xcframeworks dependencies (shared with other projects) into a xcworkspace and have it build without triggering the "Multiple commands produce ... output" errors.
Not sure this totally maps to OP scenario, but here's what worked for us.
Initial, working setup with .framework:
Workspace
Framework project
Depends on 3rd-party framework ZZZ, through Carthage
Has its own Carthage cartfile and Carthage directory
Linked to ZZZ .framework binary from Carthage\Build
Application project
Depends on Framework, through Xcode target dependency
Depends on 3rd-party framework ZZZ, through Carthage
Has its own Carthage cartfile and Carthage directory
Embeds and linked to ZZZ .framework binary from Carthage\Build
Then we moved 3rd-party dependency ZZZ to XCFramework, still through Carthage, and the same setup was not working anymore. Our framework was building fine, but building our application failed because multiple commands where trying to produce ZZZ.
What worked for us, in the end, was to modify Application project and the way it includes the 3rd-party framework ZZZ. Instead of having its own Carthage-managed dependency, build directory, built binary, etc. for the 3rd-party dependency, the Application project embedded and linked the same binary taken from our Framework Carthage\Build directory.
So a setup like the following:
Workspace
Framework project
Depends on 3rd-party framework ZZZ, through Carthage
Has its own Carthage cartfile and Carthage directory
Linked to ZZZ XCFramework binary from Carthage\Build
Application project
Depends on Framework, through Xcode target dependency
Does not explictly depend on 3rd-party framework ZZZ, through Carthage
Has no own Carthage cartfile and Carthage directory
(or anyway the 3rd-party framework is not listed there)
Embeds and linked to ZZZ XCFramework binary from Framework\Carthage\Build
Hope that makes sense.
The story is different when an Application project depends on our Framework not through Xcode target dependency, but through the raw XCFramework file copied somewhere. In that case, Application project must again explicitly depend on 3rd-party framework ZZZ through Carthage, and embed/link the XCFramework binary from its own Carthage\Build directory.
I created one Swift Package Manager dependency and I need to add a Carthage support in order that depndency later to be used with Carthage in a project. Can someone explain the steps involved in doing this?
Adding Carthage support to a dependency that uses SPM should be the same as adding Carthage support to a dependency that doesn't use SPM. The presence of SPM support should not impact Carthage at all.
The Carthage README has steps for adding Carthage support to your package. To summarize:
Make sure your Xcode schemes are marked as Shared.
Make sure carthage build --no-skip-current successfully builds your dependency.
Make sure to tag your releases with git tags.
OPTIONAL: prebuild binaries of your framework for quicker installation
The thing is a SPM package doesn't need a xcworkspace file. See e.g. one of my framworks for example. In that case using it as carthage dependency is not that straightforward or even possible.
The second thing to consider is that Apple changed the way resources, bundled with a framework are located from the app hosting the framework:
Important
Always use Bundle.module when you access resources. A package shouldn’t make assumptions about the exact location of a resource.
The main pain point here is that this struct is generated when SPM builds the framework but is not created when Carthage builds it. Read detailled information here.
If both points above don't aplpy for your framework then moshe-katz is right and you can just follow the proposed setup instructions. Otherwise please tell me how that works. I already search a solution to this problem for quite some time.
I have my own Nuget package source for internal libraries. Some of the projects reference other projects in the same solution. Currently the dependencies are referenced to the Nuget package. Management of this be becoming a pain since if a project that has a dependency is updated, I have to wait for that dependency package to update so I can update the other project with the new reference. Some of the projects have multiple layers of dependency, so in some cases I to wait for 5 builds (build, update package, build, update package in next level, etc.) to get the package into the main project. Is there a better way to manage this or is this just the price to pay for using Nuget?
Ideally you wouldn't include your libraries in the solution for a given application and only add them to the solution via NuGet. You can manage versioning between the NuGet Packages in the packages.config file of a given library and by referencing NuGet Package versioning.
When I have a situation where I need to step through the library code from the consuming application then I remove the NuGet package and add the library project to the solution. Then add a project reference from the application to that library project. Ideally this should be a rare occurrence.
I have created versions of NuGet packages,uploaded and it is working fine.
I have set of libraries in my package which has been populated in different directories inside the package.
Some users might require a particular directory of my NuGet package, and some of the libraries might not be needed. While installation I should prompt users that which part they need to install.
One Solution:Logical seperation of packages may be one solution. Like packing libraries in separate packages, and required packages can be installed.
But If it has been made selective installation, then it would be more easier. I have no idea whether NuGet have such an option. Any help would be appreciated.
NuGet has support for framework versions and platforms using conventions, you can read up on them in the docs. You can group them by target framework version or by target framework profile.
If you want to selectively install libraries, you are saying you want to selectively install dependencies: you should split them up in separate NuGet packages and declare your dependencies. These dependencies also can be grouped.
If your condition cannot be defined using framework version or profile, you should come up with your own entry-level NuGet packages and bring down the proper dependency chain (or use PowerShell hooks for this).
I have a package Ninject.Extensisons.Wcf which shall be installed differently depending on the type of the project to which it is installed. In the case where WCF is hosted in IIS (any project containing global.asax) a second package Ninject.Web.Common needs to be installed together with the package. For all other project types such as libraries, Console, WinForms, WPF applications this package should not be installed.
Is it somehow possible to achieve this e.g., using a powershell script? Or do I have to deploy two different packages in this case?
Unfortunately the current nuspec file does not provide for managing dependencies based on project type. We currently support targeting different framework versions, but that doesn't apply in your situation.
It is recommended that all dependencies are handled using package references. Although it would be technically possible to download and install a package using a PowerShell script, this is not supported and will most likely break in future versions.
First determine if it would actually be a problem to reference a web package in a non-web project. Just because assemblies are referenced, if they are not used, it should not have an impact.
If it turns out that having the web dependency causes undesirable side-effects, then you'll need to create separate packages.
I would split up your package into logical pieces. As you state, you have a package that is used by non-web projects. Web projects require a dependency on a different package.
So now you have 2 logical packages:
MyProject
MyProject.Web
MyProject (dependencies)
SomeOtherPackage
So a user would Install-Package MyProject for non-web projects, and Install-Package MyProject.Web for web projects.
At this point you would be done and everything would be fine. But I think you should consider another step. One of the issues I see with these split packages is that I have to figure out which particular package I need to install. I have to know that I need the "Web" version.
At this point, determine the typical use case for your package. If 90% of your users will be installing the Web version, then I would make a "meta" package that simply has dependencies for your common packages.
In your case I would make 3 packages:
MyProject (meta package)
MyProject.Web
MyProject.Web
MyProject.Core
SomeOtherPackage
MyProject.Core (common non-web package)
By creating the "meta" package, you can reserve the "short" package name for the most common case. This meta package only has dependencies to other packages.
A good example of this is the SignalR package.
Hope this was helpful.