I think it is great you are embracing linqpad - it is a great tool and TomDogs driver works well. Would like to see my SQL on the sql tab instead of dumped into my results though.

I have some add-on templates I put in LLBLGen so my generated code has everything needed to work with his driver. Works great.

Otis wrote:

Ok. What I initially want is first the driver, so it can be shipped with LinqPad's installer. I don't know what the unittests do exactly, do they test what meta-data is delivered?

Yes for the Schema Explorer population, I test that the counts of the fields and the navigators are the same between the Schema Explorer nodes and the entities and that the tooltips have the info I want in them.

Otis wrote:

We're currently busy with v3.5's beta and the docs overhaul, so I think we'll have to postpone this work for a couple of weeks. I'll see if I can get things set up quickly in the coming weeks so it can be wrapped up after v3.5 launches.

That will work out with me as I should have released version 2.1 of my driver by then, pending the resolution of these two issues: http://linqpad.uservoice.com/forums/18302-linqpad-feature-suggestions/suggestions/1893867-enable-linqpad-to-release-its-lock-on-a-referenced http://forums.oreilly.com/topic/72365-nullreferenceexception-executing-sql-against-llbl-driver/ Which are the two remaining pain points for me after which the driver will be 'feature complete' AFAIC. Though as Wayne Brantley alludes to I'd say the major pain point for a new user of the driver would be that you have to alter your code to get SQL output in the SQL translation tab.

Otis wrote:

When we've something working as a driver, I'll mail Joe to see whether the driver can be included in the linqpad installer as well (or at least added to their website).

He doesn't included 3rd party drivers in the installer but instead lists them here: http://www.linqpad.net/RichClient/DataContextDrivers.aspx

Looking at the EF built-in driver inside linqpad, I don't see how the SQL is obtained. It looks like LinqPad intercepts SQL statements somehow as it doesn't do anything inside the EF driver, e.g. it doesn't override the InitializeContext method. Maybe it does it somewhere else, not sure.

Looking at the pdf on linqpad's site, I conclude it's not really possible to create a general driver for all llblgen pro versions, unless everything is reflection based. Instead a driver per version (e.g. driver for v3.5) is much easier, as the ormsupportclasses can then be referenced from the driver.

To get myself up to speed with how things work I'll first try to create a bare-bones driver which works and then things are addable to that which add more features like tooltips and all the other stuff you already wrote code for.

(edit) Ok, I have a good idea how things connect with each other. Tomorrow or thursday (likely thursday) I'll start with your latest code and cut out everything that's not directly related to the driver and start from there. When things work (read: I can execute a query ), I'll create a codeplex project, upload the code and will contact you so you can be added as a developer.

For the SQL dumping, I think it's best to add a tracelistener in code, to the ORMPersistenceExecution tracer, and filter out any message that's not a query being executed. This then won't require events being bound nor extra code being generated.

I've released version 2.1 of my LLBLGen LINQPad Data Context Driver for LLBL versions 3.1 and 3.5.

New features include:

• When you switch the query language to SQL, LINQPad updates the Schema Explorer to show SQL column names rather than CLR property names
• Connection dialog unloads assemblies when it has closed down so they are no longer locked - this allows them to be rebuilt while LINQPad is still open
• Connection dialog includes a button to quickly add assemblies needed for the http://www.ormprofiler.com
• Includes this LINQPad Custom Visualizer This release is mainly to take advantage of new features in the Beta of LINQPad such as not locking assemblies and consequently it only works with the Beta. This will probably be the final release of this driver AFAIC it is now feature complete and also the Solutions Design guys are looking at creating their own driver (see posts above).

Otis wrote:

For the SQL dumping, I think it's best to add a tracelistener in code, to the ORMPersistenceExecution tracer, and filter out any message that's not a query being executed. This then won't require events being bound nor extra code being generated.

Yes of course!, I'm a bit annoyed I didn't think of that myself Even though it wouldn't give executable SQL it's great unobtrusive default behavior.

heh

Yes, it's not executable indeed. but that's a bit of a pain anyway.

I've started with the driver, and I think it's best if our driver is as simple as the EF driver in Linqpad, and we can add additional features (you added a lot!) later, or if people want them, they can use your code instead. E.g. adapter factories and the like... I don't see the necessity for that at the beginning.

I think tomorrow I'm done with the dialog and can move on to the real code. The main stuff will likely be borrowed from the WCF Data Services base class as it can handle both selfservicing and adapter code.

Otis wrote:

I've started with the driver, and I think it's best if our driver is as simple as the EF driver in Linqpad, and we can add additional features (you added a lot!) later, or if people want them, they can use your code instead. E.g. adapter factories and the like... I don't see the necessity for that at the beginning.

I expect I'm the only one using an adapter factory, which is due to a weird situation in our code base, and which hopefully we will not need soon - that was a huge pain to support. Some of the other stuff in the dialog like default settings has been redundant since the 'Create similar connection' feature was added to LINQPad.

Ok. I already wondered what all the input controls were for, as it's mainly a query tool.

Anyway.... I immediately ran into a weird issue with linqpad: when my connection dialog pops up, it's removed after a second (I use winforms), like I clicked cancel after 1 second. In the debugger however, it works OK, it stays up. I open it with ShowDialog of course. The beta build doesn't do this, however I'd like to have my driver work with the RTM as well.

Did you have the same problem or have seen things like this? No exception is thrown... No need to investigate if you haven't seen this before, I contacted Joe about this, but in case you've seen it yourself as well...

Ok good progress I now have a driver with dialog and a working getschema. No (harsh) reflection (it does use reflection, but to filter out properties, nothing fancy) Re-used a lot of code from the OData stuff. And while doing that ran into a subtle bug in that code so I fixed that as well in the OData library.

No fancy tooltips yet, just a list with entities, fields, pk fields and navigators.

I'll now move on to the real work, namely executing queries

I think I have a working driver tomorrow so I'll then check in the stuff on codeplex so you can have a look at this driver. It's nothing fancy, just gets the job done (well, schema producing at the moment that is ).

ok!

I've pushed the first repo online, I've added you as a developer to the project, you should have an email from codeplex. I'm using mercurial, so tortoisehg is required.

What works: - adapter + selfservicing - inheritance - inclusion of linqsupportclasses, ormsupportclasses, queryspec namespaces - custom member providers for entities. (so lazy loading isn't triggered on selfservicing) - SQL emitting using a trace listener.

not yet working: - queryspec - ormprofiler inclusion - inclusion of namespaces from entity assembly - grid navigation isn't properly implemented yet, so you'll get all the properties in grid navigation.

So if you compile the code and load the driver, you'll be able to use it with linq, in both adapter and selfservicing.

What's not there yet is proper headers on the files and a readme with credits etc. But we'll get there . Main point is that it works

Otis wrote:

ok!

So if you compile the code and load the driver, you'll be able to use it with linq, in both adapter and selfservicing.

What's not there yet is proper headers on the files and a readme with credits etc. But we'll get there . Main point is that it works

Great! So what's next?

I guess some house keeping first, we should probably get the HintPaths aligned, for instance you have <HintPath>..........\Program Files\LINQPad\Beta\LINQPad.exe</HintPath> while I have <HintPath>C:\Program Files\LINQPad\LINQPad.exe</HintPath> You: <HintPath>..........\Program Files\TestDriven.NET 3\NUnit\2.5\framework\nunit.framework.dll</HintPath> me: <HintPath>..\packages\NUnit.2.6.0.12054\lib\nunit.framework.dll</HintPath>

also I changed the PostBuildEvent <PostBuildEvent> Call DevDeploy4.bat Call DevDeploy.bat </PostBuildEvent>

I'll add a folder with the externals, including linqpad.exe. That should make things easier. It's otherwise a pain indeed.

I'll primary focus on the stuff that doesn't work yet as I described above. Should be done by today.

(edit)... I can't get these .bat files to work if I don't specify the complete path to them... the post build event always fails. sigh...

(edit) OK, added macro's. Now works (and portable ). I'll add workitems for things to do to the project so it'll be visible what has to be done, and I'll publish the project.

Otis wrote:

(edit)... I can't get these .bat files to work if I don't specify the complete path to them... the post build event always fails. sigh...

(edit) OK, added macro's. Now works (and portable )..

I had CopyToOutputDirectory on the .bat files.

A note about InitializeContextSelfServicing var selfServicingAssembly = DataContextDriver.LoadAssemblySafely(selfServicingAssemblyFilename); is unnecessary as you can get the assembly from object context.

var baseType = context.GetType().BaseType;
var selfServicingAssembly = baseType.Assembly;

TomDog wrote:

Otis wrote:

(edit)... I can't get these .bat files to work if I don't specify the complete path to them... the post build event always fails. sigh...

(edit) OK, added macro's. Now works (and portable )..

I had CopyToOutputDirectory on the .bat files.

Ah. Ok I added a macro, should work now.

Please Pull changes from repository to have things lined up. Place the files described in the text file in the Externals folder to make references work.

A note about InitializeContextSelfServicing var selfServicingAssembly = DataContextDriver.LoadAssemblySafely(selfServicingAssemblyFilename); is unnecessary as you can get the assembly from object context.

var baseType = context.GetType().BaseType;
var selfServicingAssembly = baseType.Assembly;

Good catch.

Will change these.

For the people interested: the project is visible here: http://llblgenlinqpad.codeplex.com

(Edit) Jeremy, you shouldn't feel obligated to participate, if you don't have the time, no worries, it's almost done anyway. If you want to help, all the better though

Otis wrote:

Jeremy, you shouldn't feel obligated to participate, if you don't have the time, no worries, it's almost done anyway. If you want to help, all the better though

Thanks, alas I don't have much time to spend on it code wise, though I can do a little testing - you'll see the issues I've raised.

Also in FilesToPlaceHere.txt you say - LINQPad.exe (build v2/4.40 or higher) - it has to be v2 only - at least while the driver is .net 2.

TomDog wrote:

Otis wrote:

Jeremy, you shouldn't feel obligated to participate, if you don't have the time, no worries, it's almost done anyway. If you want to help, all the better though

Thanks, alas I don't have much time to spend on it code wise, though I can do a little testing - you'll see the issues I've raised.

Good stuff, will try to fix them soon.

Also in FilesToPlaceHere.txt you say - LINQPad.exe (build v2/4.40 or higher) - it has to be v2 only - at least while the driver is .net 2.

of course. I've added an issue for this.

Thanks!

Released first RTM build: http://llblgenlinqpad.codeplex.com/

I currently have special templates that insert the hooks the old LinqPad driver needed and such. For the driver you have now, I can remove those hooks and extra code and simply use the driver provided?

Yes. Otherwise the usage description would contain a description of the templates . Though there's one caveat: the driver uses the trace output, so the queries aren't 1:1 copyable to a query tool.

Ok, despite all your hard work, I could not get it to work.

I opened LinqPad version 4.42.01 I clicked 'add connection' I clicked 'View more drivers...' I found LLBLGen 3.5 official release and clicked to download official driver (version 3.5.12.416).

I then added a new connection, pointed it to my DAL and my .config file.

I then tried to expand the connection in the tree on the left and received 'Error: Object reference not set to an instance of an object.'.

I tried to execute a query and it DID work...so it appears the tree on the left is just not working.

I still have the original 3.0 version of the driver (unofficial one) and it does expand on the left.

Thoughts?

no idea. It works here without problems. Also... without a stacktrace I can't help you.

It works here without problems

Ha! A true developer.

Well, there is no stack trace - as it just shows that error in linqpad beside the item. I tried it on several computers.

I will email you my DAL so you can see it or get a stack trace, etc...

Reproduced. Very odd. Will check.

With our tests, everything works, so there's little I can do other than 'assume it works' . Though we use the .net 3.5 build, and an older version so it might be something changed. We'll look into it.

It dies on: ForcePlaceLoanEntity's property: MasterPolicy. The relation mapped by that field/property is apparently null / not found.

Do you have a hidden navigator?

it crashes on line 198, in SchemaBuilder. You can check this as well, using the sourcecode from codeplex, build a debug build of the driver, and use that driver instead.

FWIW I've released Version 3.0 of my LLBLGen LINQPad Data Context Driver for LLBL versions 4.0, 4.1 and 4.2.

New features include:

• Ability to group the entities by schema and/or by table prefix.
• Ability to import connections from earlier LLBL version connections.
• The included LINQPad Custom Visualizers have been enhanced, in particular with the addition of the Entity Data Browser