InstallShield 必须是现存最糟糕的“行业标准”应用程序，原因不胜枚举。但是，其中一个缺陷是我希望能够修复的，并且在我第一次尝试为 Visual Studio 编写扩展时（目前使用 2015 版本）。
InstallShield 创建了一个 .isproj 类型，以允许与 Visual Studio 集成。这允许开发人员创建一个安装程序，该安装程序将项目的输出作为要包含在安装程序中的文件引用（而不必手动选择要包含的单个文件）。只要 .isproj 是在 Visual Studio 中构建的，并且在引用您需要输出的项目的解决方案中，这种方法就足够了。
但是，我也有一个用于我的安装程序项目的自动构建，我们使用 MSBuild 在构建服务器上运行。尝试以这种方式构建时，我们收到完全不透明的错误消息，表明无法解析上面的项目输出引用。
与所有 InstallShield 错误一样，谷歌搜索答案一无所获，除了许多其他人有同样的问题。所以我决定深入研究 .isproj 的纯文本，看看我能找到什么。
事实证明，.isproj 类型只是一个常规的 MSBuild 脚本，它甚至有注释行来解释可以添加到项目中的选项；可以添加的其中一项是包含 ProjectReference 节点的 ItemGroup。手动添加节点有助于解决问题。命令行构建现在可以工作了。
但是，我不满意 a) 必须手动输入这些内容，b) 无法直观地表示正在引用的项目，以及 c) 直到构建失败才发现问题。所以，我希望能够扩展 Visual Studio 来帮助我解决这个问题。这是我想做的：
1) 在解决方案资源管理器中的项目中添加一个“References”节点，该节点的作用类似于任何普通 .csproj 的 References 节点。
2) 限制当前解决方案中对其他项目的可用引用。
3) 直观地表示缺少引用的项目（例如，通过用彩色波浪线在项目名称下划线，如错误/警告），如果缺少，则可能会导致构建失败（取决于我是否要将其视为错误或警告；待定）。
为此，我下载了 MPF for Projects - Visual Studio 2013，它提供了用于创建新项目类型的 SDK。
但是，在深入挖掘之前，我需要知道是否可以扩展现有项目类型，如上所述，因为我显然没有 InstallShield 源代码。此外，任何有关这样做的起点的链接或指导将不胜感激。
