Extension Error: 'Could not load file or assembly' while using extension

Extension Error: 'Could not load file or assembly' while using extension

  

Hi,

While developing C# extensions in OutSystems 10 on the personal cloud environment, I keep getting errors like Could not load file or assembly 'Namespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

In C#, the reason for this error is that the .dll for the given namespace could not be found, but in this case I am sure that it is present in the extension.

I am sure of this, because, If I change the name of the eSpace consuming the extension, then it works, which leads me to be believe that this issue is related with deploying the .dll from the extensions to the application server.

Is there any way of preventing this from happening on the cloud environment? In an on-premises environment I have access to the application server (IIS) and could ensure that .dll is accessed correctly.

Has anyone managed to fix this issue without changing the name of the eSpace?

Regards,

João Mateus

Hi João,


Can you replicate the problem consistently? 

Not sure if I can get a personal on O10 to test it, but can probably try it on a O11.


As to fix it without renaming the module, you can try republishing it in Service Center (instead of publishing via Service Studio), since that skips some optimizations.


Regards,

João Rosado

João Rosado wrote:

Hi João,


Can you replicate the problem consistently? 

Not sure if I can get a personal on O10 to test it, but can probably try it on a O11.


As to fix it without renaming the module, you can try republishing it in Service Center (instead of publishing via Service Studio), since that skips some optimizations.


Regards,

João Rosado

Hi João,

I have had this problem a couple of times before, it seems to happen when an new Extension is published and an external .dll is added in Integration Studio. OutSystems seems to be having problems deploying that .dll to that specific IIS application.

When this error happens for a specific eSpace name I was not able to use the extension in that eSpace without changing its name, which translates into a new path in the application server.

Like you suggested, I went to service center, republished the eSpace and also redeployed the published version but nothing changed.

Regards,

João Mateus


Can you upload an extension example for me to try?

I have multiple extensions with external dlls in my personal environment and never had issues.


Regards,
João Rosado

Go to the "resources" tab of the Extension in Integration Studio, make sure that the needed DLLs are going to be deployed (right click the files to verify).

J.Ja

Hi,

Thanks for the answers @João and @Justin

@João - Unfortunately, I can't upload this particular extension. I believe this problem happens when there are DLLs that have dependencies between them, in this particular case I used an external DLL that depends on another external DLL. Both were added in Integration Studio.

@Justin - That's how I added the DLLs. I added the DLLs using the Resources tab, opened the BIN folder added the DLLs (made sure they were included in the extension) and then opened the extension in the IDE and rebuilt the Solution. Then published it in Integration Studio. However, this does not explain why it works for some applications and not for others.

I managed to minimize the impact of this problem by consuming the extension in a Core module, which would encapsulate its functionality, instead of in an End User module. This way, it is not necessary to change the name of the EU module, which would change the endpoint to access the application, only the Core module's (if the error persists) which does not impact the user.

By doing this, I was able to revert back to my initial eSpace name.

Regards,

João Mateus

Joao -

There is the possibility that you have encountered DLL Hell.

What are the DLLs you are trying to use in your Extension?

J.Ja

Justin,

I believe you are correct and I have indeed encountered DLL hell.

The DLLs being used are custom code I developed alongside the Outsystems extension. After reading more about DLL hell, I think that some refactoring that I did, after first publishing the extension and using it on the Outsystems module, such as changing the assembly, namespaces or class names, is the reason for this problem.

Even though I am uploading the correct DLLs in Integration Studio, the Outsystems application has been unable load the correct DLL and is trying to use the old one (which has different assembly and namespaces) hence the error on my initial post. This explains why the extension works correctly for a new Outsystems module, which does not contain older DLLs.

Now, is there a way to clear the older DLLs and force the new one to be used? 

Regards,

João Mateus