HOWTO: create redistributable COM Addins for office using .Net

[Martin Böhm]

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

 

[Vincent Melia]

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?

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

 

[Martin Böhm]

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

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?

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

 

[Vincent Melia]

I created an MSI for my add-in and placed everything where it should go.

I logged on as admin and it works. When I log on as a regular domain user
nothing happens, no add-in, no errors. any insight?

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

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?

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

 

[Martin Böhm]

Hi,

I assume you have installed it as an admin user and regular domain users are
not authorised to install software.

Take a look at your setup project in VS.Net. Right-click on your setup
project in the solution explorer and select View -> Registry.

If the registry keys are located underneath HKEY_CURRENT_USER, the only one
who's able to start the add-in is the one who has installed it.

If so, try to install the msi package as redular domain user or try to add
the registry information manually.

Regards,
Martin

I created an MSI for my add-in and placed everything where it should go.

I logged on as admin and it works. When I log on as a regular domain user
nothing happens, no add-in, no errors. any insight?

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

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?

:

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

 

[Vincent Melia]

When I log on as a domain user, open Regedit and go to HKEY_CURRENT_USER
there is an entry for the addin. I even added the proper keys to
Local_Machine .

Neither works. Any other ideas?

Hi,

I assume you have installed it as an admin user and regular domain users are
not authorised to install software.

Take a look at your setup project in VS.Net. Right-click on your setup
project in the solution explorer and select View -> Registry.

If the registry keys are located underneath HKEY_CURRENT_USER, the only one
who's able to start the add-in is the one who has installed it.

If so, try to install the msi package as redular domain user or try to add
the registry information manually.

Regards,
Martin

I created an MSI for my add-in and placed everything where it should go.

I logged on as admin and it works. When I log on as a regular domain user
nothing happens, no add-in, no errors. any insight?

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

Newsbeitrag 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?

:

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

 

[Martin Böhm]

Sorry I have no other ideas,

try to add a tracelistener in the onConnection event of your connect class:

// Create a file for output named TestFile.txt.

string fileName = Path.GetTempPath() + "Lastrun.log";

Stream myFile = File.Create(fileName);


/* Create a new text writer using the output stream, and add it to

* the trace listeners. */

TextWriterTraceListener myTextListener = new
TextWriterTraceListener(myFile);

Trace.Listeners.Add(myTextListener);

Trace.AutoFlush=true;


Add some debug statements and take a look at the log file.

Regards,
Martin

When I log on as a domain user, open Regedit and go to HKEY_CURRENT_USER
there is an entry for the addin. I even added the proper keys to
Local_Machine .

Neither works. Any other ideas?

Hi,

I assume you have installed it as an admin user and regular domain users
are
not authorised to install software.

Take a look at your setup project in VS.Net. Right-click on your setup
project in the solution explorer and select View -> Registry.

If the registry keys are located underneath HKEY_CURRENT_USER, the only
one
who's able to start the add-in is the one who has installed it.

If so, try to install the msi package as redular domain user or try to
add
the registry information manually.

Regards,
Martin

I created an MSI for my add-in and placed everything where it should go.

I logged on as admin and it works. When I log on as a regular domain
user
nothing happens, no add-in, no errors. any insight?

:

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

Newsbeitrag 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?

:

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