To reproduce this issue:
- Download and unzip console.zip
- Open
Program.cs and change line 45 to have the full path to where you unzipped the content LoadFromAssemblyPath(@"p:\temp\console\Microsoft.VisualBasic.dll");
- Execute
dotnet run
The expected output here is
Public member 'G' on type 'A' not found.
The actual output though is
Value cannot be null. (Parameter 'format')
The code here is a simplified example of Visual Basic late binding (essentially dynamic). The expectation is the late binding fails here but with an actionable error message. What happens in this case though is that the Microsoft.VisualBasic.dll is unable to load embedded resources and as a result ends up passing null to string.Format and generating the above exception.
One key thing to note is this repro is using the desktop Microsoft.VisualBasic.dll, not the .NET Core version. At the same time this seems like a fairly straight forward resource load and it's surprising that this does not work.
The context for this issue is the pattern comes up a bit in the Visual Basic Compiler test suites. The tests were initially written for desktop and when we ported them to run on Core we kept the desktop reference to Microsoft.VisualBasic (it worked hence why update). In attempting to move to netcoreapp3.1 though this behavior suddenly started changing and I'm attempting to understand why before we go through the process of re-engineering these tests.
To reproduce this issue:
Program.csand change line 45 to have the full path to where you unzipped the contentLoadFromAssemblyPath(@"p:\temp\console\Microsoft.VisualBasic.dll");dotnet runThe expected output here is
The actual output though is
The code here is a simplified example of Visual Basic late binding (essentially
dynamic). The expectation is the late binding fails here but with an actionable error message. What happens in this case though is that theMicrosoft.VisualBasic.dllis unable to load embedded resources and as a result ends up passingnulltostring.Formatand generating the above exception.One key thing to note is this repro is using the desktop
Microsoft.VisualBasic.dll, not the .NET Core version. At the same time this seems like a fairly straight forward resource load and it's surprising that this does not work.The context for this issue is the pattern comes up a bit in the Visual Basic Compiler test suites. The tests were initially written for desktop and when we ported them to run on Core we kept the desktop reference to Microsoft.VisualBasic (it worked hence why update). In attempting to move to netcoreapp3.1 though this behavior suddenly started changing and I'm attempting to understand why before we go through the process of re-engineering these tests.