12-14-2011 10:11 PM
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!
12-15-2011 08:23 PM
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.
12-16-2011 07:08 AM
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:
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:
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.
12-16-2011 07:11 AM
12-16-2011 07:19 AM - edited 12-16-2011 07:20 AM
Also, beware that in 7.5.4 you will end up with:
policy.7.0.Sage.SalesLogix.NetExtensions.Framework.dll 220.127.116.112 4,096 11/02/2009 07:51:00 policy.7.2.Sage.SalesLogix.NetExtensions.Framework.dll 18.104.22.1682 4,096 11/02/2009 07:51:00 policy.7.5.Sage.SalesLogix.NetExtensions.Framework.dll 22.214.171.1242 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 126.96.36.19948 4,096 07/11/2011 07:54:00 HF01 policy.7.2.Sage.SalesLogix.NetExtensions.Framework.dll 188.8.131.5248 4,096 07/11/2011 07:54:00 HF01 policy.7.5.Sage.SalesLogix.NetExtensions.Framework.dll 184.108.40.20648 4,096 07/11/2011 07:54:00 HF01
12-16-2011 07:34 AM
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.