adxloader poor performance

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

adxloader poor performance
 
Omri Suissa


Guest


Hi,
From some reason my topic is locked:
http://www.add-in-express.com/forum/read.php?FID=10&TID=10524

I glad to inform you that we solved this issue when adxloader has poor performance on terminal server (it took us more time that we expected but we solved it :))

The problem occurs when the loader tries to load the appdomain of the .net part of the adx addon (both in IE and Office), this can be reproduce with .net application that tries to load a new appdomain with the .net part in adx.

Why this is happening?
It related to the way to compile the AddinExpress.IE.dll (and the same for office).

I don't know what the exact symbols, flags and options you are using when compiling the AddinExpress.IE.dll but I do know that when I tested it with our build server we succeeded to compile it in a way that solved the problem (from 20 secs load to 0.5 sec load).

If this issue is important to you as it was important to us (we really invest a lot of time in it, I think we know your loading code almost as good as you know it now :)) please contact us via emails and we can try find out what exactly is wrong in the way you build your solution.

Thank your support,
Omri Suissa
DiffDoof's VP R&D
Posted 30 May, 2012 02:48:40 Top
Andrei Smolin


Add-in Express team


Posts: 18829
Joined: 2006-05-11
Hi Omri,

We are definitely interested. I've sent you an email.


Andrei Smolin
Add-in Express Team Leader
Posted 30 May, 2012 02:58:08 Top
Andrei Smolin


Add-in Express team


Posts: 18829
Joined: 2006-05-11
Hi Omri,

Do you digitally sign the resulting assembly?

gards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 30 May, 2012 03:39:40 Top
Sergey Grischenko


Add-in Express team


Posts: 7233
Joined: 2004-07-05
Hi Omri,

The fact is that we sign our assemblies with the digital signature. If the 'Check for publisher's certificate revocation' option is enabled in IE, it may produce the performance issue. Please check it on the terminal server.
Posted 30 May, 2012 04:35:58 Top
Omri Suissa


Guest


Hi Sergey,
No, it doesn't related to the signing of the assembly. it related to the build itself.


Omri
Posted 30 May, 2012 05:40:57 Top
Sergey Grischenko


Add-in Express team


Posts: 7233
Joined: 2004-07-05
Hi Omri,

We build our assemblies in VS 2005. As far as I know, you use VS 2010.
I will try to reproduce the issue on our PCs and will let you know about results as soon as possible.
Posted 30 May, 2012 08:35:02 Top
Omri Suissa


Guest


Hi,

After carefully tested the problem again we found that we made a mistake about the certificates.

My team found out that the signing of the adx addon is the problem as you said and the option of "Check for publisher's certificate revocation" off is not working.

So it is related to the certificates after all and not to the build itself.

But, here is the catch, it related to signing .net assemblies only and not C++ dlls. When we sign the loader with code signing certificate it loads fast and IE sees the addon as signed so we get both benefits.

Our conclusion is that you don?Â?Ð?ét need to sign the ADX dlls (only to use strong naming) and sign the adx loader (dlls) instead.

If you use this solution we believe that you will solve this issue completely.

If you want I can send you our testing tool with the signed and unsigned dlls in case you encounter a "bad" machine (like we did) in the future.

Omri
Posted 31 May, 2012 07:11:18 Top
Dmitry Kostochko


Add-in Express team


Posts: 2875
Joined: 2004-04-05
Hi Omri,

Thank you for the details.

My team found out that the signing of the adx addon is the problem as you said and the option of "Check for publisher's certificate revocation" off is not working.


The "Check for publisher?Â?Ð?és certificate revocation" option works correctly, this was confirmed by numerous tests of our customers on different environments. May I suggest that your team carry out additional testing?

But, here is the catch, it related to signing .net assemblies only and not C++ dlls. When we sign the loader with code signing certificate it loads fast and IE sees the addon as signed so we get both benefits.


This is exactly the reason why we do not sign the loader ?Â?Ð?ã to give our customers the ability to sign it using their own certificates. And I am not sure that signing the loader really resolved the issue, I believe it was something else that got it to work, e.g. the "Check for publisher?Â?Ð?és certificate revocation" option got somehow switched off or the CRL (Certificate Revocation List) was successfully downloaded by Windows and cached.

Our conclusion is that you don?Â?Ð?ét need to sign the ADX dlls (only to use strong naming) and sign the adx loader (dlls) instead.


Signing the Add-in Express loader would result in Add-in Express being indicated as a Publisher of any and all Office add-ins and IE plug-ins our customers develop using Add-in Express products. As you understand this is absolutely unacceptable for us. That is why we have signed and will sign our assemblies but not the loader.

Anyway, we will further research the issue with delayed loading of .NET Framework 2.0 based assemblies, we will do our best to find a solution.
Posted 01 Jun, 2012 06:09:37 Top
Omri Suissa


Guest


Hi,
Yes, I understand why you don't sign the loader.

Here is what we know:
1) Our add-on in installed on several thousand computers with great success.

2) From time to time the "certificate revocation" is taking a lot of time and we advise our customers to use the "Check for publisher?Â?Ð?és certificate revocation".

3) From all the computers that we installed on we found that on few Terminal Server (2003 and 2008) this option is not working as we expected (the loading time is still very high) ?Â?Ð?ã we didn't install or configure these machines so we don't know that is the differences.

4) If we remove the signing from the ADX DLL and sign only the loader everything is working fast as excepted.

We don't know exactly if this problem related to the fact that the loader is written in C++ and the ADX DLL is in .net or maybe because the loader is the first DLL that checked, or maybe the certificate checks of the loader is done by IE and the ADX DLL by .net framework, or something else?Â?Ð?? we do know that it is acceptable to sign only the loader and to avoid these kind of problems.

Therefore our recommendation is that you release signed and unsigned versions of ADX for these situations.

Omri
Posted 03 Jun, 2012 01:28:44 Top
Dmitry Kostochko


Add-in Express team


Posts: 2875
Joined: 2004-04-05
Hi Omri,

Thank you for understanding.

And here is what we know:
1. When a Microsoft .NET Framework 2.0 managed application that is Authenticode-signed itself or loads Authenticode-signed assemblies starts up, it may take more time than usually for the .NET Framework 2.0 managed application to start.
2. This happens to any .NET 2.0 assembly that is Authenticode-signed, it is not exclusive to Add-in Express assemblies.
3. The root of the problem is the mechanism used by .NET 2.0 Common Language Runtime (CLR) to verify code-signed .NET applications and assemblies.

Microsoft strongly recommends signing .NET components and libraries and we follow this recommendation. Not only we comply with the Microsoft guidelines, the vast majority of independent software vendors stick to their recommendations.

Your suggestion of delivering signed and unsigned versions of our assemblies will not resolve the problem globally. As you understand the issue will emerge again as soon as any signed assembly appears in your project. Even if you don?Â?Ð?ét use third-party components, you will have problems with COM add-in projects because Office 2003, 2007 and 2010 Primary Interop Assemblies are signed by Microsoft.

As I said earlier we are researching this issue, hopefully we will be able to use the generatePublisherEvidence configuration setting described in http://support.microsoft.com/kb/936707.

I will keep you updated.
Posted 04 Jun, 2012 07:24:53 Top