Re: Topic: .NET/COM Interop in VB6 MSProject Addin

From: Martin Boehm (nospam_at_mail.com)
Date: 06/28/04

  • Next message: Joakim Olesen: "Re: What COM-object is my Interop using?" 
    Date: Mon, 28 Jun 2004 09:42:41 +0200

    Hi Dan,

    Seems like you have the same problem I had when I wrote my MS Project Addin
    (completely c#).

    Let's see what I can do for you....

    1) The setup worked only on machines where VS.Net was istalled and where the
    code has been compiled before. It was a little bit frustrating, but in some
    news entry I found the solution:
        Try to declare your classes and methods as internal or private. Use
    public classes and methods only if necessary.

    This one's very important:
        Don't use your custom .Net classes in public methods!!!! (Sounds weird,
    but I have tested it, the problem is the sequence methods and objects are
    registered for COM interop)

    2) Since we have a pure c# Addin we decided to strongly name our addin and
    add it to the GAC. So it doesn't matter where the dll is. It can be in any
    directory specified by the user during the setup.

    3) Debugging .Net Addins:
    you can debug your dll quite easily: Click on the project in the project
    explorer and select properties. Select Debug from configuration settings
    and as start options select start program and an application which you would
    like to start. Then if you're in debug mode you should be able to debug your
    project ;-)

    4) Storing application settings:
    Application settings for dlls are always stored in the config file of the
    calling application. In this case it's winproj.exe.config. But I recommend
    that you store your settings somewhere else, e.g. registry. It's much easier
    to maintain, especially because there might be problems when distributing it
    to the end users. In this case the whole config file would have to be
    exchanged.

    HTH.

    Best Regards
    Martin
    Martin DOT Boehm AT OPUS HYPHEN GmbH DOT Net

    <DapperDanH@nospam.nospam> schrieb im Newsbeitrag
    news:0B757729-545D-4ACC-8357-35FEF50A1914@microsoft.com...
    > Topic: .NET/COM Interop in VB6 MSProject Addin
    >
    > I have an application that runs as an add-in to MS Project.
    > The add-in is written in VB 6.0. I am expanding the add-in
    > to include new features that were written in C#. The C# code
    > base consists of several individual projects/dlls, that are
    > also used by a separate stand-alone .NET application. In
    > order to make the .NET functionality easy to use from VB, I
    > wrote a simple wrapper class that exposes a single method
    > and several events for use in COM. In all there are about
    > seven supproting .NET dlls that are directly or indirectly
    > referenced by this wrapper I've created.
    >
    > I am looking for some sound advice regarding the best way
    > to structure and deploy this kind of solution. I have read
    > everything that I could find in the VS.NET 2003 help files,
    > MSDN-online, and a bunch of Google search hits. While I have
    > found a solution that gets the job done, I don't feel very
    > confident that I am doing it the 'right' or 'best' way.
    >
    > Some of the ideas I have encountered and/or tried are:
    > 1 Register the .NET assemblies using the 'regasm -codebase'.
    > Works great on my local machine, but didn't work when I
    > tried to deploy on several test machines.
    >
    > 2 Install the .NET assemblies in the GAC.
    > Works great, even when deployed on test machines, but
    > all the 'official' Microsoft references seemed to
    > discourage the use of the GAC, except when its use is
    > absolutely required. (The MS help pages did not specify
    > what they meant by 'absolutely required', but the did
    > specifically mention COM interop did not require that
    > the .NET assemblies be installed in the GAC.
    >
    > 3 Just install the .NET dlls in the application directory.
    > This works fine, as long as I can guarantee that the
    > 'current directory' is known when I install the dlls.
    > Using this approach, you can't even debug a VB app
    > that references .NET assemblies. You have to build an
    > executable and then explicitly place it in the same
    > directory as the .NET dlls it references.
    >
    > An additional problem is that I don't know what current
    > directory is used by MS Project when it loads/runs add-
    > ins. I don't even know if it's guaranteed to be the
    > same directory, or if it might change, depending on
    > variables outside my control.
    >
    > Attached is a simple application that roughly exhibits
    > the situation I've got. Rather than using a VB add-in
    > project, I just made a stand-alone VB 6.0 executable
    > that references one of my .NET dlls. I generated a tlb
    > using regasm.exe, so that I could reference it in my VB
    > project. To test that it will run fine, regardless of
    > the current working directory, I just copy the VB exe
    > to a different location and test that it runs the same.
    > Although the events that I fire in this sample are some-
    > what contrived, use of events is required in my real-
    > world application and that is why they are in the sample.
    >
    > To set up the attached sample, please extract the
    > archive to a folder. Everything is pre-built, so there
    > should be no need to rebuild it. However, if you wish
    > to do so, simply load 'VBCOMInterop.sln' in VS.NET
    > and 'IntCalcWrapperVBClient.vbp' in VB 6.0 and build
    > the projects. (You may need to run 'regasm -tlb' on the
    > 'IntCalcWrapper.dll' before you make the VB exe, so that
    > you can set up the project reference.)
    >
    > At this point, the VB app should run correctly when run
    > from a pre-built exe that lives in the same directory
    > as the .NET dlls.
    >
    > I would appreciate your thoughts as
    > to the most appropriate way to make it run properly even
    > if the executable doesn't reside in the same location as
    > the .NET dlls. (Such as if the VB app were really an
    > office add-in) The 'calcsetup.bat' file in the archive
    > contains the steps I took to get it to work.
    > (I copy the binaries to the 'VBCOMInterop/deploy' folder
    > in a post-build event. So all that you need to do to
    > execute my deployment solution is run 'calcsetup.bat',
    > which is also in the 'VBCOMInterop/deploy' directory.)
    >
    > Thank you for you help.
    >
    > -Dan
    >
    >

  • Next message: Joakim Olesen: "Re: What COM-object is my Interop using?"

    Relevant Pages

    • Topic: .NET/COM Interop in VB6 MSProject Addin
      ... I have an application that runs as an add-in to MS Project. ... Just install the .NET dlls in the application directory. ... that references .NET assemblies. ... execute my deployment solution is run 'calcsetup.bat', ...
      (microsoft.public.dotnet.framework.interop)
    • Re: Event Handler Problem
      ... - The *exact* wording of any and all error messages ... What line the code breaks on ... Hi, I tried to install the Addin again, this time on XP Pro SP2, PPT ... I looked at the VBE References and one of the Ref is: "Missing: ...
      (microsoft.public.powerpoint)
    • Re: sharing an add-in function for multiple users
      ... Open your AddIn and the workbook that needs to reference it. ... will just be called VBAProject in the References list. ...
      (microsoft.public.excel.programming)
    • Re: Problem with add-in written with C# in Outlook
      ... the references to your OfficePIA's points to your application folder. ... Also in CommandBar Action you load another AddIN anmed: ... > development computer it works just fine. ...
      (microsoft.public.office.developer.com.add_ins)
    • Re: Problem with references in Office Xp Developer designed Addin
      ... > I have been developing an Outlook Addin using the MOD ... > addin designer. ... > I figured I could change the references using code, ...
      (microsoft.public.outlook.program_addins)
    • Quantcast