Hi,
I have 2 .net DLLs that I'm trying to import into outsystems extesnion(built in .NET). In a normal .Net application, both of these DLLs would be present in the same directory. I can see both DLL's are under BIN directory in resources folder in Outsystem. DLL one references the second DLL via explicit runtime linking. Since it appears that Outsystems is separating these DLLs into different directories, the first DLL is unable to find the second DLL when extensions action method is called in web application under outsystems espace.
Thanks,
Aarti Kurkute
When you publish your extension containing both dll then you download the extension & open it then you find only 1dll.. M i right?
Rajat Agrawal wrote:
When I publish and download it I see both dlls. but when i use that extension action method in the web application in espace , i get the error saying it does not know about the second dll. first dll has some objects which are defined in second dll. so it finds the first dll but it does not find the objects whihc are in second dll so somehow IIS is separating both dlls
Can you please help on this issue? Is there something wrong I am doing?
Aarti
I'm also having the same issue. Can anyone help us with this?
aarti kurkute wrote:
This issue is solved for me. I needed to change my c# code to look for the dll's at the path Appdomain.currentDomain.BasDirectory + Bin2 folder which is on Outsystem server will be soemthing like C:\Program Files\OutSystems\Platform Server\running\{espace}\bin2
Earlier I was using executing AssemblyLocation path which was pointing to soemhting like this
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\{espace}\bd759b8b\18a295f7\assembly\dl3\f66c0db7 and hence espace had problem finding the dll's.
Hi Aarti,
Was there any reason to attempt to load the dll by path? (like one being C++ and not actually .NET?)
Usually you would just load it by assembly name and the system would find it automatically without having to know any implementation details like the bin2 folder.
System.Reflection.Assembly.Load("YourAssemblyName");
or:
System.Reflection.Assembly.Load(new System.Reflection.AssemblyName("YourAssemblyName"));
Where "YourAssemblyName" is just the name of the assembly (does not include the .dll).
Didn't that work in your case?
Regards,João Rosado