2248
Views
14
Comments
Extension Error: 'Could not load file or assembly' while using extension
Question

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

2012-03-16 12-21-09
João Rosado
Staff

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

2025-09-16 17-12-57
João Mateus

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


2012-03-16 12-21-09
João Rosado
Staff

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

2019-11-12 17-31-26
Justin James
 
MVP

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

2025-09-16 17-12-57
João Mateus

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

2019-11-12 17-31-26
Justin James
 
MVP

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

2025-09-16 17-12-57
João Mateus

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

UserImage.jpg
Matt Koerner

João Mateus wrote:

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


Hi João,


I seem to be running into a similar problem. Did you manage to fix this and force the new DLL to be used? 


Regards,

Matt Koerner

2025-09-16 17-12-57
João Mateus

Matt Koerner wrote:

João Mateus wrote:

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


Hi João,


I seem to be running into a similar problem. Did you manage to fix this and force the new DLL to be used? 


Regards,

Matt Koerner

Matt,

If I recall correctly I changed the OutSystems module's name or created a new module to consume the extension and it solved the issue. 

As this was an issue in my Personal Cloud and the module was not of great importance, I had no problem with this approach.

Regards,
João Mateus


2020-03-19 14-14-27
Pedro Gonçalves
Staff

Hi folks, I've recently been referencing this thread on a support case opened due to this exact same error, so thought to provide more insights to others out there.


In my case this error started when I published the JWT Forge component, whereas a much older Forge component, Firebase Web, was already existing in the environment. A frequent error with this topic's signature soon started popping up (on the client side, since this was a mobile native app), the troubleshooting pointed to a GenerateToken action within the Firebase module of the said Forge component. The dll conflict was apparently occurring with Firebase_Utils extension, referencing an internal JWT.dll which clashed with the recently deployed JWT Forge component's JWT module (which was compiled to a dll by the platform since it is referenced by other consumer modules). For my scenario I decided to rename the JWT Forge component module JWT to another name (JWTHandler), but this is something that developers on that infrastructure will need to be aware whenever upgrading the JWT Forge component again. 


Hope this helps any other folks out there, happy coding!

UserImage.jpg
Diana Mae Benitez

I have same issue on the DLL. When code is run from Visual studio, the code runs perfectly fine. But when created from integration studio and consumed in outsystems I'm getting below error. The DLL version used is in 6.29.0 but it's keep on pointing to 5.2.2 version which is no where to find. I have run it from my outsystems environment and on Dev instance, and both encountered same issue.

Could not load type 'Microsoft.IdentityModel.Tokens.TokenHandler' from assembly 'Microsoft.IdentityModel.Tokens, Version=5.2.2.0, Culture=neutral, 

Anyone can help on this? Thanks!

UserImage.jpg
Wei Pien Keoh

Encountering the same issue as Diana with the same exact error. Anyone able to resolve it?

UserImage.jpg
Diana Mae Benitez

We upgraded the platform to 11.20 it has the fix on the DLL which has version 6.26. This was the solution given by Outsystems Support. After the platform upgrade the issue no longer persist.


The 5.2.2 version is being used by OMLProcessor extension which uses same DLL.

UserImage.jpg
Rahul Shastry D

Encountering the same issue. Can somebody pls help on resolving this issue

Could not load type 'Microsoft.IdentityModel.Tokens.TokenHandler' from assembly 'Microsoft.IdentityModel.Tokens, Version=5.2.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. 

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.