Gang,

A client is attempting to install one of my class library EPDM add-ins and receives the error "archive server could not open windows registry" while adding the addin. This is usually resolved by setting the .Net framework in the dev environment from 4.0 to 2.0. Not this time. Not even close.

• Development machine Win7 x64 VB.Net 2010 EPDM 2013 SP5 .Net framework 4 Client profile
• Target server Windows server 2008 R2 EPDM 2013 SP5 .Net 4.5.1 framework

These are the troubleshooting steps taken to date:

1. No success: Changed .Net framework in VB from 4.0 to 2.0, 3.0, 3.5 without resolution but did notice something weird while at 3.5, the addin would load but would not run.
2. No success: Make COM assembly visible, set the interop for copy local true, embed interop types false...etc. build for any cpu
3. No success: Generated my own interop targeting .Net 2.0 using tlbimp recommended here
4. No success: Removed all unused references from the solution
5. No success: Copied out all code from the solution and created a new solution & built
6. Success: Created a stand alone apploader that makes calls into the DLL add-in without loading the addin in the admin tool

NOTE:

1. The addin loads from the stand alone app when all the public functions are called so instantiating a new object of my class library is working on the system.
2. Loaded the same addin on 2 other client servers, one in the UK running 2013 SP5 and one in Portland running 2013 SP5 with success loading and running.
3. While on a webinar with them recently I noticed their .Net framework is sitting on 4.5.1 on their servers and client machines...which has me VERY curious.

On the servers mentioned in #2, these are both running the .Net 4 framework client profile and so far this seems to be the tricky point. Every EPDM server running .Net 4 accepts the add-in and will run it in its current state.

The head scratcher: when first installing this addin back in November, the addin in an earlier generation would load and loading that version of the add-in still loads today. The code I've added since the November generation is an array, calls to read an XML file and a CSV file. The rest of the code is basically just EPDM interface stuff.

As a result, spent a few hours on webinar with a seasoned consulting programmer to discuss interops and settings in the program that could cause the error whose recommendation was to build the stand alone apploader to ensure the server could indeed instantiate the class library and it does. His claim is that the DLL is sound if we are able to do that and it is more than likely a .Net issue.

Looking for areas to investigate.

Tim CEPA

http://www.equivaq.com