问题标签 [target-platform]

我的理解是，在设置插件的依赖项时，可以选择的插件集是由活动目标平台决定的。

我创建了一个目标平台并将其设置为首选项中的活动目标。我可以在 Eclipse 的“内容”窗格中看到我想要依赖的插件。但是，当我尝试在依赖插件项目的“依赖项”窗格中将插件添加为“必需插件”时，它不在可供选择的列表中。如果我使用原始清单文本编辑器添加它，Eclipse 会抱怨它在“问题”窗格中找不到依赖的插件。

我是这方面的新手，所以如果“它插入了吗？” （可以这么说）想到可能性，这当然是一种可能性。

我没有使用 p2、maven 等...我只是在目标平台定义中添加了一个目录。

I am unable to compile my code despite setting the target platform containing all the required jars. I tried cleaning my workspace and restarting eclipse but it didn't help.

When i include that folder (which contains all the jars) in the build path, it compiles fine.

Kindly help!

由于某种神秘的原因，我的插件项目中的所有目标定义文件 (*.target) 都变空了。

我完全不知道如何解决这个问题。

我正在使用Eclipse 4.4 Luna M5开发一个Eclipse RCP应用程序，并且我正在使用Guice 3.0。 因此，我将 guice.jar 添加到了我的目标平台，并且对于我正在开发的每个插件，我都可以使用 Eclipse 的插件清单编辑器将 bundle com.google.inject 添加到插件的依赖项中。到目前为止，一切正常。

现在的问题是：我想使用 guice 辅助注入 ( @Assisted)。

所以我将 guice-assistedinject.jar 添加到我的目标平台。（我使用的是 .target 文件 = Eclipse Target 定义文件）。

然后在 .target 文件编辑器的“内容”选项卡中，Eclipse 正确地显示了com.google.inject.assistinject来自 guice-assistedinject.jar 的片段包 3.0，但我无法将此包或此包的导出包添加到插件项目的依赖项中正在发展。

当我在插件清单编辑器中按“添加”时，com.google.inject.assistedinject是不是在可添加依赖项列表中？怎么了？

Visual Studio（至少 VisualStudio 2010）将目标平台设置存储在*.suo文件中，显然不应受版本控制。

在我的情况下，这对于中央构建来说没有问题，因为它使用 msbuild 上的命令行选项，根据需要强制目标平台为 x86。

但是，如果一位同事检查了我的项目，他最终会为 AnyCPU 构建并对其进行测试。因为他没有*.suo文件，VisualStudio 会使用默认设置。

不管好坏，这位同事都必须测试 x86。

有没有一种简单的方法可以安全地为解决方案保留目标平台？强制使用默认值的环境变量并不完全是我们所需要的，但足够好也足够简单。

在 Windows CE 项目中，当我选择 Project > Change Target Platform 时，它显示当前平台是 Windows CE。

但是，在 Project Properties 中，虽然 Platform == 相同（“Windows CE”），但 Target Device 属性值为“Pocket PC 2003 SE Emulator”（尽管下拉列表中的众多选项之一是“Windows CE Device”

这是不匹配吗？我应该更改目标设备以匹配平台吗？

这个问题以前在这里问过，但这个问题从未回答过。如何抑制我的 MS 安装程序部署项目中的警告/错误？

谢谢

我假设很多人会将这个问题标记为重复，但让我解释一下我现在面临什么样的问题。

我刚刚注意到解决方案中的控制台应用程序具有x86目标选项，尽管其他所有内容，例如库和相关网站都有AnyCPU目标。

我已经搜索了其他关于配置管理器并AnyCPU为我的控制台应用程序添加新配置的问题，但问题就在这里。我无法创建新AnyCPU配置，因为我收到错误，它已经创建：

这是使用AnyCPU目标创建新配置的错误：

我只是不明白为什么我不能创建这个配置，它没有在我的项目的下拉选择器中列出。

还有一个目标配置可能会更改的地方，它是项目属性的构建选项卡：

我已经AnyCPU在平台目标中设置了值，但平台仍然是x86.

更改平台本身的唯一方法是直接编辑 csproj：

在这里我们提出我的问题：将目标属性放置在两个不同的属性中的想法是什么？为什么控制台应用程序不能默认选择 AnyCPU？有人认为 Visual Studio 团队是故意这样做的。如果我通过编辑 csproj 文件更改目标平台，可能会出现什么问题？

我想在 Delphi XE3 中为 64 位 Windows 构建一个现有的 32 位应用程序。但我无法选择 64 位平台，因为我在项目管理器中没有看到节点“目标平台”。你知道可能是什么原因吗？

这是我应该看到的：

我有专业版，并且已经构建了很多WIN64应用程序。

语境

我们开发了许多插件，这些插件被组装到 Eclipse RCP 3.X 应用程序中。我们使用基于 P2 存储库的单一目标平台，因为这是 Tycho 支持的唯一版本。

目标平台 VS SCM

我们的互联网访问受到很大限制。即使我们配置了代理，我们也无法访问公开可用的 P2 存储库。因此，我们下载 P2 存储库 zip 并将它们放入源代码控制中，以便团队可以共享它们并进行版本控制。但是，我们认为在 SCM 下具有二进制内容通常是一种不好的做法。

我们正准备从 ClearCase 迁移到 Git。在这样做的同时，我们正在考虑更好地改变我们管理目标平台的方式。我们已经考虑过不同的场景，但我们缺乏经验来衡量它们的优缺点。以下是我们反思的第一个结果：

场景 1：为目标平台使用单独的 Git 存储库

• 优点：
  • 插件是共享的
  • 我们稍后可以回到目标平台的“物理”先前版本
  • 更改目标平台就像操作文件一样简单
• 缺点：
  • SCM 中的二进制文件
  • 每个存储库实例使用大量磁盘来保存目标平台的整个历史记录

场景 2：将 Nexus 与插件一起用于 P2 存储库管理

• 优点：
  • 插件是共享的
  • 轻量级存储库：只foo.target需要对文件进行版本控制
• 缺点：
  • 我们以前从未使用过 Nexus
  • 更改目标平台内容更复杂
  • 我们需要手动保存目标平台内容的每个版本的存档副本

问题

您如何在封闭的企业网络中使用 Git 处理目标平台版本控制？您如何看待上述情况及其各自的优缺点？你能建议其他解决方案吗？