LINQPad is ignoring an assembly reference

Question

I've added a reference (NuGet package) as described here, but LINQPad isn't recognizing it.

Here's my query:

Sub Main
    Dim iImportList As New List(Of Integer)
    Dim oSearch As New List(Of Match)

    For i = 1 To 226
        iImportList.Add(i)
    Next

    Using oDb As Db.Context = Db.Context.Create
      oSearch.Add(From A In oDb.Applicants
                  Join C In oDb.Customers On
                      A.FirstName Equals C.FirstName And
                      A.LastName Equals C.LastName And
                      A.Ssn Equals C.Ssn And
                      A.Dob Equals C.Dob
                  Where
                      C.TotalBalance > 0 AndAlso
                      A.Aln.StartsWith(DateTime.Now.Year) AndAlso
                      iImportList.Contains(C.ImportId)
                  Select
                      New Match With {
                          .ApplicantId = A.ApplicantId,
                          .CustomerId = C.CustomerId,
                          .MatchLevel = Db.Match.MatchLevels.FirstLastSsnDob
                      })
    End Using
End Sub

Class Match
    Public Property ApplicantId As Integer
    Public Property CustomerId As Integer
    Public Property MatchLevel As Db.Match.MatchLevels
End Class

...and here's the result:

As we can see, LINQPad is ignoring my SQLCE reference and is using the SQL reference instead. (The System.Data reference is apparently internal to LINQPad; I didn't add it.)

How can I get LINQPad to do the opposite—ignore the SQL reference and use the SQLCE reference as intended?

The type of connection is only determined by what happens in `Db.Context.Create`. — Gert Arnold, Nov 04 '18 at 10:30
@GertArnold ~ That makes sense, but the `System.Data.SqlServerCe` assembly is sitting right alongside `Db.dll`, the assembly which contains my context. The application runs fine with Visual Studio or at a command prompt. I'm not sure what else to do to get LINQPad to stop defaulting to `System.Data` for creating the connection. (I'm using `System.Data.SqlServerCe.SqlCeConnectionStringBuilder` to build the string.) — InteXX, Nov 05 '18 at 05:36

score 0 · Answer 1 · answered Nov 16 '18 at 01:01

0

It sounds like a runtime assembly resolution problem - something is expecting System.Data.SqlServerCe.dll to be in the output folder.

Press F4 for query properties, click the Advanced tab, and select the option to copy all non-framework references to a single folder. That will ensure that the runtime assemblies will be discoverable.

answered Nov 16 '18 at 01:01

Joe Albahari

30,118
7
80
91

That didn't work, I'm afraid. `"copy all non-framework references to a single folder"` Which folder would that be? I'd like to verify that everything got copied correctly. – InteXX Nov 16 '18 at 02:23
Are you able to reproduce it? I can send you a sample project if you like. – InteXX Nov 16 '18 at 08:11
No, I can't reproduce it. I don't know where Db.Context comes from. You can find the output folder with a query like typeof (somethingInDb.dll).Assembly.Location – Joe Albahari Nov 17 '18 at 09:42
OK, got it. See my comment to @erikej above. The verbiage in the connection properties dialog implies that the only reason to point to the `App.config` file is for the connection string. But there're other configuration entries there that are required, whether one is building the connection string at runtime or not. – InteXX Nov 17 '18 at 23:44
@JoeAlbahari Agree, the app.config path is often required for other EF6 configuration entries – ErikEJ Nov 18 '18 at 09:25

score 0 · Accepted Answer · answered Nov 17 '18 at 16:52

0

Just use the EF DbContext connection dialog to hook up your DbContext, works like a charm.

answered Nov 17 '18 at 16:52

ErikEJ

40,951
5
75
115

Pardon me, I should have added another screenshot to my question. That's exactly what I'm doing. I'm working on a repro project, I should have it ready soon. – InteXX Nov 17 '18 at 20:28
OK, I figured it out while building up the repro project. I wasn't including my `App.config` location in the LINQPad connection's properties. At first I didn't think I had to, since I'm building my connection string at runtime, but I'd forgotten about the other necessary configuration entries there. Once I added the location, it sailed right through. Thanks! – InteXX Nov 17 '18 at 23:29

LINQPad is ignoring an assembly reference

2 Answers2