小编Jer*_*jer的帖子

我们的一位客户遇到了无法重现的问题.我们使用SPFile.Properties以编程方式将文档的属性复制到目标文件.但是,由于某种原因,文件的属性与列表中指定的元数据不匹配,文件存储在其中.

现在,我们可以通过复制SPFile.Item.Properties(尚未测试)来解决这个问题,但我只是想知道在什么情况下SPFile.Properties与SPFile.Item.Properties不相等.

更新:我们刚收到客户的最新消息.使用SPFile.Item.Properties始终返回最新信息.但是,我们仍然想了解原始问题.

我开发了一个简单的C#Winforms应用程序,它通过COM自动化加载MS-Word 2007文档.

这一切都非常简单直接,但是根据我需要以编程方式启用或禁用宏以及ActiveX控件的文档.

可能有一种方法可以将其存储在注册表中,但我希望逐个实例地控制这些设置,因为一次可能会运行多个并发请求.

所以我的问题是" 如何使用COM自动化配置信任中心设置 ".

我用谷歌搜索了几个小时,但我能找到的只是Application.AutomationSecurity属性,但这只接受以下值:

• MsoAutomationSecurity.msoAutomationSecurityLow
• MsoAutomationSecurity.msoAutomationSecurityForceDisable
• MsoAutomationSecurity.msoAutomationSecurityByUI

但是,Word 2007信任中心公开了以下设置:

宏设置:

• 禁用所有宏而不通知(匹配msoAutomationSecurityForceDisable)
• 禁用带通知的所有宏(我不需要这个)
• 禁用除数字签名宏之外的所有宏(无等效项)
• 启用所有宏(匹配msoAutomationSecurityLow)

替代文字http://www.visguy.com/wp-content/uploads/2007/05/v2007-security-settings.png

ActiveX控件(单独配置,我还没有找到任何方法来控制这些,请注意根据屏幕截图这些设置在所有应用程序之间共享)

• 禁用所有控件而不通知
• 在启用UFI控件之前提示我....
• 在启用具有最小限制的所有控件之前提示我
• 无限制地启用所有控件

我已经尝试了在更改这些设置时记录MS-Word宏的旧技巧,但没有记录这些步骤.

更新: 我在注册表中找到了ActiveX控件设置的以下条目.看起来ActiveX设置确实是全局的,除非有人证明我错了,否则不能为单个MS-Word实例指定.

ActiveX已禁用

[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security]"DisableAllActiveX"= dword:00000001"UFIControls"= dword:00000002

ActiveX启用安全模式

[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security]"DisableAllActiveX"= dword:00000000"UFIControls"= dword:00000002

ActiveX启用时没有安全模式

[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security]"DisableAllActiveX"= dword:00000000"UFIControls"= dword:00000001

仍然热衷于解决宏设置问题

我们的错误跟踪系统中有一个长期存在的问题,即关于可怕的" 错误:在TrackedRequests中找不到请求.我们可能在不同的线程上创建和关闭Web. "消息在SharePoint的跟踪日志中.

在我们为SharePoint市场开发Workflow软件时,我们会不时调查此问题,以确保它不是由我们的产品引起的.我个人得出结论,这是SharePoint中的问题,但也许其他人可以证明我错了.

这就是我所知道的:

1. 根据Google针对此主题返回的数百个搜索结果,此问题似乎主要与SharePoint Workflow相关,包括SharePoint Designer和基于Visual Studio的工作流.

2. 假设ULS日志记录设置为Monitorable,则重现此问题的最简单方法是创建新的SharePoint Designer工作流,将其附加到文档库,将其设置为在添加/更新时自动启动,不添加任何操作,保存工作流并将文件上载到文档库.

3. 该错误仅在SharePoint跟踪日志中可见,它似乎不会影响手头工作流的执行.

4. 我已经验证了问题出现在32位以及64位系统,Win2K3和2K8,WSS和MOSS以及SharePoint版本到2009年12月的累积更新(6524).

5. 手动启动工作流时不会发生此问题.

6. MSDN论坛上有数十篇相关帖子,Google 上有数百篇,StackOverflow上有一篇,SharePoint Overflow上没有.似乎没有答案.

有没有人知道发生了什么,导致这种情况的原因以及我们是否应该担心或在" 红色鲱鱼 " 下提出这个问题.

更新: Microsoft已确认这是一个可以安全忽略的已知问题.它不会在SP2007中修复,但在SP2010中不再是问题.