Addins no longer work with .NET 2.0 Redistributable Installed

Add-in Express™ Support Service
That's what is more important than anything else

Addins no longer work with .NET 2.0 Redistributable Installed
ADX addins developed with VS2003 won't load on machines with .NET 2.0 
Sergey Grischenko


Add-in Express team


Posts: 7234
Joined: 2004-07-05
Ted, there is such thing as application requirements. If the user installs .NET Framework 2.0, he must be aware that some software might stop working due to some special requirement for Framework 2.0. In this case the user will just have to reinstall the add-in.

This is really unacceptable on many levels.

As a rule the system administrator is in charge of installation of software. And he knows what software is installed on his PCs. I don't think it is a big problem for the end user.


Please describe the EXACT steps Add-In express recommends for installing and building an ADX-based add-in, assuming general-case user senarios (some of which I describe above). Or are you saying there isn't an acceptable solution and we will endup with nightmare CS issues (like the ones I describe in this post and the one above) if we use your product?

The installation of ADX based add-ins doesn't differ at all from installation of standard add-ins. Add-in Express .NET is a big universal add-in customized for main Office applicatons. You can find a lot of articles devoted to Add-in Deployment in MSDN. Also you can read the following article on the compatibility of .NET Frameworks:
http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetdep/html/netfxcompat.asp
As to exact steps, ADX automatically generates the setup project for a general case. The rest depends on your project type. If you have any problems with your setup project, you can always send it to me and I will help.

Posted 01 Feb, 2006 12:14:47 Top
Ted Morris




Posts: 5
Joined: 2006-02-01
Sergey,

From your responses, the bottom line appears to be that ADX is not a robust solution for COM Add-ins. And I understand that this appears to be an issue with Microsoft and the way they implement the .NET architecture and side-by-side compatibility. But that doesn't change the fact that this is not a fully robust solution. Implementing the COM add-in as a pure Win32 solution would not have any of these problems.

One of the main benefits of .NET is to get rid of "dll hell" and have applications/products that continue to run properly if a user installs a new version of .NET. Whether every single user has to reinstall our ADX add-in if they install .NET 2.0, or whether an IT admin has to reinstall our product across 10 or 100 or 1000 computers on their network (simply because they installed .NET 2.0), this is a MAJOR hinderance and disadvantage to using our product, and it creates HUGE CS headaches. I hope you can understand and support this position. If you can't, that tells me that you haven't distributed products to many thousands of users (or millions, as in the case of our product).

I hope at some point you will find a solution to this problem, since ADX looks like a very good product otherwise.

Ted.
Posted 01 Feb, 2006 12:50:45 Top
Sergey Grischenko


Add-in Express team


Posts: 7234
Joined: 2004-07-05
Ted, as you know that Office applications are unmanaged applications. They know nothing about managed COM add-ins at all. They use mscoree.dll to load add-ins. As a result the latest version of .NET framework is used (by default). Unfortunately Microsoft changed lots of type/classes in Framework v2.0 and this is the problem. If the add-in uses types that have not been changed, the add-in can work properly. Otherwise the add-in will not be loaded. One of a possible solution is to create a special C++ shim that can load two versions of the add-in depends on the current version(s) of .NET Framework and Office configuration. I will try to develop this shim and I will let you know about results.
Posted 01 Feb, 2006 13:55:16 Top
Sergey Grischenko


Add-in Express team


Posts: 7234
Joined: 2004-07-05
Hi Ted.

It seems I have a solution. I created a special C++ shim that allows to load two versions of the add-in depending on the current version(s) of .NET Framework installed. Now it is just an example and I am going to add it to the installation package of the new ADX version that will be published in a few days. In the next build I am planning to add a special wizard that will automate creating the add-in that will support both .NET Framework versions.
Posted 07 Feb, 2006 08:45:20 Top
Sergey Grischenko


Add-in Express team


Posts: 7234
Joined: 2004-07-05
Hi Esteban.

I don't know for sure if you are subscribed to our forum. I just can't reply you regarding this issue by email because my messages return as 'Host unknown'. Can you give me an alternative email address?
Posted 07 Feb, 2006 08:50:27 Top
Sergey Grischenko


Add-in Express team


Posts: 7234
Joined: 2004-07-05
Hi Ted.

I have good news. A new version of ADX will support COM add-ins that will work properly regarless whether both .NET Framework versions are installed or not. If an add-in is developed in VS 2003, it will work properly without any configuration files alongside other add-ins developed in VS2005. That means you will never have to use configuration files for Office applications.
However there are two requirements:
1. The appropiate .NET version should be installed on a PC.
2. The add-in should use the shim.
Does this solution suit you?
Posted 10 Feb, 2006 07:22:59 Top
Ted Morris




Posts: 5
Joined: 2006-02-01
Thanks for the hard work getting this completed! For this to work, does the add-in need to be developed in VS2003 (.NET 1.x), or can it be developed in VS2005 (.NET 2.0) instead?

Ted.
Posted 10 Feb, 2006 08:47:21 Top
Sergey Grischenko


Add-in Express team


Posts: 7234
Joined: 2004-07-05
Ted, you can use both versions of VS to develop add-ins. It depends on the version of .NET Framework you want to support.
Posted 10 Feb, 2006 13:50:12 Top