44
Views
4
Comments
Solved
[Snowflake Connector] Could not load file or assembly 'Snowflake.Data, Version=1.1.2.0,...
snowflake-connector
Service icon
Forge asset by Rita Tomé
Application Type
Service

Dear community members, have you come across the below error while executing this component's RunQuery action?

We've attempted to detach and reattach the Snowflake.dll to the Visual Studio project references and recompile the solution again, but to no avail. We've also attempted to search for similar such errors but could not establish any relation to this specific component's case e.g.

- Library hell: in our scenario we only have Snowflake Connector as the producer and a sample consumer app, so no complex order of dependencies neither multiple producer/consumers.


Any help, greatly appreciated!

2025-11-11 13-17-51
Rajan C
Solution

Hi Pedro,

As you suggested we can resolve this assembly reference issues in below approaches including your suggested approach,

Approach 1:

Check the dll version of newtonsoft with the snowflake SDK version

i.e Newtonsoft (11.0.0) and snowflake.Data DLL (2.2.0)

 

snowflake.data dll itself has newtonsoft dll so both the versions under the solution should match in order to generate the file correctly.

 

Approach 2:

If the approach 1 doesn't work then follow this approach,

Instead of de-serialising the data results in the extension. Return the data results as string and do the serialization & deserialization in outsystems.

This could solve the dll conflicts.

 

Approach 3:

If the above SDK/Dll approaches doesn't work then go with the REST API approach with Key pair authentication instead of OAuth.


 

UserImage.jpg
Francisco Calderón

Hi Pedro,

The error image you provided seems to be broken so I am unable to see the exact error message. If you can reupload it that would be great to possibly give you a better answer.

That being said, we have run into a particular error in a project with that component, although the setting seems to be a bit different than the one you're describing. In our case, it happened to be an instance of "Library Hell" due to having a couple different versions of the component/extension, with each pointing to a different version of the Snowflake.dll due to one of them being updated manually. The issue in our case was solved by having all of the extensions use the same version of the DLL. It's also important to make sure you republish the apps with full compilations after this change, to ensure no consumer module got "left behind" in terms of dependencies.

Not sure if this is relevant here, but something to note is that the DLL in question seems to have a lot of dependencies itself, one of which includes the Newtonsoft DLL for JSON Serialization. This DLL is already included as a default OutSystems library, so if the Snowflake component is modified/updated in some way, you need to ensure that it is a compatible version and that the Newtonsoft dependency isn't uploaded to the server as it could enter in conflict with the version OutSystems uses, basically leading to another instance of "Library Hell". This particular scenario hasn't happened to me with the Snowflake component itself but with other extensions that had Newtonsoft as an indirect dependency.

Hopefully this helps in some way.


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

Thank you Francisco, I'm very grateful for your swift reply.

Reuploading the image again (on my end it looks good but it may be due to a source reference that I myself can only access).

With regards to the Library Hell (LH) problem I can't quite understand how this manifests in my case since there is only 1 producer and 1 consumer involved, and 1 version of the Snowflake.dll however you have a point with regards to Snowflake's dependencies itself so I'll have a further look.


Thank you!

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

Hi Francisco regarding this

if the Snowflake component is modified/updated in some way, you need to ensure that it is a compatible version and that the Newtonsoft dependency isn't uploaded to the server as it could enter in conflict with the version OutSystems uses, basically leading to another instance of "Library Hell". 

I just validated the internal references of Snowflake.dll (using ILSpy suggested in [1]) and found out that Newtonsoft dependency does exist, however the version (11.0.0.0) is exactly the same as the OutSystems extension's. Therefore this would not result in a missing DLL version, right? Believe we can discard this possibility. Any further suggestions?

[1] https://stackoverflow.com/questions/227886/how-do-i-determine-the-dependencies-of-a-net-application

2025-11-11 13-17-51
Rajan C
Solution

Hi Pedro,

As you suggested we can resolve this assembly reference issues in below approaches including your suggested approach,

Approach 1:

Check the dll version of newtonsoft with the snowflake SDK version

i.e Newtonsoft (11.0.0) and snowflake.Data DLL (2.2.0)

 

snowflake.data dll itself has newtonsoft dll so both the versions under the solution should match in order to generate the file correctly.

 

Approach 2:

If the approach 1 doesn't work then follow this approach,

Instead of de-serialising the data results in the extension. Return the data results as string and do the serialization & deserialization in outsystems.

This could solve the dll conflicts.

 

Approach 3:

If the above SDK/Dll approaches doesn't work then go with the REST API approach with Key pair authentication instead of OAuth.


 

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