MyGroups未在Communicator.UIAutomation中实现 [英] MyGroups not implemented in Communicator.UIAutomation

问题描述

我正在开发一个浏览器的Silverlight应用程序，它提供了一些MS Office Communicator 2007控件。我正在使用自动化SDK 。与SDK一起安装的文档声明在IMessenger2接口中有一个MyGroups属性，它将返回用户定义的组，但是当我尝试使用它时，我得到一个 NotImplementedException 。这里是我使用的代码：

  dynamic communicator = AutomationFactory.CreateObject（Communicator.UIAutomation）; 
 communicator.AutoSignin（）; 
 foreach（dynamic g in communicator.MyGroups）
 {
 //使用组
执行操作} 
  

如果我用MyContacts替换MyGroups，我可以得到联系人列表很好。我需要做一些不同的访问属性在IMessenger2接口？我看到了一些网上的说，MyGroups已被弃用的Windows Messenger，但从文档，它似乎应该可用于MS Office Communicator。

如果我不能使用MyGroups，是否有另一种方法来获取用户创建的组？

解决方案

问题在于MyGroups属性被标记为NotScriptable，这意味着你不能以你正在做的方式调用它，即使用AutomationFactory。出于安全原因，Automation API中的一些属性和方法不是可编写脚本的 - 这是为了避免恶意页面自动化Communicator并在不知情的情况下执行某些任务。

像Silverlight中的COM互操作以与例如相同的方式处理从VBScript创建和调用API，因此您将无法访问任何非脚本化属性和方法。有关哪些属性和属性的详细信息，请参见参考方法不可脚本化。

我猜这会严重影响你的应用程序。我认为伤害你的是决定使用Silverlight OOB。有什么办法你可以使用WPF（甚至winforms）而不是Silverlight？如果您这样做，您可以直接引用API，并且拥有对所有属性/方法的完全访问权限。

否则，我不能想到太多选项。您不能捕获 OnContactAddedToGroup 事件，因为这不可脚本化。

可以可以使用.NET程序集来包装API，并通过COM公开它，然后以同样的方式实例化它 - 但是在这种情况下，Not Scriptable可能仍然被尊重，所以它不会买你任何东西。很难说没有尝试，仍然是一个相当可怕的解决方案。

编辑：我刚刚给了wrapper方法做类似于客户的概念验证），它似乎工作。这是我这样做的方式：

创建一个新的.NET类库。定义COM接口：

  [ComVisible（true）] 
 [Guid（8999F93E-52F6-4E29-BA64 -0ADC22A1FB11）] 
 public interface IComm 
 {
 string GetMyGroups（）; 
} 
  

定义一个实现该接口的类（需要引用CommunicatorAPI。 dll从SDK）：

  [ComVisible（true）] 
 [ClassInterface（ClassInterfaceType.None）] 
 [GuidAttribute（C5C5A1A8-9BFB-4CE5-B42C-4E6688F6840B）] 
 [ProgId（Test.Comm.1）] 
 public class Comm：IComm 
 {
 public string GetMyGroups（）
 {
 var comm = new CommunicatorAPI.MessengerClass（）; 
 
 var groups = comm.MyGroups as IMessengerGroups; 
 return string.Join（，，groups.OfType< IMessengerGroup>（）。Select（g => g.Name）.ToArray（））; 
} 
} 
  

建立并使用 RegAsm 。然后从OOB silverlight应用程序调用：

  dynamic communicator = AutomationFactory.CreateObject（Test.Comm.1）; 
 MessageBox.Show（communicator.GetMyGroups（））;注意，使用Lync API也可以使用相同的技术：
 
 $ 
 b $ b 
  public string GetMyGroups（）
 {
 var comm = LyncClient.GetClient 
 return string.Join（，，comm.ContactManager.Groups.Select（g => g.Name）.ToArray（））; 
} 
  
虽然这样有效，但我不能说是否是一个好的做法，因为它正在围绕一个安全限制，这可能是有一个很好的理由。我想最糟糕的情况是，如果恶意网页知道控件的ProgId，那么恶意网页可能会使用该组件。
 
 
 
编辑：你需要小心内存泄漏，例如确保在完成后释放COM对象 - 容易做到，只需要一点纪律; o）
 
I'm working on a out of browser Silverlight app that provides some MS Office Communicator 2007 controls.  I'm using the Automation SDK.  The docs that were installed with the SDK state that there's a MyGroups property in the IMessenger2 interface, which will return the groups that a user has defined, but when I try to use it, I get a NotImplementedException.  Here's the code that I'm using:
dynamic communicator = AutomationFactory.CreateObject("Communicator.UIAutomation");
communicator.AutoSignin();
foreach (dynamic g in communicator.MyGroups)
{
    //Do something with the group
}
If I replace MyGroups with MyContacts, I can get the contact list just fine.  Do I have to do something different to access properties in the IMessenger2 interface?  I've seen a few things on the web that say that MyGroups was deprecated for Windows Messenger, but from the docs, it seems like it should be available for MS Office Communicator.

If I can't use MyGroups, is there another way to get the groups that a user has created?
解决方案
The problem here is that the MyGroups property is marked as NotScriptable, meaning you can't call it in the way you are doing i.e. using the AutomationFactory. For security reasons, some properties and methods in the Automation API are not scriptable - this is to avoid malicious pages automating Communicator and carrying out certain tasks without you knowing.

It looks like the COM interop in Silverlight is treated in the same way as e.g. creating and calling the API from VBScript, so you won't be able to access any of the non-scriptable properties and methods. See the reference for details of which properties and methods are not scriptable.

I'm guessing this is going to seriously hobble your app. I think what's hurting you is the decision to go with Silverlight OOB. Is there any way you could use WPF (or even winforms) rather than Silverlight? If you did this, you could reference the API directly, and have full access to all properties/methods.

Otherwise, I can't think of too many options. You can't trap the OnContactAddedToGroup event, as this is not scriptable.

It might be possible to wrap the API with a .NET assembly, and expose it via COM, then instantiate it in the same way - but the Not Scriptable might still be respected in that case, so it won't buy you anything. Hard to say without trying it, and still a fairly horrible solution.

Edit: I've just given the wrapper method a try (needed to do something similar as a proof of concept for a customer), and it seems to work. This is the way I did it:

Create a new .NET class library. Define a COM interface:
[ComVisible(true)]
[Guid("8999F93E-52F6-4E29-BA64-0ADC22A1FB11")]
public interface IComm
{
    string GetMyGroups();
}
Define a class that implements that interface (you'll need to reference CommunicatorAPI.dll from the SDK):
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[GuidAttribute("C5C5A1A8-9BFB-4CE5-B42C-4E6688F6840B")]
[ProgId("Test.Comm.1")]
public class Comm : IComm
{
    public string GetMyGroups()
    {
        var comm = new CommunicatorAPI.MessengerClass();

        var groups = comm.MyGroups as IMessengerGroups;
        return string.Join(", ", groups.OfType<IMessengerGroup>().Select(g => g.Name).ToArray());
    }
}
Build, and register using RegAsm. Then call from the OOB silverlight app:
dynamic communicator = AutomationFactory.CreateObject("Test.Comm.1");
MessageBox.Show(communicator.GetMyGroups());
Note, the same technique also works using the Lync API:
public string GetMyGroups()
{
    var comm = LyncClient.GetClient();
    return string.Join(", ", comm.ContactManager.Groups.Select(g => g.Name).ToArray());
}
Although this works, I can't really say whether it's a good practice, as it's working around a security restriction which was presumably there for a good reason. I guess the worst that could happen is that a malicious web page could potentially use the component, if it knew the ProgId of the control.

Edit: Also, using this method you'd need to be careful about memory leaks, e.g. make sure you're releasing COM objects when you're finished with them - easy enough to do, just needs a little discipline ;o)

                        
这篇关于MyGroups未在Communicator.UIAutomation中实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！