Open kant2002 opened 2 years ago
The compiler tries to be tolerant to garbage input but not all codepaths do upfront validation to make sure we can abort compiling a problematic method before it puts the compiler into a state where we cannot back out.
Looks like here is a type that has a base type in an assembly that doesn't exist. We would be able to recover from that in some spots, but looks like this found a codepath that can't recover.
To troubleshoot, one could run the dependency viewer tool to see what triggered the need of this particular TypeMetadataNode. It may or may not be possible to back out there.
We can fix this if it's in a good spot, but there are some spots where the upfront validation would be so expensive (in terms of compilation throughput) that it's not worth it (e.g. I would not regress the compilation throughput by 5% just to fix compiling a particular app with broken references).
This particular library uses following pattern.
using extern alias gurobi90;
namespace Gurobi90;
public class GurobiSolver
{
readonly gurobi90::GRBEnv _gurobiEnvironment; // In case readonly make difference
IObservable<gurobi90::GRBExpr> _ev; // In case generics make a difference
GRBModel gurobi90::_grbModel;
}
gurobi90
is pointer to gurobi90.netstandard20
, similarly exists gurobi91
and others.
And then create a lot of similar constructs to different assemblies. Even if I do not like that pattern to provide backward compatibility, it is used with relatively consistency.
Technically I may want just better reporting, because it's not easy to find such spots in 3rd party libraries.
Depending your opinion of practicality of pursuing such cases I may create small repro if needed.
Take this branch to save you a bit of time setting up https://github.com/kant2002/flips/commit/9017e74418f87f6068b47e89c69ecbcf698d8fec
I assume linux-x64 does not matter
Note, I cannot find any reference to
gurobi90.netstandard20
, but instead of that filegurobi91.netstandard20.dll
in thebin/Release/net5.0/linux-x64/