Tip: After changing an extension, sometimes OML still reference the old one

Tip: After changing an extension, sometimes OML still reference the old one


Sometimes, considerable changes of an existent extension (like adding/removing actions or entities/structures or adding/removing assembly dependencies) could cause the existent consumer's OMLs to break compilation by generating internal errors. Even after refreshing an eSpace OML references to this extension the error persists.


The problem could arise when having several eSpaces that consume this extension, and have producer-consumer relationships between them as well. During compilation, deprecated versions of the DLL dependencies are injected into the current eSpace, crushing the new versions. For instance, assume an eSpace A, consumer of eSpace B and of the extension. If eSpace B also consumes the extension, when compiling the eSpace A, both DLL dependencies from the extension and the eSpace B will be injected into the current compilation process. However, eSpace B also has DLL dependencies of the extension, that will also be injected in the consumers, hence eSpace A. If eSpace B doesn't have it's references fully refreshed, the old extension DLL version could crush the new version, causing a compilation error on eSpace A.


In order to avoid this type of problems, all producers should had it's references refreshed and then published. However, when cyclic references exist, a proper order to republish the afected eSpaces could be difficult to achieve. The solution goes by eliminating all content of the "share" directory, as well as the "build" directory (in 3.1 releases), in the Hub Server installation folder. This will imply a republish of ALL the eSpaces.


Miguel João