Re: HOWTO: create redistributable COM Addins for office using .Net
- From: "Martin Böhm" <john@xxxxxxx>
- Date: Wed, 1 Jun 2005 16:09:35 +0200
Yes, indeed you're right. That's an additional point.
That's why we finally decided to save all our settings to the windows
registry or the database.
Additionally deploying the excel.exe.config file might also become a problem
if your setup has to be deployed by using net installer. From as far as I
know our biggest customer had a lot of problems during scripting, especially
since all nodes in the config file are empty and the information is stored
within the attributes.
Best Regards
Martin
Interested in mailing me? Here's my email
(please read from right to left and use COM Addin as keyword in the subject
line so your email is not considered as spam)
ed[dot]socyl[at]nitram[hyphen]mheob
"Vincent Melia" <VincentMelia@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im
Newsbeitrag news:E64BEE42-BA72-4295-9733-F7AE8D8CD1C6@xxxxxxxxxxxxxxxx
> With reference to the config. file, if I create an add-in for Excel I
> would
> create an excel.exe.config file.
>
> What if I have more than one add-in? What if I want each add-into have
> its
> am config file?
> This seems like a real limitation and there must be a better solution.
>
> Anyone know of one?
>
> "Martin Böhm" wrote:
>
>> Hi all,
>>
>> Looks like I should look into this newsgroup more frequently. I have read
>> many threads, where people have problems installing their .Net Based COM
>> Addin on other machines. Instead of answering multiple threads, I start a
>> new one.
>>
>> The two main problems are:
>>
>> 1. Addin is not loaded correctly (automatically unloaded)
>> 2. Runtime Debugging: Addin
>> 3. Storing Application Settings for the Addin
>>
>> 1) The Addin is not loaded correctly: (This problem kept me busy for
>> WEEKS, thus I thought it might be interesting for you)
>>
>> The Addin works fine on a the development machine, but if the setup is
>> installed on a non-development machine, the addin does not start.
>> Before the addin is started for the first time the corresponding load
>> behaviour registry key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\MS
>> Project\Addins\MyAddin.Connect] is set to 3. After the office program has
>> been started for the first time, there is a short break while loading the
>> application and the registry key is automatically set to 2.
>>
>> The problem has to do with the sequence the classes that are contained
>> within the .Net dll are registered for COM Interop.
>>
>> I was able to reproduce this behaviour the following way:
>> - Try to use internal classes or functions instead of public ones
>> whereever possible.
>> - If public functions have to be used, make sure that they do not use
>> ..Net classes as parameters (Your Addin is like a COM AddIn to the office
>> application, therefore you can't use parameters that are not defined
>> inside
>> COM)
>>
>> I know this might sound weird to you but make a small test. Create a new
>> Addin with a public function that uses a custom class as parameter, and
>> try
>> to install it on a different machine, then set this function to internal
>> and
>> try again.
>>
>>
>> 2. Runtime-Debugging:
>>
>> Many people wonder why they can't debug their Addin. Instead a new
>> instance
>> of VS.Net is opened.
>>
>> To use the runtime debugger take a look at your project properties. In
>> the
>> Configuration Properties section you have the Debugging options. In the
>> Start Action Section you can set the Debug Mode. You might have to set
>> debug
>> mode to Program, apply your changes and then select the start
>> application,
>> e.g. winproj.exe. (Yes, Microsoft was unable to add an event to the debug
>> mode dropdown list which automatically enables/disables the other
>> dropdown
>> lists. But don't worry, they had this feature in VS2002 and 2003, I'm
>> sure
>> they'll keep it in other versions too ;-) )
>>
>> Set a breakpoint in your Addin and press F5 to run.
>>
>> 3. Storing Application Settings for the Addin.
>> As we have a .Net dll application settings should be saved in the .config
>> file of the calling application. If you have an addin for word the
>> configuration file would be winword.exe.config, if you write an addin for
>> excel the configuration file would be exel.exe.config. As you know, there
>> are different versions of office applications, the configuration file
>> must
>> be copied to the Office, Office10 or Office11 folders, depending on the
>> version which is installed.
>>
>> You see, if we decide to create an addin for different office
>> applications
>> supporting different versions we should think about where to save the
>> settings. I prefer to save it to the registry, no matter if it is
>> recommended or not. It's much easier for the netinstall team to update a
>> registry key on a client machine, than to exchange a complete file.
>>
>> I guess this should help many of you out there. Please give me some
>> feedback
>> if this helps you.
>>
>> Best Regards
>> Martin
>>
>> Interested in mailing me? Here's my email (please read from right to left
>> and use COM Addin as keyword in the subject line so your email is not
>> considered as spam)
>> ed[dot]socyl[at]nitram[hyphen]mheob
>>
>>
>>
.
- Follow-Ups:
- Re: HOWTO: create redistributable COM Addins for office using .Net
- From: Vincent Melia
- Re: HOWTO: create redistributable COM Addins for office using .Net
- Prev by Date: Re: Windows form on a task pane
- Next by Date: Re: The timeless, never-ending question
- Previous by thread: Re: Windows form on a task pane
- Next by thread: Re: HOWTO: create redistributable COM Addins for office using .Net
- Index(es):
Relevant Pages
|
