Avoid DevArt assembly collisions with user query references
Not sure how viable this is, but I spent all day today trying to find the source of an assembly collision that prevented some code compiling in Linqpad, only to find that the stray version originated from Linqpad itself!
If possible, I suggest you avoid injecting Devart.Data / Devart.Data.Oracle assemblies into the query app domain if later versions of those assemblies are already being (directly) referenced by the query. Otherwise you create assembly binding issues for the compiler.
Failing that, Linqpad.config should probably have some binding redirects for DevArt.Data / DevArt.Data.Oracle
(Linqpad 4.55 references DevArt.Data.Oracle 7.9.333.0, my query references assemblies which use 8.4.379.0)
Failing that, perhaps a big fat warning somewhere, rather than just bubble up the generic build error.
Piers Williams
shared this idea
-
Piers Williams
commented
I should note this only appears to be a problem if your query uses the DevArt dotConnect drivers *and* an IQ connection/DataContext in your query at the same time. Which of course I was.