问题标签 [mpf]

我正在尝试按照此处的步骤操作：https ://msdn.microsoft.com/en-us/library/cc512961.aspx为我想在 Visual Studio 中添加支持的自定义 DSL 创建一个新项目系统（最终这将包括很多功能，但现在我只是想让一些非常基本的工作）。

我可以让他们的示例正常工作，但是我在尝试进行应该非常简单的修改时遇到了麻烦：将“AssemblyInfo.cs”文件放入“Properties”文件夹中。

我的模板如下所示：

• 模板
  • 装配信息.cs
  • 程序.cs
  • 模板.myproj
  • 模板.vstemplate

我希望我创建的项目具有以下结构：

• 模板
  • 特性
    • 装配信息.cs
  • 程序.cs
  • 模板.myproj
  • 模板.vstemplate

所以我修改了我的 .myproj 文件以读取：

和我的 .vstemplate 文件读取：

这很简单：我刚刚在两个地方添加了“属性”。

但是，在创建一个新项目时，我的实验性 VS 实例抱怨：

不用说，我编写的任何代码都没有包含任何类型的枚举......我尝试单步执行“MPFProj”代码，但错误似乎发生在与正在执行的代码无关的随机位置虽然（大概错误发生在不同的线程上？）。

奇怪的是，似乎我可以在没有文件夹的情况下创建一个新项目，然后手动创建（如在 IDE 中）一个文件夹，然后我可以添加一个新文件（使用“新项目”模板）到那个文件夹就好了。

这是 MPFProj 中的错误吗？我是否需要覆盖 MPFProj 类型中 100,000 个未记录的虚拟方法之一来处理这个问题？vstemplate文件不正确吗？

另外：VS 2015 的 Visual Studio 可扩展性有什么好的资源吗？或者如何实现这些东西的最佳实践？还是有意义的文档？我看过一些示例（例如 IronPython VS 插件），它们并不是特别有启发性，特别是对于解决像这样的微妙问题（并且没有良好的文档，就不可能说出不同示例之间存在差异的原因...... ）。

我是扩展编写 VS 扩展的新手，并查找有关该主题的信息，例如解开 3 个纱线球。我在 MSDN 网站上读了很多，也做了很多失败的谷歌搜索。

我的目标是编写一个 Visual Studio 扩展（使用 MEF 和 MPF）来改进对由第 3 方创建的语言的支持。第 3 方已经有一个 VS 扩展，它支持调试以及最小的 Intellisense，并提供着色。我不想失去他们的调试支持，但我确实想改善体验的其他方面。

据我了解，给定语言（内容类型）只能由一个 LanguageService 和/或一组通过 MEF（着色、智能感知等）的编辑器服务支持。这个对吗？是否可以替换他们现有的 Intellisense 并添加其他功能？

所以我不断收到此错误消息：

从我调用此 SQL 语句的函数中：

不确定我的 SQL 是否关闭，因为我不是 100%，但我的想法是使用此查询更新我的数据库的内容。即使它是一个 UPDATE 查询，它告诉我它不是。

我已经尝试解决这个问题两天了，我想我现在只是迷失在树林里。

C＃：

任何建设性的帮助将不胜感激！

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 源代码。此外，任何有关这样做的起点的链接或指导将不胜感激。

我需要使用 mpdf 在多个页面上打印大表格内容。

动作代码

这是加载在 pdf 中的视图代码

表格内容适合一页，但我需要在多个页面上。

我测试了链接中提到的解决方案，但它不起作用。

https://mpdf.github.io/tables/tables.html

标题基本概括了所有内容。我正在编写一个 Visual Studio 扩展，在其中创建自定义命令。在此命令的回调中，我需要在我的逻辑中的某个时刻调用“解决方案级别构建命令”。我在 OleMenuCommandService 类中发现了一个GlobalInvoke(CommandID commandID)方法。CommandID 接受两个参数“ CommandID(Guid menuGroup, int commandID) ”。我找不到构建菜单组的菜单组指南。首先，我在上述方法中是否正确？如果不是，请指导我采取正确的方法。如果是，我如何找到调用 Build 命令所需的 Guid 和 ID？提前致谢。

我正在关注本教程，了解如何创建新的 Visual Studio 项目类型。在那里，它说“导入托管包框架的源代码文件”。谷歌把我带到了这个链接，它有一个 MPF 2013 包的链接。在第一个链接中，他们说要查找ProjectBase.files第二个链接下载中不存在的文件。

问题：

1. Visual Studio 2017 的正确 MPF 下载在哪里。
2. 将来当我们转向 Visual Studio 2019 时，我是否需要为 2019 年下载新的 MPF？

我们使用带有 UserAuthenticationSecurityCheck 的 IBM MFP 8.0。我们将 createUser 方法实现为指令：

但是，在我们使用大量 userId 登录 logout 的过程中，我发现多个 userId 被粘在设备上： 请在此处查看屏幕截图

问题是当我们用通知注册设备并推送到 userId 时，它会放错一个。

有人有这种情况的经验，请帮忙？谢谢

我正在尝试为成员生成标签。它带有两个东西地址和名称。我正在使用 mpdf 生成 pdf。我不知道为什么 mpdf 没有为二十秒的数据生成 pdf。

所以，我试图通过替换第 21 个数据上的相同数据来检查它。结果是一样的。我尝试如下创建我面临的问题。

将 for 循环增量编号从 21 更改为 22，仅此而已......！Mpdf 停止工作。为什么只有第 21 个数据会生成 pdf ？我不知道。

我有超过两万条记录列表，我需要以这种格式打印。那么，mpdf 是否可以工作，或者我是否需要寻找任何其他替代方案。

When you add a template custom command in a VSIX project, the scaffolding code that Visual Studio generates includes the following general structure:

Note that the framework-provided MenuCommand class takes a standard synchronous event-handling delegate with the signature void Execute(object sender, EventArgs e). Also, judging by the presence of ThreadHelper.ThrowIfNotOnUIThread(), it seems pretty clear that the body of the Execute method will indeed be running on the UI thread, which means it would be a bad idea to have any blocking synchronous operations running in the body of my custom command. Or do anything very long running in the body of that Execute() handler.

So I'd like to use async/await to decouple any long-running operations in my custom command implementation from the UI thread, but I'm not sure how to correctly fit that into the VSIX MPF framework scaffolding.

If I change the signature of the Execute method to async void Execute(...), VS tells me that there's a problem with the ThreadHelper.ThrowIfNotOnUIThread() call:

I'm not sure how to "switch to the thread required instead". Is that what the await ThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync(package.DisposalToken) code in the InitializeAsync method is doing? Should I just copy that?

What about exception handling? If I allow the synchronous void Execute() handler to throw an exception, VS will catch it and show a generic error messagebox. But if I change it to async void Execute() then uncaught exceptions won't be raised on the thread which invoked the Execute, and may cause a more serious problem elsewhere. What's the correct thing to do here? Synchronously accessing Task.Result to rethrow exceptions in the correct context seems like a canonical example of the well-known deadlock. Should I just catch all exceptions in my implementation and display my own generic message boxes for anything which can't be handled more gracefully?

EDIT to ask more specific question

Here's a fake synchronous custom command implementation:

When the custom command button is clicked, VS has some basic error handling which shows a simple message box:

Clicking Ok dismisses the message box and VS continues working, undisturbed by the "buggy" custom command.

Now let's say I change the custom command's Execute event handler to a naïve async implementation:

Now, when I click the command button, Visual Studio terminates, due to the unhandled exception.

My question is: What is the best practice way to handle exceptions arising from an async VSIX Custom Command implementation, which leads to VS treating unhandled exceptions in async code the same way it treats unhandled exceptions in synchronous code, without risking a deadlock of the main thread?