01-14-2008 03:15 PM
by Xavier on 01-07-2008 11:03 AM
.NET Publisher policy files have been used since 7.0.1 to redirect any assemblies built against the ACT! SDK to the latest and currently installed version of the ACT! SDK. This includes ACT! add-ons (plugins) as well as applications. This is used as part of SDK compatibility to make sure consuming assemblies such as third-party solutions do not need to re-deploy anything to work with the latest version of ACT!, so as long as those assemblies consume ACT! SDK assemblies.
For a number of reasons, we are entertaining the possibility of using the ACT! application configuration file instead of publisher policy files to redirect assemblies for SDK compatibility in future versions. In other words, ActSage.exe.config would contain assembly redirects for all ACT! SDK assemblies, and we would no longer install publisher policy assemblies in the Global Assembly Cache (GAC). From an add-on (plugin) perspective, nothing would change. Add-ons would be redirected to the currently installed version, and continue to work as they do today. However, for third-party applications (exe) leveraging the SDK, those would need to have configuration files deployed themselves with assembly binding redirects for each new version of ACT! to support that version. While we could make available the redirect themselves to application authors, those authors would be responsible for deployment of the configuration files alongside their applications as they choose to support newer versions of ACT!.
Because this could be disruptive to those applications, we are very interested to know if you are deploying applications (not add-ons) leveraging the SDK today. We’re also interested in your feedback in general regarding the use of the application configuration file instead of publisher policy files for SDK compatibility.
This is important for us all, so I thank you in advance for your feedback.
You can reply to this thread or send me a note privately.
01-14-2008 03:15 PM
by david on 01-09-2008 12:46 PM
We sell two aps that are not add-ons; they use the SDK externally.
Sage Migrator is used to migrate ACT! databases to Sage CRM, CRM.com and SalesLogix - we actually developed it in conjunction with Sage. It also does GoldMine to ACT!, so don't feel to grumpy about it...
Inaport is a full blown integration engine that is used for bi-directional integration with ACT!; but is also works with SalesLogix, Sage CRM, CRM.com and GoldMine. To be honest, it is early days for us with ACT!
Thinking through the issues, currently deployed ACT! installs would have publisher files already installed, so it would only be with ACT! 10.??? and up. How granular are we talking about here? Would it be config file for V10, another for V11, or would we need files for point releases? What kind of exception would be thrown for a mis-match of redirect file and installed API? If it is something sensible, then it can be caught and a reasonable error message given.
Inaport and Sage Migrator are currently built against 7.x dll's to retain the lowest common denominator. This will have to change with 10.02 and Custom Entities anyway. Will the move to App config files coincide with this release?
In summary - not sure I am fully across the issues, but it seems doable provided we do not get into a combinatorial explosion of many config files to support many different version combinations.
01-14-2008 03:16 PM
by Xavier on 01-09-2008 3:30 PM
Preferably, configuration files would need updating on major releases only, but I’m not sure that’s entirely feasible at this point. In terms of exceptions, dependent assembly exceptions happen very early on in the application lifecycle, so there’s usually not a chance to do nice error handling unless the assemblies are loaded dynamically, unfortunately.
There would only be one configuration file needed, and the only thing that would change is the target assembly version for each assembly binding redirect in the config file, which would need to match the version of ACT! installed.
The proposed change and any impact isn’t yet associated with a release at this time, but certainly this will be shared once known.
01-14-2008 03:17 PM
by david on 01-10-2008 12:14 PM
Possible I am mis-understanding something, but I think multiple config files will be needed in the install. Take the current situation; Inaport is (deliberately) built against ACT 7, but runs against 7, 8, 9, 10.
To ship, I would need to supply a config file for each version of ACT, and either have the installer detect and use the correct one, or get the customer to manually configure the correct one. If config files are needed for point releases, within 2-3 years I might have 5-10 config files...:-(
We had a small dose of this already; Sage Migrator is a .Net 1.1 app, and ACT 9 is .Net 2.0, so we ship it with a config file that does a redirect to .Net 2.0 when working with ACT 9; but customer has to manually configure. We are able to give a sensible error message, because no attempt is made to connect to ACT until UI is up and running and we need to connect.
01-14-2008 03:18 PM
by Xavier on 01-10-2008 1:59 PM
You could have the install generate the correct entries in the config file depending on the ACT! version installed, rather than have seperate config files, but I think you are correctly undestanding. And it is a bit like the .NET 1.1 -> 2.0 redirect issue.
We are looking at alternatives, such as as the machine.config file, such that we don't affect any add-ons or applications, as we do realize having to manage versioning isn't ideal for applications / authors
01-14-2008 03:18 PM
by RobEisler on 01-11-2008 9:42 AM
Our situation is quite similar to David's. Our Stonefield Query for ACT! mainly uses the OLE/DB provider for reporting, but it also uses the SDK to retrieve some information which is not available through the provider, such as activity and group membership information. We have some logic in our installer which looks up the installed version of ACT! in the registry and reacts accordingly; I guess that this would end up being more complicated if the change you describe is made.
02-07-2008 03:02 PM