06-19-2008 03:16 PM
Act.Shared.Config redirect information is missing from MachineConfigUpdater,
thus causing at least one of our programs to no longer work with 10.2.
Can we make sure this is addressed for 10.3?
06-19-2008 04:35 PM
I have also had ACT! 10.2 installs were the Machine.Config file was updated but the old policies files were still installed in the GAC.
Needles to say ACT! would not load plugins until this was cleaned up. Can that also be fixed in 10.3?
Also can the Activity object on the "Edit Activity" window be made public rather then Friend?
-- jim durkin
06-24-2008 01:41 PM - edited 06-25-2008 12:38 PM
I will add this as a feature request but the reason this might have been left out would most likely be cause of the fact that Act.Shared.Config not a supported assemly.
Once again the assemblies we promise to maintain are:
06-25-2008 08:04 AM - edited 06-25-2008 08:05 AM
I think the "we offically support these assemblies" is a bit outdated. For one, the original supported assemblies were placed into the GAC and were all updated with Policy files. We've had AutoAdmin using the DLL in question for the past several years, NEVER with a problem until now. So don't break what's working. In addition, if you look at the Machine.Config file, you'll see almost every ACT.* assembly in there. Certainly more than the short list you've given us. So if you don't officially support them, why did you put them in there in the first place?
My request, if you update a file, then you need to update the policy/config information for it. If you don't update the file, then there's nothing to do. Either way, our apps will continue to function as designed using the originally bound assemblies.
06-25-2008 05:15 PM
The SDK supported assembly list is still very much up to date. It's important to note that using unsupported assemblies may change, and we don't take measures to make sure these are backwards compatible. There are lots of ACT! assemblies in the GAC that are not SDK supported, and/or version redirects for some. These are often internally used assemblies and/or dependencies. Their presence in the GAC, and/or machine config entries in an ACT! version, does not imply any SDK compatibility.
We do run compatibility tests in all of the SDK supported assemblies such that we can ensure third-party products continue to function. If you choose to reference an unsupported assembly, and it doesn't change, that doesn't imply SDK support or that it will not change in the future.
That being said, we do strive to do what we can to support all the great products out there. We'll look into this to see why there was a change and any alternate suggestions we can provide you.
07-03-2008 07:51 AM
I don't understand this: if this file is missing no 3rd party developer can set preferences! Why was this ability taken away (without letting us know)? Why was it decided that this assembly would be unsupported? Why are other assemblies in this file that are unsupported still in the file?
Could this just have been an oversight? It looks like someone had to put the assemblies in this file one by one and might have overlooked this?
Can we put it back in? Can you give us an alternate method of getting/setting preferences? I cannot think that this is going to have any product implications, so can someone do the right thing and put this back?
07-03-2008 11:53 AM
This was never a supported assembly, so it wasn't 'taken away', certainly not purposefully. Redirects for unsupported assemblies are usually there for ACT! (or other Sage) product compatibility, and not meant for SDK long term compatibility.
In any case, this is fixed in 10.0.3. We will look to and see what we can do long term here though - whether that means graduating this assembly to an SDK supported assembly, or providing needed functionality in a supported assembly.
07-08-2008 06:24 AM
It appears that the file has been restored in v 10.03 and in v11. Thanks for taking care of this.
The larger question is how should we proceed in the future if we need to read/write user preferences?