help wanted: debugging exception inside NSwag 14 #4842
Comments
vvdb-architecture
changed the title
|
I have also run into this same error after upgrading from 13.20.0 to 14.0.7, and am stuck. I have no idea where the error is occurring. |
|
@vvdb-architecture / @danchristensen2000 - I don't know if you are still trying to solve this, but we ran into what appears to be a very similar error that I noted here #4918 We were able to track down the trigger by running our web api in the debugger with it set to stop on all exceptions. Launch a browser to the swagger.json URL. This caused it to stop in the debugger at that location. By looking at what variables we could see in the debugger (particularly in Namotion.Reflection.ContextualType.Fields.get(), the base.Type pointed directly to the Action type in question), we were able to get a clue as to where this was coming from. As with you, this issue began appearing after updating from nswag v13 to v14. |
|
@adam-clauss : indeed. The issue is very similar. I can confirm what happens. The exception: ...is actually thrown from code in public ContextualFieldInfo[] Fields
{
get
{
if (_fields == null)
{
lock (this)
{
if (_fields == null)
{
_fields = base.Type.GetRuntimeFields().Select(delegate (FieldInfo field)
{
if (base.TypeInfo.IsGenericType && !base.TypeInfo.ContainsGenericParameters)
{
FieldInfo runtimeField = field.DeclaringType.GetGenericTypeDefinition().GetRuntimeField(field.Name);
if (runtimeField != null && runtimeField.FieldType.IsGenericParameter)
{
ContextualType contextualType = GenericArguments[runtimeField.FieldType.GenericParameterPosition];
int nullableFlagsIndex = contextualType._nullableFlagsIndex;
return new ContextualFieldInfo(field, ref nullableFlagsIndex, contextualType._nullableFlags);
}
}
int nullableFlagsIndex2 = 0;
return new ContextualFieldInfo(field, ref nullableFlagsIndex2, null);
}).ToArray();
}
}
}
return _fields;
}
}The implementation enumerates all the (runtime) fields of the The So now, I need some help on how to best correct this error: is it a Since I have no illusions on the speed of a resolution, I wil try to circumvent the problem but it looks like it won't be easy to do.... After some further digging, it looks like in the _fields = Type.GetRuntimeFields().Select(field =>
{
if (field.DeclaringType is { IsGenericType: true })
{
var genericType = field.DeclaringType.GetGenericTypeDefinition();
var genericField = genericType.GetRuntimeField(field.Name);
if (genericField != null && genericField.FieldType.IsGenericParameter)
{
var actualType = GenericArguments[genericField.FieldType.GenericParameterPosition];
var actualIndex = actualType._nullableFlagsIndex;
return new ContextualFieldInfo(field, ref actualIndex, actualType._nullableFlags);
}
}
var index = 0;
return new ContextualFieldInfo(field, ref index, null);
}).ToArray();... but I don't know if we can just include the latest version and have it override whatever the existing NSwag/NJsonSchema version uses... |
|
Does anyone know who to contact/who to beg to to release an updated NSwag with the latest changes of Namotion.Reflection to correct this bug and #4918 ? Thanks. |
|
Please remember that you can always patch any parts of the toolchain and compile your own version for your internal use. |
That's simple in theory, but difficult in practice. It would mean generate updated NSwag.* nuget packages, push them to our internal artifact store and then find a way to make all our application builds use these new NSwag.* packages while minimizing the impact of the change so that we can revert back to the official version if/when it's finally updated. So yeah, not impossible but first let me see if begging @RicoSuter works... |
|
For those who are interested, I found a rather silly workaround, but it works. The only thing that needs to be upgraded is the <Target Name="NSwagWorkaround" AfterTargets="PostBuildEvent" Condition=" '$(Configuration)' == 'Debug' ">
<Copy DestinationFolder="$(OutDir)" SourceFiles="C:\PRJ\Namotion.Reflection\src\Namotion.Reflection\bin\Debug\netstandard2.0\Namotion.Reflection.dll" />
</Target>The target will overwrite the buggy DLL and make your error go away. I restrict it to the Debug build, but the choice is yours. This will enable you to resume your life until @RicoSuter or anyone else with superpowers decides to release a new version with the updated |
|
Does anyone here have the same rights are @RicoSuter and can that person just make an update of NSwag with the recent version of Namotion.Reflection? |
Hello,
I am trying to track down a problem when upgrading from NSwag 13 to NSwag 14. The error message I'm getting during the generation of the CSharp client using the post-build event:
is the following:
Now, I would love to know what type is causing the
GetGenericTypeDefinition()to trip up and throw an exception.This worked perfectly with NSwag 13.
For this, I first implemented a processor that narrows down the method on the controller:
This is added as follows:
Sadly, a close inspection did not reveal anything that narrowed down the problem. In fact, before the offending controller is reached, a lot of other controllers and methods with generic types are handled without issue.
Next, I defined a schema processor:
... which I then injected using:
This did not tell me more. Just before the exception occurs, it writes:
I don't see the connection between a Guid and a a generic type. And in the type being handled, a Guid doesn't even occur.
I noticed in the above stack trace that one of the methods is:
... so I changed the
SchemaProcimplementation as follows:The reasoning is that by calling the method that occurs in the stack trace myself, I could trigger the exception and investigate from there.
Sadly, that didn't work: the body of the above
catchis never executed.The only rational explanation is that the exception is thrown before
SchemaProc.Processis being called.This makes me throw my hands up in the air and ask for help on this forum. What else is there to do? The controllers and their return types are very complicated, and systematically removing types "until it works" will take more time than I have.
Is there some kind of trace flag I can set to have more detailed information?
The text was updated successfully, but these errors were encountered: