Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> Derived Models UpdateFromXXX method compile error when 'generate as nullable type' is false
 

Pages: 1 2
Bugs & Issues
Derived Models UpdateFromXXX method compile error when 'generate as nullable type' is false
Page:2/2 

  Print all messages in this thread  
Poster Message
TomDog
User



Location:
Wellington, New Zealand
Joined on:
25-Oct-2005 22:21:17
Posted:
570 posts
# Posted on: 04-Sep-2018 14:02:26.  
On my work machine I only need Microsoft.CodeAnalysis.dll and Microsoft.CodeAnalysis.Scripting.dll in the plugin directory to make it happen, on 3 other machines I needed that set I've given.

You could try grabbing a bunch of random assemblies from somewhere and see if that tips it over the edge for you.
Jeremy Thomas
VS 2017 C#, LLBLGen v5.4, Winforms, WPF and ASP.NET MVCLLBL & LinqPad
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38097 posts
# Posted on: 04-Sep-2018 14:21:15.  
The designer indeed loads the data in the background (using a task on a dispatch queue) and first does the plugins etc. and then the type converters. It could be that takes longer than anticipated, the form is shown and then the project is loaded (on the foreground thread) and things aren't ready.

(speculation as I can't repro it, but it looks like that's the situation you're running into). I can queue the project load into the same dispatch queue but then it loads slower than it does now, which is abit silly. The thing is that the language stuff for the editor takes a lot of time (relatively) to load, so queueing the project load after all that is noticable slower when double clicking (you'll look at the designer, empty and have to wait for 1-2 seconds before something happens).

Switching the order, so it first does type converters and then the rest would already solve things I think, however in theory it still can go wrong if there are many dlls in the type converter folder which cause exceptions so that task is slow and the project is then already loading...

We've now set the project to load at startup as a part of the initialization process of the designer and it's loaded in the background after the data needed is loaded, so it'll always be done after things are loaded properly.

This works OK and should solve your problem. I'll post a hotfix shortly so you can try it out.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38097 posts
# Posted on: 04-Sep-2018 14:33:37.  
Could you try the hotfix build for 5.4.3 we just uploaded, to see if that solves your problem?
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TomDog
User



Location:
Wellington, New Zealand
Joined on:
25-Oct-2005 22:21:17
Posted:
570 posts
# Posted on: 05-Sep-2018 06:52:41.  
Yep, got it in one!Laugh

Thanks for sorting.


Jeremy Thomas
VS 2017 C#, LLBLGen v5.4, Winforms, WPF and ASP.NET MVCLLBL & LinqPad
 
Top
Pages: 1 2  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.