-1

We have our own tool to create documentation of our web api. It reads the /// comments and creates the documentation from them. But we have one weird issue with it: The expression typeof(HttpResponseMessage) weirdly evaluates to null. Why this happens?

Just to clarify: When we read the assemblies at runtime and create documenation, we have HttpResponseMessage in MethodInfo.ReturnType of some API methods. This one works without problem. But when we try to check if the type is HttpResponseMessage, we do if(methodInfo.ReturnType == typeof(HttpResponseMessage) and here the right side of this if always evaluates to null. When I run it in Visual Studio debugger and write typeof(HttpResponseMessage) to Watch window, it evaluates to null too.

(The type is defined in System.Net.Http.)

Here is the screenshot from debugger showing that this is real: enter image description here

The sceenshot clearly shows that typeof returns null both in program and in Watch window, but parameterType variable actually points to the type object of that class. It is a normal Win32 console application.

Al Kepp
  • 5,831
  • 2
  • 28
  • 48
  • 2
    Please provide a [mcve]. I would be very surprised to see `typeof(HttpResponseMessage)` actually return null. It's entirely possible that there are debugger issues going on here though - it would be better if your example assigned the value to a variable, and compared that with null. – Jon Skeet Jul 18 '18 at 13:17
  • `typeof(HttpResponseMessage)` returning null is unfortunately harder to believe than user error. I'd like to see a [mcve] demonstrating this issue. AFAIK, `typeof(x)` can only return null if the class in question is a dynamic class created in memory. That isn't the case here. –  Jul 18 '18 at 13:33
  • [Further reading: `typeof(T)` may return null](https://stackoverflow.com/questions/6497570/typeoft-may-return-null) –  Jul 18 '18 at 13:36
  • I added the screenshot from the VS debugger. – Al Kepp Jul 18 '18 at 14:24
  • @Amy: I am not sure if your link applies to this case, because this is neither generic nor dynamically generated type. Or am I wrong? – Al Kepp Jul 18 '18 at 14:28
  • 1
    @AlKepp The takeaway is that `typeof` only works for types that exist at compile-time. Types created at runtime don't apply. I'm aware this doesn't apply in your case, I said as much in my first comment. –  Jul 18 '18 at 14:30
  • How are you reading the assemblies? Are you doing something weird like loading some with `ReflectionOnly`? – Damien_The_Unbeliever Jul 18 '18 at 14:55
  • Will other types from the same assembly behave similarly, for example, will `typeof(System.Net.Http.HttpContent)` also look like null? Do you have several versions of this assembly? You still need to give us a full reproducible sample. With [this tio.run code](https://tio.run/##hYwxDsIwDEX3nMJjMpALoE5dGCgDDMzBGBQU4qg2lSrUs4cIde/yh/efHsoOBWsVDRoRMAUR6M3XrGDieIchxGxdg1MYQaEDnQvxw15mUXr7E6k/qJb/nEkKZ6GBRMKT3N6sVt8oJ/LXMSodYybbSh3kT0qbkuXbi1DdptzOxSy1/gA), everything seems normal. – Jeppe Stig Nielsen Jul 18 '18 at 15:09
  • Again, a screenshot from a debugger isn't as useful as a [mcve]. There's a *lot* that can happen in the Watch window that doesn't behave the same way elsewhere, and if we can't reproduce it that makes it a lot harder to help too. – Jon Skeet Jul 18 '18 at 17:46

1 Answers1

0

It looks like I hit a strange edge case here. The typeof operator returns null on types imported from System.Net.Http assembly which is referenced in the project, but the file is in C:\Program Files\Reference Assemblies which I think is not used to search assemblies in runtime. And the reference is set as CopyLocal=false. So it seems the issue is caused by the type being available at compile time, but not at run time. I would expect an exception if a type is missing and couldn't be loaded at runtime, but wow this operator just throws nulls silently.

I will test tomorrow if I can fix the issue by correcting this ill reference.

Al Kepp
  • 5,831
  • 2
  • 28
  • 48