Obj-C框架集成第三方后报错：非模块化头文件引入问题求助

针对你遇到的「Include of non-modular header inside framework module」错误，结合你已经尝试的操作，这里补充几个可能遗漏的关键步骤：

1. 确认第三方框架的模块化属性 #

检查WindowsAzureMessaging.framework内部是否包含Modules/module.modulemap文件：

• 如果没有这个文件，说明该第三方框架本身不是模块化框架。这种情况下，你不能在MyFramework的public伞头中直接用<>语法引用它的头文件，需要改为在MyFramework的私有头文件或实现文件中用引号#import "WindowsAzureMessaging/WindowsAzureMessaging.h"引用，同时确保MyFramework的「Header Search Paths」正确指向该框架的路径。
• 如果存在modulemap文件，确认其中的声明是否正确，比如是否包含framework module WindowsAzureMessaging { export *; }这类标准声明。

2. 调整MyFramework的依赖嵌入设置 #

在MyFramework的Xcode项目中：

• 打开「Frameworks, Libraries, and Embedded Content」面板，将WindowsAzureMessaging.framework的嵌入状态设置为：
  • 如果MyFramework是动态框架：选择「Embed & Sign」，确保该框架被打包到MyFramework的产物中，这样集成到TestApp时不会出现路径找不到的问题。
  • 如果MyFramework是静态框架：选择「Do Not Embed」，但需要确保TestApp在集成MyFramework的同时，也手动引入WindowsAzureMessaging.framework，并添加正确的搜索路径。

3. 检查并同步「Allow non-modular includes」设置 #

• 不仅要在MyFramework的项目中开启「Allow non-modular includes in Framework modules」（Build Settings -> Search Paths分类下），还要在集成MyFramework的TestApp项目中同样开启这个选项。因为当TestApp编译时，会处理MyFramework的模块信息，若第三方头文件是非模块化的，主项目也需要允许这种引用。

4. 调整MyFramework的头文件暴露策略 #

如果你不需要将WindowsAzureMessaging的API暴露给TestApp，建议不要在MyFramework的public伞头中引入它的头文件：

• 将#import <WindowsAzureMessaging/WindowsAzureMessaging.h>移到MyFramework的私有头文件（比如TestManager.h的私有部分，或者单独的私有头），或者直接在.m实现文件中引用。
• 这样既避免了模块化冲突，也符合框架封装的原则，隐藏内部依赖细节。

5. 验证Framework Search Paths配置 #

在MyFramework的Build Settings中，确保「Framework Search Paths」包含WindowsAzureMessaging.framework的正确路径，并且设置为递归（勾选Recursive）。如果是相对路径，要保证打包后路径依然有效，比如使用$(SRCROOT)这类变量来定位框架位置。

尝试以上步骤后，重新打包MyFramework并集成到TestApp，应该能解决路径找不到和非模块化头文件的问题。

内容的提问来源于stack exchange，提问作者user591410