One way is to use the Import option in your package: 

Other options, add to Files\bin in an assembly package (and add reference to csproj file), see https://academy.creatio.com/docs/8.x/dev/development-on-creatio-platform/development-tools/packages/assembly-package

Ryan

Also need to make sure that any dependencies and trust level will work with cloud hosted systems.

Hi Ryan,

I usually add referenced assemblies using the import option you mentioned there, but thats not working for platform-specific assembies or native assemblies (the ones that need to know if its x64 or x86).

trying to load that type of assembies is showing an error message: 

Will check with assembly package if that works. Thanks!

Andres,

Hello!

The error "File 'pdfium.dll' is not a valid .Net assembly" indicates that you're trying to load an incorrect type of library for the .NET platform.

pdfium.dll is a native (unmanaged) library, not a managed .NET assembly. Any .NET development environment, including Creatio, expects only .DLL files compiled for .NET. Platform-specific native DLLs like pdfium.dll cannot be imported directly as .NET assemblies.

As a workaround, you may consider trying the following approach: 

To do this:
1) Open the Files folder of the required package.
2) Create a new subfolder inside it—for example, name it Libs.
3) Place the required .dll file into the newly created folder.
4) Open the .csproj file of the package.
5) In the "3rd Party References" section, add a reference to the native library.
For example:
<ItemGroup Label="3rd Party References">
  <Reference Include="$(RelativePkgFolderPath)/<PackageName>/Files/Libs/<NativeLib>.dll">
    <SpecificVersion>False</SpecificVersion>
    <Private>False</Private>
  </Reference>
</ItemGroup>

After completing these steps, you can compile the package, proceed with the development and later install it on the cloud environment. This approach enables the use of native libraries within your package.

That worked. Thanks!

Orkhan,

When deploying such a solution to a cloud environment, does Creatio automatically bundle the DLL from the Files directory into the application deployment zip, or would this DLL need to be manually deployed onto the cloud environment application server(s)?

Hi Altaf Hussian,



If it’s a regular package you can use the Newtonsoft.Json core library, but for the assembly package, the required DLL must be added to the package explicitly.



The Assembly package is like an external cs project.

If you want to use an external library like Newtonsoft.Json.dll in your project - you have to specify it as a reference for your project (using) by adding that dll to the package.



The same can be achieved by using the Terrasoft core class without adding any explicit dll reference into the package as below,

Example of the code:

using CommonJson = Terrasoft.Common.Json;
string orderItemsInput = CommonJson.Json.Serialize("YourObject");

string orderItemsInput = Terrasoft.Common.Json.Json.Serialize("yourObject");

Terrasoft.Common.Json

Serialize Polymorphism

 

BR,

Bhoobalan Palanivelu.

Hello Luca,

I am not sure I understand you correctly. Can you please send an expected result and an actual result you receive?

Thank you!

Best regards,

Oscar

Hi Oscar Dylan,

I have a visual studio C# project binded to OdataV3 endpoint ("/0/ServiceModel/EntityDataService.svc/") and I don't find the custom entities created by me.

Using the following URL: "http://localhost/0/odata/$metadata" (ODataV4) I can see the expected entities.

The problem is that if I try to generate ODataV4 client code using "Unchase OData Connected Service" add-On it returns this error when I use ODataV4 endpoint.

While if I use ODataV3 endpoint with "Unchase OData Connected Service" add-On everything runs fine but the custom entities are missing (first picture). Furthermore if I use ODataV3 in a simple package every custom entity endpoint is available.

Did I make myself clear?

Thanks,

Luca

Luca Tavasanis,

Yes, it's clear now, thank you!

The problem is that OData3 forms its metadata based on the default assembly and doesn't include separate assemblies (where your objects are located), while OData4 uses a separate special assembly (neither default nor the custom one). And that's why its impossible to get access objects in packages compiled in the separate assembly using OData 3.

Our core R&D team will review this logic in the future releases, meanwhile the only way to access the object is using OData 4 only.

Best regards,

Oscar

Hello Luca,

As stated in the Academy article here: 

• It is not possible to implement object business logic via event sub-processes in the Object Designer. Use EntityEventListener to work with the event model. The EntityEventListener event set does not entirely match the event model in Creatio IDE. Learn more about the Entity event layer: Objects business logic.

And enabling the event on the object is needed for the sub-process in the object designer only. Please use the EntityEventListener instead.

Best regards,

Oscar

Hi Oscar,

I actually enabled the event on the object just to use it (as you said) in the sub-process in the object designer, but the customizations that I made there didn't work in an assembly package,  instead worked in a simple one.

Let me know if I have made myself clear or if you need other explanations.



Thank you.

Best regards,



Luca

Luca Tavasanis,

Hi,

As you said, you've enabled the event on the object to use in the sub-process in this object and did it in the assembly package. As stated on the Academy - it's impossible to use sub-processes on the object in the assembly package (and as a result the source code for the object won't be updated in case you are designing this sub-process in the assembly package). Can you please clarify what exactly is expected here?

Best regards,

Oscar

Hi Oscar,

sorry but I didn't understand that you were talking about the assembly package, my fault.

I will try the solution that you suggested with the EntityEventListener.

Thank you for your help!

Best regards,

Luca