0

I've tried everything in my knowledge to fix this but as I can't here I am asking for help.

Basically I have an issue with some VB.NET code that throws a TypeLoadException. This is code that was written ages ago and has always worked without a problem.

  • If the code is built in VS2013 it fails.
  • If the code is built in VS2017 it works.
  • If the project is built in VS2017 and opened in VS2013 (without rebuilding) is works. After a rebuild, problem comes back.

I converted the code to C# and it works even if built in VS2013.

The only thing that I have done recently is to clean up temporary files in my system (Win7 64) so I am thinking maybe something happened due to this but my knowledge of Visual Studio isn't sufficient to understand what could be happening.

Before I try to repair VS2013 wanted to know if this happened to someone else and if a solution was found.

To add to the confusion the problem exists only with generic classes!

I have created sample code to run in a console application to replicate the problem and here it is:

Imports System.Runtime.CompilerServices

Module Module1

    Sub Main()

        Dim ng As New NonGenericClass
        ng.WriteToLog() ' Works

        Dim g = New GenericClass(Of IO.FileInfo)
        g.WriteToLog() ' Fails with TypeLoadException

    End Sub

End Module

Public Class GenericClass(Of T)
    Implements IHasLogger

    Public Sub WriteToLog()
        Log.Info("some message")
    End Sub


End Class

Public Class NonGenericClass
    Implements IHasLogger

    Public Sub WriteToLog()
        Log.Info("some message")
    End Sub

End Class

Public Interface ILogger

    Sub Info(message As String)

End Interface

Public Class Logger
    Implements ILogger

    Public Sub Info(message As String) Implements ILogger.Info
        Debug.Print(message)
    End Sub
End Class

Public Interface IHasLogger



End Interface

Public Module LoggerMixin

    <Extension>
    Public Function Log(Of T As IHasLogger)(this As T) As ILogger
        Return New Logger
    End Function


End Module

I assume the issue is with the visual basic compiler at this point as c# has no problems.

Using VS2017 is not an option because the project uses controls from DevExpress and I don't have a license for a version compatible with VS2017.

Thanks for your help.

-- UPDATE -- (Exception information)

System.TypeLoadException: Could not load type 'ConsoleApplication1.GenericClass1' from assembly 'ConsoleApplication13, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. at ConsoleApplication1.GenericClass1.WriteToLog() at ConsoleApplication1.Module1.Main() in E:\Projects\Temp\ConsoleApplication13\ConsoleApplication13\Module1.vb:line 13

-- FIX --

As suggested by TnTinMn using Me.Log (as opposed to just Log) allows to circumvent the problem. For now I will go with that. And now that I come to think of it in C# you would need to call this.Log which is equivalent to Me.Log in VB.NET so my comments about it working in C# don't really apply.

Thanks to all for the help. If anyone knows or finds out why this happens I would still like to know :-)

djv
  • 15,168
  • 7
  • 48
  • 72
Simo Ferrari
  • 87
  • 1
  • 6
  • addressing TypeLoad exception, do you have static constructors? I seem to get that error mostly when an exception is thrown in a static constructor – T McKeown Feb 13 '18 at 19:57
  • And can you include a stack trace? That might help to narrow down the issue. Also, check that the projects are targeting the same versions of the .Net framework on each build. – Chris Dunaway Feb 13 '18 at 20:10
  • There are no static contstructors. To isolate the issue I replicated the error in a simple console application (using the code I posted) with no references other than default system ones. Error occurs with any version of .net framework. I updated my question with the exception info. – Simo Ferrari Feb 13 '18 at 20:20
  • I can verify that your example raises the TypeLoad exception in VS2013. I found extension method usage strange (assuming that `Log.Info` is a reference to the extension as indicated by the IDE) and was surprised that it compiled as no "this" argument is included. If I add a "Me" argument, it raises an issue that Log can not be indexed. If I fully qualify it as `LoggerMixin.Log(Me)`, then no errors are raised. – TnTinMn Feb 13 '18 at 20:56
  • Ow wow... I would have never thought you would be able to replicate this because it worked fine for me for ages and cannot understand why now it's failing. Log.Info indeed points to the extension and for that reason the "this" argument doesn't need to be passed explicitly. If you build with VS2017 which uses more recent compilers you won't get the exception (VB.NET & C#) while the same code written in C# will build and run fine also in VS2013. Can't get my head around this. – Simo Ferrari Feb 13 '18 at 21:13
  • The bulb just turned on, and I realized that the compiler is extending the implicit "Me" on `Log.Info`. Duh! With that said, qualify it as `Me.Log.Info` allows the code to function as well. So there must be a glitch in the 2013 VB compiler that loses track of the implied reference somewhere with the extension method. – TnTinMn Feb 13 '18 at 21:28
  • Yes ;-) There's definitely something wrong with the VB compiler but 1) was working before (I checked the version history of the code) and 2) it works with the non generic class. I can change the extension method to Function Log(this As IHasLogger) and it will work, but I loose a vital piece of information which is the type of class containing the method that is calling the extension method (in inheritance scenarios). By changing the method "this.GetType" will always give me the type of the last class on the inheritance tree which is not what I wanted: GetType(T) – Simo Ferrari Feb 13 '18 at 21:41
  • "...but I loose a vital piece of information" - Why not just replace `Log.Info` with `Me.Log.Info`? Simple search and replace, and it will keep VS2013 happy without changing the intent of the code? – TnTinMn Feb 13 '18 at 21:49
  • Yes I might end up doing that.. probably the best solution at this point in time ;-) – Simo Ferrari Feb 13 '18 at 21:57

0 Answers0