Jump to content
How To Get A Custom Typed Data Context To Shadow Referenced The Custom Assembly?
26 replies to this topic
Posted 12 February 2012 - 12:58 AM
When I use the UniversalStaticDriver in your DataContextDriverDemo with a LINQtoSQL dll it isn't shadow referenced but when I use the built-in LINQtoSQLTyped Data Context Driver it is. Why is that?
Enable LinqPad to release its lock on a referenced DLL
Posted 12 February 2012 - 05:33 PM
Download the latest beta - this should be fixed.
Posted 23 February 2012 - 01:08 AM
On a related matter when shadow assemblies is turned on GetSchema is called withAppDomain.CurrentDomain.BaseDirectory set to the linqpad directory rather than the directory of the custom assembly like it is when shadow assemblies is off, and this is causing a problem for me.
Shouldn't the BaseDirectory always be the custom assembly directory either way?
Posted 24 February 2012 - 01:10 AM
Shadow loading cannot work if the application base directory is the custom assembly directory, because the CLR loads (and locks) assemblies automatically if they're in the base directory - so LINQPad has no chance to intervene.
Posted 24 February 2012 - 01:45 AM
But shadow loading isn't used or available during GetSchema is it?
Edited by Jeremy Thomas, 24 February 2012 - 01:46 AM.
Posted 24 February 2012 - 05:16 AM
With GetSchema, LINQPad doesn't need to shadow load because it can destroy the appdomain right after creating it. That can't happen with queries, because the user might display the results to a grid or a custom visualizer which dies immediately upon destroying the domain.
Posted 24 February 2012 - 11:15 PM
That's kind of my point, because shadow loading isn't used during GetSchemathe application base directory can be the custom assembly directory as it is when
shadow loading is turned off. Obviously the calls to InitializeContext etc when the custom assembly is shadow loaded it can't be.
Edited by Jeremy Thomas, 24 February 2012 - 11:15 PM.
Posted 06 March 2012 - 10:30 PM
There's a new beta that now disables shadow loading during calls to GetSchema.
Let me know how you get on.
Posted 07 March 2012 - 01:39 AM
Not so good,
GetSchema now works OK, but now I'm getting missing method exceptions during the execution of queries.
e.g. Method not found: 'Void AW.Helper.LLBL.SQLTraceEventArgs..ctor(SD.LLBLGen.Pro.ORMSupportClasses.IQuery)'.
nothing in %localappdata%\linqpad\logs\
Works fine with shadowing off or with shadowing on in the previous beta - version .04
Posted 08 March 2012 - 01:39 AM
This might be hard to track down.
I've just done another build that might fix it. It also lets you disable shadow loading for your driver via the header.xml file:
Posted 08 March 2012 - 02:00 AM
No v.38.06 still has the same problem. And while I think the AllowAssemblyShadowing setting is a good idea I have no interest in using it as you probably understand.
Yes would be hard to debug since you can't step through it with Shadowing on.
Edited by Jeremy Thomas, 08 March 2012 - 02:04 AM.
Posted 08 March 2012 - 02:32 AM
The old build failed to shadow some assemblies - that's probably why it worked.
I think you'll have to switch off shadowing via the header.xml option - it seems something in LLBLGEN is taking an aversion to it.
I've created various chains of dependencies and tried to reproduce the problem but I can't.
With shadowing disabled, you'll still be able to alt+tab to VS and rebuild assemblies. LINQPad monitors the currently active process and if it's VS, it will kill the appdomain of a non-running query that's holding assembly locks.
Posted 08 March 2012 - 03:00 AM
Looking in process explorer the current build has the LLBLGEN assemblies loaded twice - shadowed and non shadowed (which I guess is causing the problem), while the .04 version had them just loaded once shadowed.
Bizarrely my old 2.0 driver runs fine and the LLBLGEN assemblies are shadowed.
If you want to repro the problem open the LINQPad.sln from https://rapiddevbook...n/LLBL Pro v3.1
OK great - so I don't really need shadowing - good to know.
Edited by Jeremy Thomas, 08 March 2012 - 03:01 AM.
Posted 08 March 2012 - 04:49 AM
Do you have it as a zip file or something?
I get the .sln file itself from that URI - not the code
Posted 08 March 2012 - 03:04 PM
Opps - I should of made it clear to use TortoiseSVN to get that code using the url.
Alternatively a zip file can be downloaded from http://rapiddevbookc...list/changesets
Posted 18 March 2012 - 01:58 AM
Even more bizarre, I tried it on a fresh VM and I don't get the error running the query but I do get this error
System.ArgumentException occurred Message=Object type cannot be converted to target type. Source=LINQPad StackTrace: at LINQPad.UI.SchemaTreeInternal.StaticSchemaNode.SchemaRetriever.GetSchema(Repository r) at LINQPad.UI.SchemaTreeInternal.StaticSchemaNode.GetNodes() InnerException:on the two test model assemblies included in the source, but not on another model assembly
Also on the 2 machines with the trouble I tried creating new connections to the same model assemblies in different paths and that worked ok.
Edited by Jeremy Thomas, 18 March 2012 - 03:22 AM.
Posted 20 March 2012 - 02:05 AM
Found the culprit - the model assemblies were in the same directory as the driver- AW.LLBLGen.DataContextDriver.dll - I took the driver dll out and the SchemaTree worked OK.
Posted 20 March 2012 - 04:08 AM
The problem is caused by SD.LLBLGen.Pro.ORMSupportClasses.NET20.DLL being loaded twice, once as a shadow and once directly from the driver directory, in the older beta's it was only loaded once as a shadow.
This only applies to the adapter variant of LLBL where the driver has to load a second assembly.
Posted 21 March 2012 - 04:03 AM
I think I found the problem, the driver assembly, AW.LLBLGen.DataContextDriver.dll is dependent on a number of other assemblies - 2 of which, AW.Helper.LLBL.dll and AW.Winforms.Helpers.LLBL.dll, depend upon SD.LLBLGen.Pro.ORMSupportClasses.NET20.DLL.
It seems if those 2 dll's are present in the Typed Data Context directory they get shadow loaded and so SD.LLBLGen.Pro.ORMSupportClasses.NET20.DLL is only loaded once. But normally they aren't so in the later LinqPad beta's they are loaded non-shadowed which causes SD.LLBLGen.Pro.ORMSupportClasses.NET20.DL to be loaded again but from the driver directory.
Has ShadowAssemblyManager.IsShadowable changed in the later beta's?
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users