Re: Topic: .NET/COM Interop in VB6 MSProject Addin
DapperDanH_at_nospam.nospam
Date: 06/29/04
- Next message: DapperDanH_at_nospam.nospam: "RE: Topic: .NET/COM Interop in VB6 MSProject Addin"
- Previous message: Anna Mallikarjunan: "OWCMDX: No such interface supported"
- In reply to: Martin Boehm: "Re: Topic: .NET/COM Interop in VB6 MSProject Addin"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 29 Jun 2004 12:23:01 -0700
Martin,
Thanks for your reply. This has been tremendous help!!!
Sincerely,
Dan
"Martin Boehm" wrote:
>
> 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: DapperDanH_at_nospam.nospam: "RE: Topic: .NET/COM Interop in VB6 MSProject Addin"
- Previous message: Anna Mallikarjunan: "OWCMDX: No such interface supported"
- In reply to: Martin Boehm: "Re: Topic: .NET/COM Interop in VB6 MSProject Addin"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
