Need to create proxy objects inside the addin

Hello,

I want to have a callback function implemented by an addin. The function should generate an array of elements which are returned and are used by the host application.

Let's assume a simple class A

public class A
{
  public String m_B;
  public String m_C;

  public A(String B, String C)
  {
    m_B = B;
    m_C = C;
  }
}

The signature of the callback function should be something like

public A[] MyCallbackFunction(String Param1, String Param2)

For easy programming I define the method

virtual public A[] MyCallbackFunction(String Param1, String Param2)
{ return null; }

in the host class (isAddInEntryPoint = true). I generate the proxy for the object model and a proxy class for A is generated.

The idea is to overwrite that method in the addin like

public override MyCallbackFunction(String Param1, String Param2)
{
   return new A[] { new A(Param1, "0815"), new A(Param2, "42") };
}

The problem is that the proxy class for A has only one constructor
       [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
        [global::System.ComponentModel.BrowsableAttribute(false)]
        public A(global::System.AddIn.Contract.IContract contract, global::Microsoft.VisualStudio.Tools.Applications.TypeInfrastructureManager typeInfrastructureManager) {
            this.remoteObject = null;

                if (contract == null)
                    throw new global::System.ArgumentNullException("contract");
                if (typeInfrastructureManager == null)
                    throw new global::System.ArgumentNullException("typeInfrastructureManager");

                global::System.AddIn.Contract.Automation.IRemoteObjectContract remoteObjectContract =
                    (global::System.AddIn.Contract.Automation.IRemoteObjectContract)contract.QueryContract(typeof(global::System.AddIn.Contract.Automation.IRemoteObjectContract).AssemblyQualifiedName);

                remoteType = null;
                this.RemoteObject = new global::Microsoft.VisualStudio.Tools.Applications.RemoteObject(remoteObjectContract, typeInfrastructureManager);

                this.RemoteType = this.RemoteObject.GetType();

        }      


So it looks like I always have to create object instances at host context and are only able to pass them from the host to the addin and not vice versa?

>>I always have to create object instances at host ...

Yes, that is correct.  We will send along your request -- support 'new' operator to create object instances in the add-in.

That said, the proxy layer should be able to pass object instances either direction.  Have you found otherwise?

Hi Gary,

thanks for your answer and for forwarding the request. Especially for callback methods a 'new' functionality will be helpfull.

You are right, the proxy layer is able to pass object instances in both directions, my remark was targetetd at the fact that I always have to create the object instance at the host context and to pass it into the addin before I can use it inside the addin.

So I have to provide the object instance in the method arguments like

  public function void myCallback(MyObject myInstance)

 or I have to provide the addin with a factory method for creation of object instances at the host context like

  public function MyObject CreateMyObject()

right?

That's correct.

Right...here's an example

Thanks Gary & Melody,

I took the Factory method approach it's working fine for the moment.

@Melody:

I use VSTA v1. Are there benefits to change to VSTA CTP v2? I'm still using the .Net Framework 2.0 with Visual Studio 2005 and I expect some effort in switching to .Net 3.5, Studio 2008 and VSTA v2. Because of the test state of this components I decided to wait until the things are "settled" and there are clear advantages to migrate to the new plattform.

Thorsten:

If your VSTA 1.0 integration is working fine, and you are ready to deploy VSTA 1.0, we would suggest you do so.  Please contact me directly to get your license in place (dschneid@summsoft.com).

Doing so will allow you to switch at your convenience, while allowing your customers to begin utilizing VSTA. 

Best,

David Schneid
General Manager 

Thorsten,
   I'm glad to hear the factory method is meeting your needs.  If you have any other questions please let us know.
Thanks,
   -Melody

Hi David,

thanks for your aid, but we are not ready to deploy VSTA in the moment, regardless of version. We are considering to replace our VBS automation by VSTA in one of our next releases, but I'm still in the process of evaluating if and how all aspects of our fairly complex object model can be made available to a VSTA addin. Our next big release ist month away, so I'm not in a hurry yet ;-)

I think the time frame will allow to switch to VSTA 2.0 (and .Net framework 3.5) if it will reach release status in the next months, migration is no big effort and there are benefits which support a migration.

Thorsten:

Thanks for your feedback regarding your plans.  As you progress, please let me know when you are ready to move forward with getting the VSTA license in place.

Best,

David