I might miss something, but did you install Chilcat on the new server?

Also, do you have any idea what DNN extension is actually using ChillCat?

Posted By Timo Breumelhof Host (SU) on 1/10/2024 7:05 AM

I might miss something, but did you install Chilcat on the new server?

Also, do you have any idea what DNN extension is actually using ChillCat?

In the dnn website bin folder ,there is 'ChilkatDotNet2' dll file and in web config file there is dependent assembly like

<assemblyIdentity name="ChilkatDotNet4" publicKeyToken="-------" />

As the website using so many dnn modules, both custom and others , I am not sure which DNN extension is actually using Chilkat

Have you tried installing the 32-bit Visual C++ runtime along with setting Application Pools "Enable 32-bit Applications" to True ?

Posted By James Clarkson on 1/10/2024 10:27 AM

Have you tried installing the 32-bit Visual C++ runtime along with setting Application Pools "Enable 32-bit Applications" to True ?

Yes, from this link  Microsoft VC++ Runtime Redist Downloads tried installing x64 architecture and tried setting Application Pools "Enable 32-bit Applications" to True

Posted By Will Strohl on 1/9/2024 11:47 AM

Posted By divyamk on 1/9/2024 8:34 AM

Exception type: ConfigurationErrorsException 
Exception message: Could not load file or assembly 'ChilkatDotNet2' or one of its dependencies. An attempt was made to load a program with an incorrect format.

First, another step that could help to find issues is to perform a clean installation of the same version and SKU (e.g., Platform or Evoq) of DNN you're using and then grab a copy of that web(dot)config file.  Use a comparison program like WinMerge to compare the files to determine if there are any other dependencies that you may not be aware of.  It often also will show missing & legacy updates that you may want to incorporate as well.  My goal when doing this is to put everything into the same order first, then compare it line by line to see if anything looks out of place.  The web(dot)config files will never be a 100% match, but this process can highlight a lot about your site. 

Now, the error message you just presented is usually fairly straightforward.  Normally, this message means that either the site (or the file itself) doesn't have proper permissions assigned.  Either that or the file is literally missing.  However, if the site worked without any modifications just before, then it sounds more likely that this DLL may need to be rebuilt using a newer version of .NET.  It may be compiled against a .NET version that's too old for the new server.  

 

The website is running on dnn version 09.05.00 . As you suggested, performed a clean installation of the same version, copied and compared web config file from fresh installation and one from the website.There are about 424 additional lines in website web config with a number of dependent assemblies including devexpress and corresponding dlls are there on bin folder

About the chance of permission issue for ChilkatDotNet2 dll, I have checked and verified folder permission.Let me know how can I perform DLL rebuilt using a newer version of .NET and how to modify corresponding changes on web config file

I just want to be sure that (1) you found the DLL in the Bin folder; and (2) the DLL is what you expected...?  For example, it's there, and it matches the version number you see in the assemblyBinding in the web(dot)config?  This is where/what you checked and reapplied permissions too, correct? 

I'd also suggest looking for any rogue .config files in the Bin folder.  They'll often be named something like AssemblyName.dll.config.  Sometimes, these other rooted config files will cause something else to happen.  

Did you see anything odd in the main website config file?  I know there's additional lines of code, but once you put everything in the same order as a clean install, you can much more clearly see what's added and maybe what shouldn't be.  This also will help to highlight any legacy config updates you may want to consider removing, and so on.  I can't tell you how many times this step has tripped me up over the years.  Developers put all kinds of things in the config file when they don't know other ways to do them.  

I intentionally meant the 32-bit version, not just the 64-bit version that you indicate.
Could you try installing the X86 one as well please.

Posted By James Clarkson on 1/10/2024 3:58 PM

I intentionally meant the 32-bit version, not just the 64-bit version that you indicate.
Could you try installing the X86 one as well please.

Yes installed that one also

Posted By divyamk on 1/11/2024 6:51 AM

Posted By Will Strohl on 1/10/2024 12:56 PM

I just want to be sure that (1) you found the DLL in the Bin folder; and (2) the DLL is what you expected...?  For example, it's there, and it matches the version number you see in the assemblyBinding in the web(dot)config?  This is where/what you checked and reapplied permissions too, correct? 

I'd also suggest looking for any rogue .config files in the Bin folder.  They'll often be named something like AssemblyName.dll.config.  Sometimes, these other rooted config files will cause something else to happen.  

Did you see anything odd in the main website config file?  I know there's additional lines of code, but once you put everything in the same order as a clean install, you can much more clearly see what's added and maybe what shouldn't be.  This also will help to highlight any legacy config updates you may want to consider removing, and so on.  I can't tell you how many times this step has tripped me up over the years.  Developers put all kinds of things in the config file when they don't know other ways to do them.  

Yes, DLL is there on Bin folder and is expected DLL. In the case of ChilkatDotNet2, in web config file there is dependent assembly like

<assemblyIdentity name="ChilkatDotNet4" publicKeyToken="-------" />

But in the website Bin folder ,there is 'ChilkatDotNet2' dll file not ChilkatDotNet4. When I executed following statement in Powershell

([system.reflection.assembly]::loadfile("C:\..\Full_Path\..\ChilkatDotNet2[dot]dll")).FullName

The output provide the Version, Culture and PublicKeyToken corresponding to ChilkatDotNet4 dependent assembly binding

I tried deleting above dependent assembly from web config , but still getting  'Could not load file or assembly ChilkatDotNet2'  error when enable 32 application on app pool

As you suggested , I checked rogue .config files in the Bin folder, but not found any.

Do you know if the ChilkatDotNet4 DLL is compiled against a newer version of .NET?  If it hasn't been rebuilt against a newer version of .NET, it may simply be that the .NET Framework isn't able to read the code, but knows it's a dependency.  If you have access to that DLL, ideally it should be compiled against .NET 4.7.2.