O'Reilly Forums: How To Get A Custom Typed Data Context To Shadow Referenced The Custom Assembly? - O'Reilly Forums

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

How To Get A Custom Typed Data Context To Shadow Referenced The Custom Assembly? Rate Topic: -----

#1 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • 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
0

#2 User is offline   JoeAlbahari 

  • Super Veteran Member
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 529
  • Joined: 15-February 08
  • Gender:Male
  • Location:Perth, Australia

Posted 12 February 2012 - 05:33 PM

Download the latest beta - this should be fixed.

Cheers
Joe
0

#3 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 13 February 2012 - 03:24 AM

Yes it is - Much thanks!

Cheers
Jeremy
0

#4 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • 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?
0

#5 User is offline   JoeAlbahari 

  • Super Veteran Member
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 529
  • Joined: 15-February 08
  • 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.
0

#6 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 24 February 2012 - 01:45 AM

 JoeAlbahari, on 24 February 2012 - 01:10 AM, said:

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?

This post has been edited by Jeremy Thomas: 24 February 2012 - 01:46 AM

0

#7 User is offline   JoeAlbahari 

  • Super Veteran Member
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 529
  • Joined: 15-February 08
  • 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.
0

#8 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • 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.

This post has been edited by Jeremy Thomas: 24 February 2012 - 11:15 PM

0

#9 User is offline   JoeAlbahari 

  • Super Veteran Member
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 529
  • Joined: 15-February 08
  • 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
0

#10 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 07 March 2012 - 01:39 AM

 JoeAlbahari, on 06 March 2012 - 10:30 PM, said:

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
0

#11 User is offline   JoeAlbahari 

  • Super Veteran Member
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 529
  • Joined: 15-February 08
  • 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
0

#12 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 08 March 2012 - 02:00 AM

 JoeAlbahari, on 08 March 2012 - 01:39 AM, said:

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.

This post has been edited by Jeremy Thomas: 08 March 2012 - 02:04 AM

0

#13 User is offline   JoeAlbahari 

  • Super Veteran Member
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 529
  • Joined: 15-February 08
  • 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.
0

#14 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 08 March 2012 - 03:00 AM

 JoeAlbahari, on 08 March 2012 - 02:32 AM, said:

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://rapiddevbookcode.svn.codeplex.com/svn/LLBL Pro v3.1

 JoeAlbahari, on 08 March 2012 - 02:32 AM, said:

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.

This post has been edited by Jeremy Thomas: 08 March 2012 - 03:01 AM

0

#15 User is offline   JoeAlbahari 

  • Super Veteran Member
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 529
  • Joined: 15-February 08
  • 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
0

#16 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 08 March 2012 - 03:04 PM

 JoeAlbahari, on 08 March 2012 - 04:49 AM, said:

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
0

#17 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • 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.

This post has been edited by Jeremy Thomas: 18 March 2012 - 03:22 AM

0

#18 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 20 March 2012 - 02:05 AM

 Jeremy Thomas, on 18 March 2012 - 01:58 AM, said:

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

#19 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 20 March 2012 - 04:08 AM

 JoeAlbahari, on 08 March 2012 - 02:32 AM, said:

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

#20 User is offline   Jeremy Thomas 

  • Active Member
  • PipPip
  • Group: Members
  • Posts: 35
  • Joined: 18-June 09
  • Gender:Male
  • Location:Wellington, New Zealand

Posted 21 March 2012 - 04:03 AM

 Jeremy Thomas, on 20 March 2012 - 04:08 AM, said:

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

Share this topic:


  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users