I've searched Apple's documentation, open source projects, and Google, and I cannot seem to find any information about SwiftPM.SPMRepositoryError error 5. Heck, I can't even find information about SwiftPM.SPMRepositoryError.
Does anyone know of documentation for this error or the error codes?
What worked for me was switching to ED25519 key.
I think this is happening now because of the effort to improve Git protocol security on GitHub. You can read more about it here: https://github.blog/2021-09-01-improving-git-protocol-security-github/
There you can see the timeline. The final step was put into motion on Mar 15, 2022 (coincidentally that was just two days before your question)
Changes made permanent.
We’ll permanently stop accepting DSA keys. RSA keys uploaded after the cut-off point above will work only with SHA-2 signatures (but again, RSA keys uploaded before this date will continue to work with SHA-1). The deprecated MACs, ciphers, and unencrypted Git protocol will be permanently disabled.
This helped in my case:
File -> Packages -> Reset Package Caches
File -> Packages -> Update to Latest Package Versions
This happened to me on Xcode 13.3 and 13.3.1 when my team added package dependencies that I didn't have Github access to. The error message is ambiguous and shows the same number of errors as the number of packages I have in my dependency tree. But, obtaining access to any repos that I didn't already have access to (which was a smaller number of repos than the error count) resolved the error for me.
I was able to track down the issue by attempting to add another package (anything public like swift-algorithms). Xcode gave me better error reporting in that process.
Updating swift-tools-version in Package.swift file worked for me. We've previously been using 5.3, and updating it to 5.5 or 5.6 resolved the problem.
One thing to keep in mind, Apple has deprecated the existing package declaration functions in Swift 5.6 [1], so using this version would result in a lot of new warnings.
Hopefully, this is just a temporary thing, and a proper fix is coming in the next Xcode version.
Just had the same issue.. (project based on a Package.swift file, not a regular .xcodeproj)
Doubted that it would have to do something with GitHub's policy as described above, since I've worked on other projects today without any issues.
Tried to clear the derived data folder, as well as the project's .swiftpm folder and even the swiftpm repo cache.. nothing helped.
Tried the same project on another MacBook and worked fine!
Then made a fresh clone of the project in a different folder on the Mac with the issue and worked fine as well.
So finally I just deleted the local Package.resolved file, reopened the project in Xcode and everything was back to normal 👍🏻
This seems to be the same issue as Error while fetching remote repositorygit#github.com:***/***.git: An unknown error occurred. reference 'refs/remotes/origin/master' not found (-1) in Xcode 14.
Here is a small script I made to work around it: https://stackoverflow.com/a/74130700/624854.
Related
I am getting this error:
"error: unable to spawn process (Argument list too long)
** ARCHIVE FAILED **
The following build commands failed:
CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
(1 failure)
Exitcode =65 "
I went through this link:
Xcode export localization throws error "Argument list too long"
This article provides a good temporary solution of the problem stating to reduce the path hierarchy. But this does not seem to be an appropriate approach. Can anyone provide me with a different approach to the solution for this problem?
In my case, it was about custom configurations in .xcconfig files.
My config files were including Pods configurations like:
// Development.xcconfig
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.debug (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.debug (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.release (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.release (development).xcconfig"
// Production.xcconfig
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.debug (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.debug (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.release (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.release (production).xcconfig"
This produced the error you mentioned, when I added Firebase pods into my Podfile.
So to make this compile again I had to:
remove all inclusion (#include ...),
set them explicitly in the Project -> Info -> Configuration, as follows:
Quick tip:
If you don't want manually setting up corresponding target configurations (those with red icon), mark them as None and run pod install. This will automatically change it for you.
A few days ago I faced a similar challenge. I want to provide details and share my research with SO community.
First of all I found this thread and I followed the link in the asked question.
And yes, thats right, the answer marked in the link is correct, but the solutions to this problem did not suit me.
Problem
In my case, I had this problem when I changed the folder hierarchy in my project to be more convenient and suitable for me.
#oOEric option did not suit me, because according to the rules, the hierarchy of groups in Xcode should coincide with the hierarchy of folders in the system.
But I've already had about 1680 swift files to compiling.
The problem was that I had too long path to the compiled files and their number was too large.
Research
Then I start research and found swift jira with the same bug.
Here some links:
Main
Linked Issue 1
Linked Issue 2
Linked Issue 3
Bug on Open Radar
But here I didn't find some solutions for me.
Most of all I was pleased with this response of the swift developers.
Again, this is an Xcode-side issue, not a Swift-side issue. Commenting here won't make the Xcode engineers work any faster!
(We're not all the same people at Apple.)
Okey, after this answer, I was finally convinced that if it is an Xcode bug, then the solution should be sought in Xcode.
Solutions
Temporary solution
You need to move your project higher in the hierarchy of your system.
I choose this one, because I have really big project and the use of other solutions will require more than one day from me.
In my case, I conducted an experiment and calculated that the length of the path to the project should be no more than 50 characters.
But this is a temporary solution. If your project grows further, you will have to shorten the path or use other solutions.
Cocoa Touch Framework target
This solution is suitable for files that do not use dependencies.
First of all you need to add Cocoa Touch Framework as a target to you main project.
This target should be added automatically to Embedded Binaries and Linked Framework and Libraries.
After this you need to find some files without dependencies and change target membership to your "TestTarget".
Don't forget classes, properties, methods, enums, protocols from cocoa touch framework should have open or public access.
And don't forget clean your DerivedData folder.
Modular iOS
This solution has a more integrated approach.
If you want to use any dependencies in your Cocoa Touch Frameworks you should go to this guide and make more complex refactoring for your big project!
Link to solution
I think this is the best solution.
I hope this big answer will help someone!
I solved this by setting build system to Legacy build system
in file-> workspace setting -> select workspace setting
I solved this by reducing the hierarchy of groups in Xcode.
e.g. original files at project_name/project_name/About/Model/Text
I removed the groups "Model", "Text" and moved files under project_name/project_name/About/
I made simple script for temporary fix that problem. https://github.com/gregoryvit/flatter
It simply move all swift files in Xcode project to root group.
Error - unable to spawn process (Argument list too long)
There are many reason for this error. Some of these are mentioned below:
Your project might have many swift files (say more than 2000)
Most of the Swift source files may be deeply nested inside directories
Many of these files have absolute paths with more than 150 characters (eg. /Macintosh HD/Users/jayprakashnd/mySampleProject/Module1…)
Xcode swift complier takes the absolute paths of all source files while so compiling, the ARG_MX limit is reached and build fails.
This has been fixed in Xcode 11 wherein a flag is used to set unlimited number of swift files.
Solutions:
Switch to Xcode 11 and add USE_SWIFT_RESPONSE_FILE to YES in build settings - User Defined Section
If you cannot switch to Xcode 11 then take a new checkout of your project in Macintosh HD ▸ Users directory with folder name as minimal as possible.
Solution 2 worked for me like a charm!
It happened to me when I use Xcode 11 beta version using Live Preview. Then I solved it by restarting Xcode after that error has gone.
I have fixed this issue, moving my folder of My Xcode project to the mac root and changing my name Folder to less characters.
Terminal: cd /
Change name folder to BX (example).
xcode11
-build setting
-user-defined
-add setting: USE_SWIFT_RESPONSE_FILE
-setValue: YES
Doing this you enable xcode to have more files than is allowed. But im not sure if this always solve the problem.
I have changed build type to legacy and it also resolved problem for me, both locally and on our CI builder. For me it was caused during checking Podfile.lock and Manifest.lock. Probably this could be skipped in our pipeline since we are always installing pods on CI.
If you faced this issue on your Flutter project while building in Release mode (or Archive) check out my this answer: https://stackoverflow.com/a/61446892/5502121
Long story short:
set your build system to New Build System in File > Project Settings…
remove ios and build_ios folders
run flutter create . to init new ios module
run pod install
run flutter pub get
check your Xcode build config (it should be Release mode and General iOS Device)
and you're good to go
I have the same problem. I fix it using a temporary solution, however that work for me.
My solution is to change the Derived Data folder to a directory with a shorter path.
The Steps is as the following:
Xcode -> File -> Workspace Settings... -> Select Custom Location for Derived Data and give a shorter path as the location.
I've been trying to get On-Demand Resource to work but I keep getting this compile error:
/* com.apple.actool.errors */
: error: The tag combination "tagName" for "xxx.imageset/xxx#3x.png" has no output specification.
I had a look at actool man page and there's an option:
--asset-pack-output-specifications filename
Which says:
Tells actool where to write the information about ODR resources found
in the asset catalog. The emitted file will be a plist.
But I'm not really sure what to put as an argument/where this plist is used or even if this option is in the right track of fixing the error.
My coworkers and I struggled with this error for over a day and were only able to fix it by wiping our existing local repos and installing a fresh clone from our remote repos with the code that contains the on-demand resources.
In our case, I was the one that created the on-demand resources functionality and did the tagging for the assets. I built and ran all of that code, and everything worked fine locally on my machine. I pushed those commits to our remote, and when my coworkers pulled they received the asset catalog compile error that you reported when they tried to build.
I compared my build logs with those of my coworkers and found that I had the --asset-pack-output-specifications flag along with a filename whereas they did not, even though all of our production code was the same. I never set that flag manually myself during development, it was automatically generated at some point in the process but I have no idea where -- I didn't even know it existed until this build failure occurred. After struggling for many hours we noticed that if my coworkers deleted their local projects entirely and basically started fresh by installing a new project and repo again from the remote, they suddenly were able to build. They had already tried to clean and nuke their derived data, but that didn't work. Only totally deleting the repos and the projects entirely did the trick. Not sure why, but something about wiping the project and all associated directories and building themselves totally fresh from their own local machines triggered something that enabled the --asset-pack-output-specifications flag.
I just faced this issue and was totally against deleting my repo and cloning again.
I noticed that alongside this error, I also got a warning stating that I had assets under the same name (thus being duplicated).
Deleting the duplicated asset in order to get rid of the warning, fixed the compilation error.
Hope this helps someone, as deleting the repo and cloning again shouldn't be an option.
I just faced the issue.
I could solve it just by deleting on-demand resource tags and tagging them back again.
I just solve it by rebooting Xcode then run successfully. The error seems to only appear once...I don't know why.
I'm trying to get VSCode working with my Unity projects, and every time I select the Project icon (the little fire at the bottom) I get the following error:
Error: Failed to connect to OmniSharp
Is anyone else getting this?
You need to download the most recent version of "mono". Open up terminal and pass in brew install mono. Then "Pick a project" and select the ..-csharp.sln file and you should be up and running.
Ok, made some progress and gotten a few Unity projects working. It seems that you need some prerequisites installed, a clean up of your Unity project folder, and possibly some hand editing of your .sln and .csproj files.
I posted a (possibly) better answer over on Reddit. Hope that's not breaking stack etiquitte.
http://www.reddit.com/r/Unity3D/comments/34d6gc/visual_studio_for_mac_help_us_vote_for_unity/
i get this on windows when my project directory has a space in it
i removed the space and removed the error
i expect it will be fixed soom
I have a completely different answer: it's the runtime that VSCode is using. It doesn't match up with what it thinks it needs. I have to remember that we're still in beta and that things are changing rapidly. I had my dnvm running beta 7, but VSCode (and OmniSharp, by extension) is looking for beta 6, so it was failing. I updated my runtime using this this post as a clue. Now I have VSCode 0.7.0 using the beta 6 runtime. I have no idea how to tell what it's looking for...I just guessed based on when they were both released. HTH
I have an ASP.NET MVC 4 application. I used NuGet to update all of the NuGet packages that were installed when I created the application. One of the packages was Microsoft.Bcl.Build.
After updating these, NuGet displayed the following message at the bottom of its window:
I have since restarted Visual Studio several times, but the message still exists. When I checked the installed packages, it did appear that the updated version (1.0.8) of the package was present.
How can I fix this?
Instead of deleting all of ~/packages, see if there are any *.deleteme files in ~/packages and delete them. Then restart Visual Studio.
I believe this problem is caused by the packages being read-only or otherwise inaccessible at the file system level.
Packages under source control
Temporary work-around (untested)
Check out the entire packages folder prior to telling NuGet to restart Visual Studio to delete the packages.
Permanent work-around
I found that this could be permanently resolved by removing the packages from source control and instead using NuGet Package Restore.
Packages not under source control
Temporary Work-Around
I worked around this by deleting from the solution's packages folder all of the files that referenced the package in question. Specifically, these were:
Folder: Microsoft.Bcl.Build.1.0.7
File: Microsoft.Bcl.Build.1.0.7.deleteme
In my case, the relevant package folders remained in ~\packages, although they were empty. I deleted the folders and restarted Visual Studio, and this warning went away.
I've just deleted the folders of each package that had error in the Packages folder in my solution folder and also deleted the .deleteme files and everything works fine!
1) Delete the entire ~\packagesfolder.
2) Restart VS.
3) Go to Manage NuGet Packages and Restore
I'll agree that this can happen when your packages folder is under source control. If you like to have it there, instead of removing the bindings you can check it all out, remove the package with the NuGet Package Manager, and then check in after wards.
In my experience, I found my answer on this thread, but using a combination of a couple of different answers above so I thought I would share what I found.
I had the exact same issue with "Microsoft.Bcl.Build" as the original poster. I had been trying to update references for other functionality using NuGet and had issues with some of the updates (compatibility then rollbacks). After this NuGet failure, I started getting this error.
I initially used the selected answer and Jedidja's answer and was able to get this to work, but it only partially solved my problem. It did fix the VS restart error, but it caused a downstream issue with TFS as I could no longer check in the project as it was expecting that "*.deleteme" file. This got me thinking, so I did some testing. When I restored the file from recycle bin, I started getting the restart error again.
Here is where I deviated from the posted answers and got my full resolution to my version of the problem.
When I checked into TFS this time, the project checked everything in (after I got the projects all updated using NuGet while the "*.deleteme" file was deleted). Once it checked everything in, I noticed that file was still pending check-in so I checked the solution in again and TFS accepted that file, but it was as a deletion....assuming it checked in the first time and then VS auto deleted it which required the second check-in. Anyway....after the last pending change check-in, the file was gone and VS no longer complained about needing to be restarted. I can't say for sure because the problem is gone, but I get the feeling if I had checked the code in before deleting the file in the first place it might have solved the problem without manual file manipulation.
** Hi, everybody.**
i resolve this problem this ways.
If you have source control run the vs as administrator ( it is important )
in the solution packages -> delete thing about packages.
sample -> i deleted all entity framework version folders.
restart the vs
open solution and solution right click -> manage nuget packages for this solution.
you will see restore button :) restore
that is all.
If you are using Entity Framework 6, then you can install the NuGet package "EntityFramework.SqlServerCompact".
This enabled me to use the standard ASP.NET Identity tooling that comes with the project templates for 2013 and MVC5.
I just upgraded my Xcode, now when I try to open my project, I get this error:
Project /Users/xxx/xxxx/xxxxx/xxxxxx/xxxxxxxx.xcodeproj cannot be opened: PBXContainerItemProxy (xxxxxxxxxxxxxxxxx) is missing a containerPortal key
I have searched the web and stackoverflow, but cannot get anything relevent to come up at all regarding this.
I do have Three20 as part of my project, I don't know if that matters. I just upgraded to xcode 4.4.1
Thanks for any insight.
-D
the project icon which we see i.e projectname.xcodeproj, is actually a directory, you do this
1. in terminal do cd yourproject.xcodeproj
2.ls
3.vi project.pbxproj
4. scroll down till /* Begin PBXContainerItemProxy section */
5.there you will see all sections check for the section which is missing a portal key edit it and save it :wq it will work
in image if you see the first section is missing container portal key.just pic it from other section and replace it..
it will work :D see this link
Now I should start with that I do not know the actual error, never seen it before, but I did find a reference to a "PBXContainerProxy"-error in this post (As soon as I add a project to XCode 4.0.2 it crashes) and thought you might try the solutions from there?
"Apparently this is due to the new version of XCodeProjects. I found a
work around by pre-compiling the library that was causing the issue
and then using the linker to link to the .a file. I also had to copy
the .a library into the DerivedData path.
The real solution was to remove the project and replace it with an
updated project for the new version of XCode."
Hope that helps somewhat :)
Never saw that error either, but if you're upgrading directly from XCode 3.X I'd suggest you to go to https://developer.apple.com/downloads/index.action?name=Xcode
and download/install a previous version of Xcode somewhere else. (You can have several different copies installed on your machine, just google it if you don't know how but just remember to use xcode-select to pick the one you want to use). Repeat with all the versions back to 4.0.1 until (hopefully) it works. I know it's tedious but it might help.
If it does, validate the project settings and try to open it with 4.4.1. That should work.
Good luck