Replies: 2 comments 6 replies
-
|
Hi @Capsup, Unfortunately this look very specific to ILRepack. I'm thinking they're not adjusting the custom attributes on generic constraints containing types when merging them, so when writing Cecil is telling you that there's a mismatch in the metadata. I suggest you file a bug with ILRepack. |
Beta Was this translation helpful? Give feedback.
-
|
That's a lot of pretty big questions :) ILRepack uses Cecil as a metadata reader/writer. In the metadata, everything has a scope: where things are defined. ILRepack uses Cecil to merge things together and adjust their scope so that if you have types coming from multiple assemblies their scope end up being one final assembly. There's no magical process making Cecil pick one based on name. It's all pre-backed in the metadata. The nullable feature started using a metadata feature that wasn't generally used before the introduction of the feature: custom attribute on a generic constraint. In pseudo C#, that's like writing: class Foo<T> where [Nullable]T {}That's not valid C#, but that's what the C# compiler generates. Supporting this required an API breaking change in Cecil. Looking at ILRepack, I don't think they've updated to this version. Now imagine you have 2 assemblies that you want to merge, A and B, and in one of them you define When ILRepack is going to merge everything into C, it's going to change the scope of the types so they're defined in C. Except that because it hasn't been told to do it, it's not going to process the custom attributes of the generic constraints like T in Foo above. So when writing C, Cecil still sees a usage of Nullable that is defined in A, while ILRepack should have updated it to point to C and that's why you're seeing this exception. All of this to say, you can not fix this specific issue without adding support in ILRepack for custom attributes on generic constraints. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @jbevain! Thanks for the detailed description. I have spent some more time looking into this problem and as far as I can tell, ILRepack is supposed to fix generic constraints already. At least there is some code that seems to do it here: https://gitlab.com/capsups1712/ilrepack.netstandard/-/blob/master/ILRepack/ReferenceFixator.cs#L408 The above repository is my fork of the package, made to support .NET Standard instead, with the new csproj format. I verified that the Mono.Cecil version can actually read generic constraints: I have also tried another option, that is, a custom MSBuild task which uses Cecil to remove this attribute from all generic constraints in my dependencies, it looks like this: (ignore the contrived Harmony stuff to actually get an instance of DefaultAssemblyResolver...) namespace RemoveNullableTask
{
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using HarmonyLib;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using Mono.Cecil;
using Mono.Collections.Generic;
public class RemoveNullableTask : Task
{
[Required]
public ITaskItem[] Assembly { get; set; }
[Required]
public ITaskItem OutputPath { get; set; }
[Required]
public ITaskItem VintageStoryPath { get; set; }
public override bool Execute()
{
var defaultResolverType = typeof(Harmony).Assembly.GetType("Mono.Cecil.DefaultAssemblyResolver");
var baseResolverType = typeof(Harmony).Assembly.GetType("Mono.Cecil.BaseAssemblyResolver");
var resolver = (IAssemblyResolver)defaultResolverType.GetConstructor(Type.EmptyTypes).Invoke(null);
var addSearchDirectory = AccessTools.DeclaredMethod(baseResolverType, "AddSearchDirectory");
addSearchDirectory.Invoke(resolver, new object[] { this.OutputPath.ItemSpec });
addSearchDirectory.Invoke(resolver, new object[] { this.VintageStoryPath.ItemSpec });
addSearchDirectory.Invoke(resolver, new object[] { Path.Combine(this.VintageStoryPath.ItemSpec, "Lib") });
addSearchDirectory.Invoke(resolver, new object[] { Path.Combine(this.VintageStoryPath.ItemSpec, "Lib32") });
addSearchDirectory.Invoke(resolver, new object[] { Path.Combine(this.VintageStoryPath.ItemSpec, "Lib64") });
foreach (var assembly in this.Assembly)
{
this.Log.LogMessage(MessageImportance.High, "{0}...", assembly.ItemSpec);
using (var assemblyDefinition = AssemblyDefinition.ReadAssembly(assembly.ItemSpec, new ReaderParameters
{
ReadWrite = true,
AssemblyResolver = resolver
}))
{
foreach (var module in assemblyDefinition.Modules)
{
foreach (var method in module.Types.SelectMany(t => t.Methods).Where(m => m.HasGenericParameters))
{
this.RemoveNullableAttribute(method.GenericParameters.Select(x => x.CustomAttributes), method.FullName);
foreach (var parameters in method.GenericParameters)
{
this.RemoveNullableAttribute(parameters.Constraints.Select(y => y.CustomAttributes), method.FullName);
}
}
foreach (var type in module.Types.Where(t => t.HasGenericParameters))
{
this.RemoveNullableAttribute(type.GenericParameters.Select(x => x.CustomAttributes), type.FullName);
foreach (var parameters in type.GenericParameters)
{
this.RemoveNullableAttribute(parameters.Constraints.Select(y => y.CustomAttributes), type.FullName);
}
}
}
assemblyDefinition.Write();
}
}
return true;
}
private void RemoveNullableAttribute(IEnumerable<Collection<CustomAttribute>> customAttributeList, string belongsTo)
{
foreach (var customAttributes in customAttributeList)
{
for (CustomAttribute attribute = null; (attribute = customAttributes.FirstOrDefault(a => a.AttributeType.Resolve().FullName == "System.Runtime.CompilerServices.NullableAttribute")) != null;)
{
this.Log.LogMessage(MessageImportance.High, "\tRemoving nullable attribute from {0}", belongsTo);
customAttributes.Remove(attribute);
}
}
}
}
}But I still see the same error: And that's after running the above task on all of my dependencies: The task reports having removed the attribute in two assemblies, Is there any way I can get Mono.Cecil to tell me exactly what module contains the offending attribute? Thanks a lot for your help too. Is there any way for me to pay for some of your time to help me with this problem? I really need to solve it and I'm really starting to run out of ideas to try here... |
Beta Was this translation helpful? Give feedback.
-
|
Then it's hard to say, we'd need to debug it I guess. Sure, reach out to me on my profile's email and we can work something out. |
Beta Was this translation helpful? Give feedback.
-
|
Tried reaching out to your e-mail but I get a bounceback trying to send an e-mail. |
Beta Was this translation helpful? Give feedback.
-
|
@Capsup “it works here”. You can also try my GitHub alias at gmail. |
Beta Was this translation helpful? Give feedback.
-
|
The base issue seems to be that ILRepack has not been updated with knowledge of Nullable Reference Types, so any assembly that uses them may confuse it. What may contribute to the problem is that for several of the new C# features, the compiler will emit "system" attributes directly in the compiled assembly instead of referencing them; that allows such features to work on older runtimes, like .NET Framework 4.7.2 (which would not include this new attribute). If you removed the uses of the attribute, consider checking whether the assembly contains Finally, if those internal attributes are present, chances are there'll also be a Hope this helps. |
Beta Was this translation helpful? Give feedback.
-
So I realize this may not be the correct place for asking for help with this problem, but I'm hoping that the people here might be able to help me in any case, since it is Mono.Cecil related.
So I'm using ILRepack, which as far as I understand, uses this library behind the scenes, to do ILWeaving. I'm running into a problem in my project, which ends up resulting in the following error as soon as I import, for example, Newtonsoft.Json version 13.0.1:
All I'm doing is adding it as a PackageReference, and when building in release mode, I get this error.
I realize the error message is quite specific, but after hours of attempts at solving this, I have been unable to. My biggest problem is I have no idea what "another module" means exactly.
This is a completely empty project except using the ILRepack package and importing Newtonsoft.Json. It targets
netstandard2.0, which I need to be the target. I cannot change this to a newer version for... reasons.Building in release mode without Newtonsoft.Json works. It also works building in debug, where ILRepack doesn't execute. So this means that the necessary Attribute must exist, otherwise it wouldn't have compiled in debug, right?
I tried defining this attribute in my project manually, like so:
but even then, I get the above error. So where is Mono.Cecil actually looking for this attribute? And why is it not even enough for me to manually define it, in my project?
The ILRepack configuration I use is this:
From a purely Mono.Cecil point of view, what options do I have for telling Mono.Cecil where to look for this attribute?
Or can I somehow make it ignore the attribute completely? I don't need to use it, I just need this to compile properly.
See the attached output.txt for a log file:
output.txt
Inside this log file, I also noticed that it actually does import the NullableAttribute that I manually defined:
Importing System.Runtime.CompilerServices.NullableAttribute from TestSolution4.dll, but why doesn't Mono.Cecil just use this one then?Any help greatly appreciated!
Beta Was this translation helpful? Give feedback.
All reactions