This situation can occur if your custom "UsrG***" package has the "Compile into a separate assembly" attribute.
When converting a package to assembly package (AP), transferring a schema with code to a AP, or creating a version of a compiled process, the compilation error "The type or namespace cannot be found" occurs if the code uses types from external libraries located in other packages. To solve your problem, deselect the "Compile into a separate assembly" checkbox for your package and recompile. This should solve the problem.
This situation can occur if your custom "UsrG***" package has the "Compile into a separate assembly" attribute.
When converting a package to assembly package (AP), transferring a schema with code to a AP, or creating a version of a compiled process, the compilation error "The type or namespace cannot be found" occurs if the code uses types from external libraries located in other packages. To solve your problem, deselect the "Compile into a separate assembly" checkbox for your package and recompile. This should solve the problem.
When i publish my changes the system (7.16.3.1473) pop up this message/warning:
FacebookMessagingService.OmnichannelMessaging.cs | 49 |
This async method lacks 'await' operators and will run synchronously. Consider
using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)'
to do CPU-bound work on a background thread.
This warning message appears because there is no await operator in the RegisterFacebookMessenger async function of the FacebookMessagingService schema (the await operator is actually presented in this function but is commented and as a result, the compilator returns a warning). Please ignore it since it doesn't impact the system functionality at all. We have already created the request for our R&D team to review the logic of this schema and apply changes to it to remove the warning message in further releases.
Very frequently we find that the Generate, compile, publish or Update operations from the Configuration manager take a long time to run ( > 30 mins). This happens across developers across projects.
Sometimes it keeps running endlessly and we need to force abort.
1. Are there any specific reasons why this might happen? Our hardware configurations are in line with what is recommended by Creatio for developer machines. So, I doubt if it is hardware related.
2. How long is Generate, publish, compile or update generally expected to take?
2. Could this be because of too many objects/schemas inside one package? If Yes, What is the recommended scale/volume of work that can go inside one package.
Compilation and source code generation depends on several parameters. 1st most significant parameter is connected to hardware. To ensure your hardware can provide enough resources for those action monitor server performance during compilation or source code generation.
2nd parameter is amount of code that should be compiled/generated. OOB instance without customisations can be fully compiled in 5-10 minutes. More code you have more time it will take for system to compile.
Most important recommendation here is not to compile all - you should understand when your system needs to be compiled and what should be compiled. In general you can simply compile only modified items to reduce compilation time and generate/compile all only before updates/package installation.
To clarify, We only compile modified items and not compile all items. But still it takes a significant time. Your point regarding hardware does help. Thank you Angela..
Regarding my 3rd question,
Is there a maximum number of objects or schemas that is recommended to be in a package? Beyond that number, Would you suggest creating a new package? (This is presuming that generation and compilation happens only on the selected package?)
There is no maximum number of objects in each package. Amount of objects in package should only depend on your development process so that you could always tell which package contains certain functionality.
It was recommended to us to have all the functionality in a single package, and not split into different packages. Would you have the same recommendation? Any reasons why?
You can use several packages in case you have several different customisations that are not connected to each other and can be installed separately without each other. If all your changes are connected it is better to use 1 package.
