I suggest you ...

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.

1 vote
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Piers Williams shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    1 comment

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Piers Williams commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base