Jump to content


Photo
- - - - -

How To Get A Custom Typed Data Context To Shadow Referenced The Custom Assembly?


  • Please log in to reply
26 replies to this topic

#1 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

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?
(using 2.38.01)

Enable LinqPad to release its lock on a referenced DLL

#2 JoeAlbahari

JoeAlbahari

    Super Veteran Member

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 529 posts
  • Gender:Male
  • Location:Perth, Australia

Posted 12 February 2012 - 05:33 PM

Download the latest beta - this should be fixed.

Cheers
Joe

#3 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 13 February 2012 - 03:24 AM

Yes it is - Much thanks!

Cheers
Jeremy

#4 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

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?

#5 JoeAlbahari

JoeAlbahari

    Super Veteran Member

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 529 posts
  • Gender:Male
  • Location:Perth, Australia

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.

#6 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 24 February 2012 - 01:45 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.

But shadow loading isn't used or available during GetSchema is it?

Edited by Jeremy Thomas, 24 February 2012 - 01:46 AM.


#7 JoeAlbahari

JoeAlbahari

    Super Veteran Member

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 529 posts
  • Gender:Male
  • Location:Perth, Australia

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.

#8 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 24 February 2012 - 11:15 PM

That's kind of my point, because shadow loading isn't used during GetSchema

the 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.


#9 JoeAlbahari

JoeAlbahari

    Super Veteran Member

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 529 posts
  • Gender:Male
  • Location:Perth, Australia

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.

Cheers
Joe

#10 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 07 March 2012 - 01:39 AM

There's a new beta that now disables shadow loading during calls to GetSchema.

Let me know how you get on.

Cheers
Joe

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

Cheers
Jeremy

#11 JoeAlbahari

JoeAlbahari

    Super Veteran Member

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 529 posts
  • Gender:Male
  • Location:Perth, Australia

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:

<AllowAssemblyShadowing>false</AllowAssemblyShadowing>

Joe

#12 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 08 March 2012 - 02:00 AM

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:

<AllowAssemblyShadowing>false</AllowAssemblyShadowing>

Joe

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.


#13 JoeAlbahari

JoeAlbahari

    Super Veteran Member

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 529 posts
  • Gender:Male
  • Location:Perth, Australia

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.

#14 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 08 March 2012 - 03:00 AM

The old build failed to shadow some assemblies - that's probably why it worked.

I've created various chains of dependencies and tried to reproduce the problem but I can't.


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

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.

OK great - so I don't really need shadowing - good to know.

Edited by Jeremy Thomas, 08 March 2012 - 03:01 AM.


#15 JoeAlbahari

JoeAlbahari

    Super Veteran Member

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 529 posts
  • Gender:Male
  • Location:Perth, Australia

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

#16 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 08 March 2012 - 03:04 PM

Do you have it as a zip file or something?

I get the .sln file itself from that URI - not the code

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

#17 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

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.


#18 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 20 March 2012 - 02:05 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.

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.

#19 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 20 March 2012 - 04:08 AM

The old build failed to shadow some assemblies - that's probably why it worked.

I've created various chains of dependencies and tried to reproduce the problem but I can't.

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.

#20 Jeremy Thomas

Jeremy Thomas

    Active Member

  • Members
  • PipPip
  • 35 posts
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 21 March 2012 - 04:03 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.

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