|
|
Rank: Advanced Member
Groups: Member
Joined: 10/4/2016
Posts: 104
|
I have an existing project which references EO.Base, EO.Web, EO.WebBrowser, EO.WebBrowser.Wpf, and EO.WebEngine, I am simply updating the DLLs to EO.23.2.48.0 from EO.20.2.90.0, but receive the error below when trying to build. What is the issue here? This same build command worked for EO.20.2.90.0 and the DLLs are referenced in the same way as before.
Note: This error is repeated for all referenced EO DLLs in the project.
Error:
2023-10-17T21:04:35.8337699Z Resolved file path is "F:\Agents\Workspace\A8\_work\1230\s\Web.EO\EO.23.2.48.0\EO.Web.dll".
2023-10-17T21:04:35.8338460Z Reference found at search path location "{HintPathFromItem}".
2023-10-17T21:04:35.8339033Z Primary reference "EO.WebBrowser".
2023-10-17T21:04:35.8347450Z ##[warning]F:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2301,5): Warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. System.BadImageFormatException: Could not load file or assembly 'EO.WebBrowser.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'EO.WebBrowser.dll' ---> System.BadImageFormatException: Could not load file or assembly 'EO.WebBrowser.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'EO.WebBrowser.dll'
at System.Reflection.AssemblyName.nGetFileInformation(String s)
at System.Reflection.AssemblyName.GetAssemblyName(String assemblyFile)
at Microsoft.Build.Shared.AssemblyNameExtension.GetAssemblyNameEx(String path)
at Microsoft.Build.Tasks.ResolveAssemblyReference.<>c.<Execute>b__255_3(String p)
at Microsoft.Build.Tasks.SystemState.GetAssemblyName(String path)
at Microsoft.Build.Tasks.ReferenceTable.SetPrimaryAssemblyReferenceItem(ITaskItem referenceAssemblyName)
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi,
We are not aware of any corrupted DLLs in our public build. I would recommend you to create a separate clean test project and then reference those DLLs directly to see if that works. If that works but your doesn't, then it might have to do with file access/permission issue. If that does not work, then it probably means the DLLs are really corrupted. In that case we would recommend you to reinstall from our current version, refresh the DLLs and then try again.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/4/2016
Posts: 104
|
Hi,
Thank you for your reply. We are not suspected any corrupted DLL in this case. We are actually investigating a peculiar situation when we receive the above mentioned errors when building within our DevOps pipeline whereas it is compiling fine within the developer environment or was compiling fine with the previous DLL in that same DevOps environment - using the same pipeline pointing to the old DLL.
We upgraded to those later DLLs, made the few other changes required due to some signature changes. Is there any changes in the way those DLL were built between EO.20.2.90.0 and EO.23.2.48.0 that we should be aware? We really looking for hints and help to resolve that issue as we really want to move on to this latest updated.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
No. We can't think of any signficant change in term of building process in between these two versions. The only big change is during the 2022 build cycle we brielfly removed support for .NET Framework 2.0 (DLLs are built using .NET Framework 4.6). However this change was reverted since the start of the 2023 build cycle so the current version is still build with .NET Framework 2.0. In another word, it's the same between v20 and v23.
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/4/2016
Posts: 104
|
We suspect that there is something related to 32-bit/64-bit DLLs.
All the EO Dlls in EO.23.2.48.0 are of 32-bit version. Can we get a 64-bit version of the same dll's? Or even if you have any available in the higher versions?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
No. It shouldn't have anything to do with 32 bit/64 bit. All our DLLs are built for AnyCPU. So regardless the bitness of your target system/build system, our DLLs will be loaded properly.
The difference between the 32 bit/64 bit version lies in the native code embedded inside our DLL. These native codes are dynamically loaded at runtime by our .NET code and our .NET code will throw an exception if you attempt to run the 64 bit version on a 32 bit system. However this is a runtime exception that occurs AFTER our DLLs have already been loaded. It is not a load time exception. The .NET part loads and runs on both 32 bit and 64 bit system.
|
|