I'm trying to build MailCore into my app but I keep getting
"_OBJC_CLASS_$_CTCoreAccount", referenced from:
That is the only error I'm getting and CTCoreAccount is in the project.
In order to use mail core framework, visit the link follow step by step process and you are done.
I have an answer. It is not "The Answer" but I have an answer and it worked.
Eidt: For this: After a slew of issues, I've realized that "this" particular fix is that you need to add libmailcore.a to the frameworks. It keeeps getting deleted by XCode, or you may ahve added the MailCore Framework instead.
Started a fresh project, erased everything by removing application files to trash, then deleting references. "Added" via group (unsure if it matters) all my folers/files from the project I was trying to.
Had to tell it where the pch and Info.plist were, (essentially pointing it to my old project). Re-added all frameworks, and voila, it compiled.
I'm suspecting XCode 4.5 has different framework settings as far as library paths and valid flags for linker, etc. But nothing I tried regarding that fixed it. I would love to do this more direclty, old project is on 4.3, and won't be upgrading it if this is happening. Anyway, up and running, hope others are soon too. Would like real answer myself
Related
After updating some NuGet packages, it turned out that some things in my website got broken by new code. I updated to the new Unity inversion control 5.0.0, etc. So after a while of hunting around and trying to fix it, I was able to get it to finally build and launch the site. However, the Unity IOC was broken because I kepts getting the "Error in Application '~/', controller must have a parameterless constructor". I saw that my couple of Unity files (UnityConfig.cs and UnityMvcActivator.cs) were gone, so I replaced them with ones I had in the backup folder.
Well, now it launches a loading site, but in VS it now says "UnityContainerExtensions.cs not found". I see that it looks all over for this file, around 'C:\ Program Files (x86)\Microsoft Visual Studio 14.0\VC...' and then it goes looking through 'c:\projects\unity]Abstractions\src\Utility...' - a folder that I can't even see.
This is in VS2015, doing a web application with Framework 4.6.
What can I do to just make it work again, as when I first had it so many months ago?
Alright, I was able to fix my Unity problem by rolling back on some of the packages. I'm the kind of person who likes to have no notifications, so I clicked Update All, and apparently the updates weren't necessarily compatible with my project here. To get it working again I has to bring back:
Unity.Abstractions = 2.0.0
Unity = 4.0.1
Unity.AspNet.WebApi = 4.0.1
Unity.Mvc = 4.0.1
Now to great relief, all works just as it did before!
However, I do wish I knew why the breakages happen and also why these packages are listed as updates when they are not going to work with my project.
Till the future, my system is going to have to consist of a Post-It "Do not update these xxxx packages, they will break stuff". And I wish to gain an understanding of what is the reason behind such Unity mess.
I am working on a fork of the Xbox HID project (to allow greater configuration of the controller) and came across a really strange issue.
The project is three projects, which I have grouped together under a workspace, which works well, it compiles them in order (kext, daemon and prefpane) and all works.
However, I decided to uncrustify the code (thanks Alcatraz!) and standardise the names and locations of source files. This required me to update the project as file paths changed.
Once this was all completed the PrefPane wouldn't load. For some reason it was instantiating and sending initWithBundle to an object that was NOT the File's Owner in the XIB.
After a lot of debugging and hair-pulling I discovered the object it was instantiating also happened to be the first file listed in the Compile Sources build phase. Once I moved the correct file to the top of that list the PrefPane once again launched and worked as expected.
That seems wrong, why does it need to compile this particular class first... better yet, why is it picking up only the first compiled class instead of the one specified in the XIB?
I am using Xcode Version 6.2 (6C131e) under OSX 10.9.5, however, I am using the OSX 10.6 SDK and have 10.6 as the deployment target.
I was having some other issues with the project in question, so I rebuilt all three projects and this issue went away.
I am guessing there was some sort of issue with the Xcode project itself as I believe it was probably upgraded from at least two previous major versions of Xcode.
Lesson here seems to be, rebuild the project files themselves and see if that fixes the issues!
After updating with Xcode 6.3, I found something strange things with my projects.
Below codes causes parse issue that says "Could not build module 'AgendaFramework'", the AgendaFramework is my custom embedded framework for ios8:
#import MyEmbededFramework;
The error marker looks like this:
The issues is raised during indexing not building. Whole building can be performed successfully without any error or warning. I can build, archive, run on device, deploy, submit to App Store.
However the error marker shows up when I edit the classes that belongs to the extension. The the extension(widget) explicitly linked to the embedded framework. (I know that I don't have to do it when I use #import statement.)
In this state, I could not receive any valid content assistant, very annoying.
After I replace the import statement with old style, the problem was disappeared:
#import <AgendaFramework/AgendaFramework.h>
I have several other projects that have very similar topology with the project which causes this issue, But they are okay. Only one project causes this issue. I compared every detail build settings, I could not find any clue.
I tried:
Delete derived data
Full Clean
Reboot
Any clues are welcomed. Thanks!
It looks like turning on:
Allow Non-modular Includes In Framework Modules solved this issue for me.
Hi this is due to the fact that file which you are making it public in framework header must be public also.
Sometimes this issue can be solved by adding the framework to the same folder as the .xcodeproj file, no subfolders or anything.
Credits to Jonny who points it out as a comment in the question.
Solution that worked for me: diligence in framework header file orientation to system style imports... like #import <CoreXLib/CoreThreads.h> the story:
In my case my framework that I built came from the combination of several code bases as it became apparent that I could reuse some of the general design patterns across that code easer via Framework vs the fragile Xcode project pathnames.
As I built my framework "CoreXLib", I reorganized it into the Cocoa Framework typical of Xcode. I changed my imports from:
#import "CoreTypeAliases.h" // project local style
to
#import <CoreXLib/CoreTypeAliases.h> // system or framework style
appropriately. Several projects that used the CoreXLib.framework which includes the public headers in the lego-folder worked... so I thought I was good to go...
Unfortunately some of the headers that were public did not get fully updated. The classes in the framework built just fine in the local style. All projects using it worked up to this point and then I ran into one that didn't... and the error noted by #jeeeyul
So after finding this thread and finding #kwz 's solution, and not having it do anything in my case, I decided to polish the code up while I was trying to figure this problem out. In the polishing, I found that some of the #imports did not get changed like they should have in the Xcode search and replaces. Time for some hand-jamming...
After fixing all of those references in all of my CoreXLib project headers (not just the public ones, self defense), I dove back into the problem... I took the newly complied CoreXLib.framework over to the errant project that embedded it... and the problem had vanished! I checked the Allow Non-modular Includes... in both the framework project and the project that linked the framework in and both were "No". Flipping both to "Yes" and to "No" made no difference in several tests. The only other change was the #import "..." to #import <CoreXLib/...> modifications.
So sometimes polishing the apple 🍎 knocks the bugs🐞🐞off...
set YES in Build Active Architecture Only in build settings.
It worked for me.
Today I solved this problem by those steps,:
Chose the schema "MyEmbededFramework"
Press [Command + B] to build
From the build phase panel, add "MyEmbededFramework.framework" to Link Binary With Libraries
Try to build your project, the problem may disappear now.
you can try this, it's work for me. delete DerivedData dir that about your project.step by step
Turn off module's in build settings. That may work
I just downloaded and compiled Pantomime for SMTP use in my Cocoa Application. The first issue was that it is old... so I changed the build settings to use the most recent SDK as well as eliminate the old PPC build settings.
After those changes, everything compiled nicely (or at least appeared to do so.)
Next, I installed the Pantomime.framework into the /Library/Frameworks directory per Apple documentation recommendations.
Then, I imported the framework into my project under the Build Phases tab where it says "Link Binaries to Libraries".
So far everything seemed to work as it did with WebKit.framework, and ScriptingBridge.framework.
Finally, I added the following to my code:
#import <Pantomime/Pantomime.h>
I got as far as "Pa" when it auto completed the rest, so it apparently knows what I'm looking for. However, when I try to compile my code, I receive the following error:
Lexical or Preprocessor Issue "Pantomime/Pantomime.h" file not found.
All of the other frameworks seemed to work, but this one does not, and I really don't know why (I'm relatively new to working with frameworks.)
Anyone have any ideas on what I'm doing wrong here?
Thanks!
I've never used Pantomime, but this happens to me all the time with Xcode, so although I'm a newbie to development in general I'd wager it's just a bug with Xcode. Here's how I fix it:
In Xcode, hit command-1 to switch to the Navigator's file/folder view.
Reveal the Pantomime.h and .m files in the Finder, wherever you've stored them.
Drag them into the Navigator.
Xcode will prompt you to confirm adding again, and I usually leave it set as is to "copy files if needed".
Xcode will import. You should then delete the old references in the Navigator. It should work fine after that.
I have met this problem.
The solution is setting 'Build Settings' --> 'Header Search Path' Value where your pantomime is. Good luck!
I noticed since Xcode 4.3, the audio unit templates are gone and the audio unit headers and helper apps are a separate download from Apple's website.
I have no idea what to do with the downloaded folder... I tried putting AU Lab And HALLab in Xcode.app/Applications and they don't show up in the new developer tools menu; I tried placing the CoreAudio folder with the headers in Xcode.app/Developer and even recreating /Developer in my root and Xcode doesn't see AUEffectBase.h anywhere (unless I actually add the file).
I saw someone's post on how to come up with a new from-scratch template but I won't even go there yet since Xcode doesn't even find the headers right now.
Any ideas on how to go about making it all work again?
And about the templates.. I can forget about them right, meaning, the ones we used to have from Apple?
Thanks!
If they are in your project, and referenced by Xcode, then you will have to update those project references. Xcode may refer to them as absolute path, relative to project, relative to SDK and a few others.
At this point, you might consider creating a static library for these dependencies, if you have multiple AUs to build out. Then you just create a static lib to link to, rather than managing a handful of sources per AU.
Templates: It appears they have been removed (temporary? permanent? idk). I moved off distributed template dependence years ago. Perhaps you can scan or hit the CA-API list and see if a dev has one handy.