If there's a problem in a module and I want to push it out to all the consumers, I don't need to wait 15+ minutes to finish all of this...
All I need OS to do is copy the DLL to all the consumers. I don't need all the consumers to be recompiled that takes too long.
And... what happens when the signature of methods and classes in those DLLs changes?
That's why we re-compile.
J.Ja
OutSystems will know beforehand if a method signature changes because we've added mandatory parameters or removed a server action, etc. In that case, a warning would be nice. But I'd still like the capability for when it hasn't changed.
As it stands, we have a team of devs working on a project. One dev makes a change that affects 10 other dependent modules. If we republish all consumers, it takes 15 minutes or more and during that time, 1-Click publish fails for ALL the devs because it's being locked by the re-publish, so our team is disabled for that amount of time.
If we had a Push DLLs to consumers function, we could simply recompile the producer module then push it out to consumers without recompiling and without downtime for the whole team. If there are no signature changes the entire process is transparent to the consumers and we don't lose productivity.
When publishing a CS module, if it is used by many modules, Service Studio would ask if the user wishes to automatically refresh and republish all modules that use the CS module that was just published.
I lose so much time with updating a cs module, then going one by one refreshing modules that use that cs.
Why not have the same strategy for all module.
There's many ideas about making the refresh of dependencies easier and quicker, but I also see a quick win in just forcing a publish.
When making changes in a Core Widgets module that is consumed by a front-end module, you constantly need to publish both. It would be convenient if Service Studio could recognize that the Core Widgets module is consumed and does this publication itself.
My workplace discourages the use of "Publish" from the Service Center because of (as far as I understand) possible issues with eSpaces with circular dependencies, etc.
When a low-level eSpace is updated, It would be handy to republish/refresh all affected eSpaces in the current application form within Service Studio rather than manually opening and republishing them.