.Net Extension Issue

[yshld]

Hi,

I have developed a Form in Visual Studio by using SalesLogix .Net Extension. After I deploy it through .Net Extension manager, I can see the form on my PC. However, if I run SalesLogix on other PC to open the form, it says cannot find the Form.

Is there anything I need to configure specially? It seems on the other PC it doesn't have the form dll. I suppose the client should download the dll from the database after I deployed it.

Could anyone give any suggestion?

Thanks a lot!

[yshld]

I have figured out that, this is due to the version different.

The .Net form I used to develop is for SalesLogix Version 7.5.4, but the other PC is running SalesLogix version 7.4.2. After I change the version to be the same, it works.

A question here, is it possible to make the .Net extension to work for mutiple SalesLogix versions? It is really painful if it can only work for a version at once.

[bthompson]

We had a similar problem, but a different resolution.  For reference, we are on 7.5.3 (LAN). 

We developed a .NET form that worked on my machine, as well as another developer's machine.  But when we released the code to test and tried to have another user test, it couldn't find the custom classes.  The users were using the same version of the client - same version, same service packs, etc.

Upon further inspection, we found that the client machine was missing the following file:

• policy.7.5.Sage.SalesLogix.NetExtensions.Framework.dll

Adding that file to the client machine did not fix the problem, however.  As we looked into the issue more, we found that the following .DLLs were older versions:

• policy.7.0.Sage.SalesLogix.NetExtensions.Framework.dll
• policy.7.2.Sage.SalesLogix.NetExtensions.Framework.dll
• Sage.SalesLogix.NetExtensions.Core.dll
• Sage.SalesLogix.NetExtensions.Framework.dll

Upon replacing the client's DLLs with the newer versions, everything worked as expected.  I know that the issue of the missing policy.7.5 file is a known issue corrected by moving to 7.5.4, however I am at a loss as to why the client had other DLLs that were old.  Perhaps moving to 7.5.4 fixes that as well.

We also know that any machine which had the admin tools installed on it was properly updated to the correct DLL versions, however how could any 7.5.3 client ever have run a .NET extension?  We are left scratching our head as to what is going on, and would love to have any info from anyone with experience with this issue. 

Regardless, our fix is to push the 5 newer DLLs to the client machines and re-run the .NET extention registration .bat file on the client once again.

[MikeSpragg]

The issue could be down to the installation. During a custom installation there is an option to switch off the .Net extensions. During an upgrade it probably got confused and partially updated those. Also, if you install Admin - you get those as well as part of the install - whereas a normal client doesn't.

[MikeSpragg]

Also, beware that in 7.5.4 you will end up with:

policy.7.0.Sage.SalesLogix.NetExtensions.Framework.dll 7.5.1.1742 4,096 11/02/2009 07:51:00 policy.7.2.Sage.SalesLogix.NetExtensions.Framework.dll 7.5.1.1742 4,096 11/02/2009 07:51:00 policy.7.5.Sage.SalesLogix.NetExtensions.Framework.dll 7.5.1.1742 4,096 11/02/2009 07:51:00

Which, as you can see are incorrect. Hot-Fix 01 fixes that. If you do not apply HF01 you will have to re-compile against the new version prior to rolling out to upgraded clients. After you apply HF01 you will get these.

policy.7.0.Sage.SalesLogix.NetExtensions.Framework.dll 7.5.4.7048 4,096 07/11/2011 07:54:00 HF01 policy.7.2.Sage.SalesLogix.NetExtensions.Framework.dll 7.5.4.7048 4,096 07/11/2011 07:54:00 HF01 policy.7.5.Sage.SalesLogix.NetExtensions.Framework.dll 7.5.4.7048 4,096 07/11/2011 07:54:00 HF01

 Regards Mike

[bthompson]

Thanks for the quick reply, Mike. 

We are still on 7.5.3.  On my developer machine I have the DLLs dated 2/11/2009, which work.  They seem to get installed with the admin tools.  The clients which don't have the admin tools have DLLs dated in 9/13/2008, which don't work.  On the few machines we tested on, copying the newer 2009 DLLs resolve the issue.

We installed the clients on the user's machines as admin, and we then apply the most recent service pack.