Home

Deja Vu - Cannot open LinqPad without every aspect of referencing DLL's broken

So I reference my project's dll, I add a link to the project's dll.config with the connection strings.
Then, no matter what, linqpad asks for references to dll's in my bin folder.
Or maybe its looking at my packages config? who knows? The items its asking for are listed there...
Or is it examining the dll entries in my web.config or the dll.config in the bin folder? Maybe Joe knows!
Under F4/Additional Namespace Imports, all the namespaces in my project seem to be there. But the Assemblies and Namespaces boxes are EMPTY! Is that good?
I click 'Set as default for new queries', the dialog says 'DONE!' but nothing changes: I still get errors on all the dll's in the project folder, one after the other.
Should I click 'Cleanup...'? What's dirty that needs cleaning?
On the App.Config tab, I could set the global location for app.config. Maybe this is the linqpad app.config? I guess 'maybe'.
On the advanced tab I can 'copy all non-framework references to a folder'. What would this accomplish? Where is the connecting principle between that folder and any other place in the universe?
The Additional References tab LOOKS interesting, but why would I add references to dll's that are already referenced by my project's dll? Won't linqpad already know about those references and follow them to the dll's my project dll references?
If I add NuGet packages, are they added to my project or to linqpad? where are they stored?
IF someone actually wrote linqpad (rather than finding it under a linqpad) maybe they would be so kind as to end this multi-year guessing game and provide 'A Comprehensive Guide to Adding References to LinqPad?
Of course, probably, someone will scan these questions and provide the first answer that comes to their mind when reading the first question that seems to be about something they think they know about.
Then I'd have to write all these one at a time in many posts. Would that work better, I mean without context, things are less meaningful. Maybe that would help.
Maybe just three paragraphs on what references are necessary and how to add them to Linqpad. That would be a start. after all, I've been trying to use this program for more than three years and everytime I have to go through this guessing game for a day and a half until I stumble into some combination of attempts that works. Just give me a paragraph for each year!, I mean I paid for it a couple times.
please!!! geeze!

Comments

  • Oh, I like this one too!
    After adding hard references to linqpad for System.EnterpriseServices.dll, which was reported by linqpad as missing, I also got an error for System.EnterpriseServices.Wrapper.dll. This is a windows/microsoft.Net/framework assembly that is automagically loaded by the framework. The era of this error is 2012 in stackoverflow. Adding the wrapper to linqpad reports it as 'not an assembly'. I'm on VS 2015 and .net 4.6.
  • edited September 2016
    I guess the crux of your main question is:
    Why would I add references to dll's that are already referenced by my project's dll?
    The answer depends on what kind of error you're getting.

    There are two possibilities. One is that you're getting error CS0012. In which case, the C# compiler is to blame for needing to add the extra references:
    https://msdn.microsoft.com/en-us/library/x0dz51e1.aspx

    You'll see the same behavior in Visual Studio. Having said that, LINQPad includes a feature whereby it detects that error and parses it, and then offers to add the necessary references when you press F4 (or automatically from then on, if you choose.) That feature was to designed only with Framework assemblies in mind, however there's no reason why I couldn't make it work with your own assemblies, too. I will add this feature to the next build.

    The other possibility is that LINQPad cannot resolve the assembly at runtime, in which case you'll get some other kind of error. In order to diagnose this, you'll need to say exactly what error you're getting.

    To answer to your other questions:
    • The app.config page in Query Properties refers to the query, not LINQPad itself. Config files have little bearing on how LINQPad references or resolves assemblies.
    • 'Set as default for new queries' sets the default for new queries that you create. It doesn't change the current query.
    • The Cleanup hyperlink removes namespace imports that don't exist in the assemblies that you've referenced.
    • The advanced option 'copy all non-framework references to a single folder' is there to support scenarios such as MEF, which requires that all assemblies are in one place in order to 'discover' them.
  • ok, thanks for this. I'll dig up the error.
  • Now, an easy one:
    When I click the 'cleanup' button (now with high expectations), I get a tall, narrow dialog that does not show the bottom of the dialog, and whose 'x' will not accept a click. the bottom of the dialog extends below the bottom of the screen and the top will not allow moving up above the top of the screen and there are no scroll bars (an obvious solution). I'm guessing there is an operative button below the bottom of the screen. My monitor is 1920x1200. The only way out is Task Manager.
  • But also, your few paragraphs were a big help in clearing up some fundamental ambiguities. You have my sincere gratitude.
Sign In or Register to comment.