Is there a way to resolve a type from the executing assembly in dotnetfiddle environment

[Serg046]

I am talking about this example https://dotnetfiddle.net/tR9D3D:

var asm = Mono.Cecil.AssemblyDefinition.ReadAssembly(typeof(Program).Module.FullyQualifiedName);
asm.MainModule.ImportReference(typeof(Program)).Resolve();

which prints

Unhandled exception. Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: '1ybp1zok.exe, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
   at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters) in C:\src\cecil\Mono.Cecil\BaseAssemblyResolver.cs:line 172
   at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name) in C:\src\cecil\Mono.Cecil\BaseAssemblyResolver.cs:line 117
   at Mono.Cecil.DefaultAssemblyResolver.Resolve(AssemblyNameReference name) in C:\src\cecil\Mono.Cecil\DefaultAssemblyResolver.cs:line 33
   at Mono.Cecil.MetadataResolver.Resolve(TypeReference type) in C:\src\cecil\Mono.Cecil\MetadataResolver.cs:line 110
   at Mono.Cecil.ModuleDefinition.Resolve(TypeReference type) in C:\src\cecil\Mono.Cecil\ModuleDefinition.cs:line 748
   at Mono.Cecil.TypeReference.Resolve() in C:\src\cecil\Mono.Cecil\TypeReference.cs:line 278
   at Program.<Main>$(String[] args)
Command terminated by signal 6

This works fine when I run it locally and I have no idea what is different with dotnetfiddle (probably something related to the process or its isolation). Could anybody help to investigate it? Please note that the following example works there fine https://dotnetfiddle.net/XGfVNL:

var asm = Mono.Cecil.AssemblyDefinition.ReadAssembly(typeof(System.DateTime).Module.FullyQualifiedName);
asm.MainModule.ImportReference(typeof(System.DateTime)).Resolve();

[adrianoc]

That is strange.

One workaround (really ugly) is to pass an assembly resolver that returns that assembly:

#define TEST
using System.IO;
using System;

var readerParams = new Mono.Cecil.ReaderParameters();

var resolver = new Mono.Cecil.DefaultAssemblyResolver();
readerParams.AssemblyResolver = resolver;

#if TEST
resolver.ResolveFailure += (sender, args) => 
{
	return Mono.Cecil.AssemblyDefinition.ReadAssembly(typeof(Program).Assembly.Location);
};
#endif

var files = Directory.GetFiles(Path.GetDirectoryName(typeof(Program).Assembly.Location));
foreach(var file in files)
	Console.WriteLine(file);

#if !TEST
System.Console.WriteLine(System.IO.Path.GetDirectoryName(typeof(Program).Assembly.Location));
resolver.AddSearchDirectory(System.IO.Path.GetDirectoryName(typeof(Program).Assembly.Location));
#endif

var asm = Mono.Cecil.AssemblyDefinition.ReadAssembly(typeof(Program).Assembly.Location, readerParams);
var resolved = asm.MainModule.ImportReference(typeof(Program)).Resolve();
System.Console.WriteLine(resolved);

[Serg046]

Interesting, if I update your resolver to look like this:

resolver.ResolveFailure += (sender, args) => 
{
	Console.WriteLine(args.GetType().FullName);
	Console.WriteLine(args.Name);
	Console.WriteLine(File.Exists(Path.Combine(".", args.Name)));
	return Mono.Cecil.AssemblyDefinition.ReadAssembly(typeof(Program).Assembly.Location);
};

Then I get:

Mono.Cecil.AssemblyNameReference
kakojdie.exe
True

Looks like Cecil tries to find kakojdie.exe.exe.

protected virtual AssemblyDefinition SearchDirectory (AssemblyNameReference name, IEnumerable<string> directories, ReaderParameters parameters)
		{
			var extensions = name.IsWindowsRuntime ? new [] { ".winmd", ".dll" } : new [] { ".exe", ".dll" };
			foreach (var directory in directories) {
				foreach (var extension in extensions) {
// ------------------------------------ Seems it is adding an extension once again ---------------------------------
					string file = Path.Combine (directory, name.Name + extension);
// -----------------------------------------------------------------------------------------------------------------
					if (!File.Exists (file))
						continue;
					try {
						return GetAssembly (file, parameters);
					} catch (System.BadImageFormatException) {
						continue;
					}
				}
			}

			return null;
		}

https://github.com/jbevain/cecil/blob/master/Mono.Cecil/BaseAssemblyResolver.cs#L215

I will continue investigation and then probably propose a PR. We should probably check if there is an extension already in the name and try to find the file without additional extensions for such cases.

[adrianoc]

interesting.. so it looks to me that dotnetfiddle is generating a module with the extension as part of the name... I am not sure that is correct.
try modifying the code to print the assembly name and run it locally and in dotnetfiddle. I guess they will differ

[Serg046]

Exactly, that's what I am gonna do. I will try to check if having an extension in the name is a possible valid case. Usually you don't have it there.

[Serg046]

The docs say that the assembly name could be anything, although the best practice is to use the name of the file without its extension. Sometimes it is even a must. Seems it doesn't make sense to support this corner .NET Fiddle case. Imagine your someLib.dll has an assembly name = "blablabla.ext". There is nothing to do with it. However, I will try to communicate it with .NET Fiddle guys. Unfortunately, their communication channel is their twitter, not sure if they will notice my voice.

P.S. If you are interested in fixing this specific issue with .NET fiddle as well as me, I will create a PR @jbevain