Assembly Loading Problem in Tizen .NET Applications
you may have encountered the following error when launching a .net application on your tizen device, although the dll file specified by the error message is already owned by the application (in tpkroot). note: you can view the log from the tizen log viewer window or dlogutil. unhandled exception. system.io.filenotfoundexception: could not load file or assembly 'system.collections.immutable, version=1.2.5.0'. the system cannot find the file specified. file name: 'system.collections.immutable, version=1.2.5.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a' at tizenapptemplate.app.oncreate() at tizen.applications.corebackend.uicorebackend.oncreatenative(intptr data) at tizen.applications.corebackend.uicorebackend.run(string[] args) at tizen.applications.coreapplication.run(string[] args) at tizen.applications.coreuiapplication.run(string[] args) at tizenapptemplate.app.main(string[] args) why do i see this error? the error is a result of a dll version mismatch. your application expects a newer version of system dll than what the device has. this error appears when both of the following conditions are met: the application package contains or has a recursive dependency on one or more system dlls (system.* or tizen.*) the application's system dlls are newer than dlls installed on the device this usually happens when you reference a system package from your application. the following example shows an application project file (.csproj) that contains such a reference. <propertygroup> <outputtype>exe</outputtype> <targetframework>tizen50</targetframework> </propertygroup> <itemgroup> <packagereference include="system.collections.immutable" version="1.7.0" /> </itemgroup> in some cases, the file doesn't reference the system package directly. however, it may have a recursive dependency in its dependency graph. <itemgroup> <!-- this library is dependent on system.collections.immutable 1.7.0. --> <packagereference include="somelibrary" version="1.0.0" /> </itemgroup> note: assemblyversion, assemblyfileversion, and nuget packageversion are different version properties. for example, the nuget package system.collections.immutable version 1.7.0 (nugetpackageversion) comes with system.collections.immutable.dll version 1.2.0.5 (assemblyversion). only assemblyversion is used by the runtime to verify dll dependencies. the following example shows the assemblyversion of the dll used by the application and the assemblyversion of the dll installed on the system. ### application-owned dll $ sdb pull /opt/usr/globalapps/org.tizen.example.tizenapptemplate/bin/system.collections.immutable.dll $ dotnet-ildasm system.collections.immutable.dll | grep '\.ver' | tail -n 1 .ver 1:2:0:5 ### pre-installed dll $ sdb pull /usr/share/dotnet.tizen/netcoreapp/system.collections.immutable.dll $ dotnet-ildasm system.collections.immutable.dll | grep '\.ver' | tail -n 1 .ver 1:2:0:4 the current implementation of the application launcher in tizen (which hosts the .net runtime) always prioritizes dlls found on the device and disregards application-owned dlls, even though they are newer. it also ignores any properties defined in the application's .deps.json file. in fact, this restriction is intentionally added in tizen for performance reasons. the launcher pre-fetches several runtime components commonly used by applications (for reduced startup time) by assuming a unified set of trusted platform assemblies across all applications. because of the fundamental design of coreclr, a dll cannot be loaded into the default loadcontext if a dll with the same name exists in the trusted platform assemblies. for further details, you can read: runtime-dependent deployment coreclr hosting apis assemblyloadcontext class tizen's launcher implementation possible solutions here are some solutions you can try: remove or downgrade the package the first, most basic workaround you can try is to eliminate the dependency itself. check if the package is being used in the code and, if possible, re-implement the code without the package. otherwise, downgrade the package from nugets so that its dll versions are compatible with all target devices. however, this may not be feasible if you cannot find a working version or you cannot control the dependencies of the libraries used by your application. <itemgroup> <!--<packagereference include="system.collections.immutable" version="1.7.0" />--> <packagereference include="system.collections.immutable" version="1.6.0" /> </itemgroup> handle assemblyresolve events another workaround is to install a custom assemblyresolve event handler inside your application. this handler is invoked when the runtime cannot find a dll with a matching version. note that if an application dll has a native image, the native image is not automatically resolved by assembly.loadfile(). static void main(string[] args) { appdomain.currentdomain.assemblyresolve += (object s, resolveeventargs eventargs) => { var appdir = path.getdirectoryname(typeof(app).assembly.location); var assemblyname = eventargs.name.split(',')[0]; var assemblypath = path.combine(appdir, assemblyname + ".dll"); return file.exists(assemblypath) ? assembly.loadfile(assemblypath) : null; }; .. app.run(args); } use this api with care since it can cause some unexpected behaviors, such as a type identity problem (see best practices for assembly loading). also, you cannot use assembly.load() (with a full assemblyref as an argument) or assembly.loadfrom() because they implicitly load an assembly into the default loadcontext and this leads to a similar error: unhandled exception. system.io.fileloadexception: could not load file or assembly 'system.collections.immutable, version=1.2.5.0'. could not find or load a specific file. (0x80131621) file name: 'system.collections.immutable, version=1.2.5.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a' ---> system.io.fileloadexception: could not load file or assembly 'system.collections.immutable, version=1.2.5.0'. at system.runtime.loader.assemblyloadcontext.internalloadfrompath(string assemblypath, string nativeimagepath) at system.runtime.loader.assemblyloadcontext.loadfromassemblypath(string assemblypath) at system.reflection.assembly.loadfrom(string assemblyfile) .. use custom assemblyloadcontext for advanced scenarios, you can create your own assemblyloadcontext in your application to isolate any specific dlls. the following customassemblyloadcontext class overrides the load() method to resolve dlls from the current application directory. see understanding system.runtime.loader.assemblyloadcontext for detailed information. private class customassemblyloadcontext : assemblyloadcontext { protected override assembly load(assemblyname assemblyname) { var appdir = path.getdirectoryname(typeof(app).assembly.location); var assemblypath = path.combine(appdir, assemblyname.name + ".dll"); return file.exists(assemblypath) ? loadfromassemblypath(assemblypath) : null; } } // in application code, var alc = new customassemblyloadcontext(); var assembly = alc.loadfromassemblyname(new assemblyname("somelibrary")); assembly.gettype("somelibrary.someclass").getmethod("somemethod").invoke(null, null); the sample code shown above may not work if the prefer_dotnet_aot manifest property is enabled in tizen-manifest.xml because application dlls can have their native images located in either bin or bin/.native_image. in such cases, consider using applicationinfo.executablepath from the tizenfx api instead of assembly.location. if you need help, please contact me at swift.kim@samsung.com. for further information about tizen .net, see samsung developers tizen.