ORM Profiler

Posts   
 
    
JSobell
User
Posts: 145
Joined: 07-Jan-2006
# Posted on: 18-Jan-2018 10:27:30   

I'm buggered if I can get anything to register on the ORM profiler display, and I can't see anything amiss. I'm using .Net 4.7 with v5.3 LLBLGen, and I start in my Main() with


            var tracer = InterceptorCore.Initialize("Engage App");
            if (tracer)
                _logger.Info("LLBLGen Profiler running");

It's using the standard LLBLGen 5.3.1 packages, and my calls are wrapped in using:


    public class Database:LinqMetaData, IDisposable
    {
        public Database(): base(new DataAccessAdapter(RuntimeConfiguration.GetConnectionString(DataAccessAdapter.ConnectionStringKeyName)))
        {
        }

        public void Dispose()
        {
            AdapterToUse.Dispose();
        }
    }

e.g.


 using (var db = new Database())
            {
                var firstRow = db.Streamrow
                    .WithPath(t => t.Prefetch(u => u.Stream))
                    .Single(s => s.Stream.Name == streamname && s.Idx == 0);
            }

If I run the app without the profiler, I can see errors reported as there's nothing listening on the port, and when I run the profiler the errors are avoided so it's obviously talking to something.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 18-Jan-2018 11:14:29   

You by accident ran a netstandard / .net core build ? The profiler only works on .net full

Frans Bouma | Lead developer LLBLGen Pro
JSobell
User
Posts: 145
Joined: 07-Jan-2006
# Posted on: 19-Jan-2018 02:03:46   

Otis wrote:

You by accident ran a netstandard / .net core build ? The profiler only works on .net full

No, it's all 4.7.1. I did originally write the system as .Net Core, but I'm usng the ClearScriptV8 engine, and that is not compatible so the entire system has been switched back to CLR. Is there anything anywhere that can be traced to see why the information is not being displayed?

If the profiler isn't running I can detect the internal exceptions, and I've attached a screenshot. Running the profiler avoids these internal exceptions, so it's clearly creating a named pipe to listen on. I don't even get a Profiler message telling me it can see the application. Any other suggestions?

Attachments
Filename File size Added on Approval
llblgen Profiler.PNG 66,659 19-Jan-2018 02:04.00 Approved
Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 19-Jan-2018 10:29:30   

Could you please attach a repro solution to test?

We didn't need the real project just a couple of lines in a new project where you can replicate it.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 19-Jan-2018 11:39:57   

Additionally, if a console app with on the first line calling the InterceptorCore.Initialize() method and then a simple query also doesn't work, then something else is off.

Perhaps the firewall, although I doubt RPC (named pipes) are really mapped through the firewall...

(edit) just tried, .net 4.7.1 with console app, interceptor for .net 4.5+ (there are two, you need the .net4.5+ one), and queries are coming through fine. This is within Rider too, so that can't be it either.... strange! confused

Frans Bouma | Lead developer LLBLGen Pro
JSobell
User
Posts: 145
Joined: 07-Jan-2006
# Posted on: 19-Jan-2018 13:46:19   

Otis wrote:

Additionally, if a console app with on the first line calling the InterceptorCore.Initialize() method and then a simple query also doesn't work, then something else is off.

Thanks for subtly mentioning the one stupidity check that I didn't try. A standalone console app does log, so it's something to do with the DBProviderFactory not being found and hooked. I've done a little more drilling down, and I'm using ServiceStack's web host, and that is instantiated using


        public AppSelfHost(IEngageConfig config, ILog logger)
            : base("QuestMetrics.SMS.WebService", typeof(WebService.WebService).Assembly)

So it only news up instances when requests arrive, and if the database is accessed from within the threads created the profiler doesn't register it. It's obviously scanning the definitions and finding all classes subclassed from Service in the assembly, so I'm guessing this is messing with the pre-prepared hooked DBProviderFactory, perhaps because it's not using the hooked one at all? I've tried calling InterceptorCore.Initialise in the instantiated component's constructor, but no luck.

Any suggestions?

Cheers, Jason

JSobell
User
Posts: 145
Joined: 07-Jan-2006
# Posted on: 19-Jan-2018 14:06:04   

Ah, finally found why:


            // Configure the DQE            
            RuntimeConfiguration.ConfigureDQE<SQLServerDQEConfiguration>(c =>
            {
                //We're using MSSQL
                c.AddDbProviderFactory(typeof(SqlClientFactory));  <====!!!!!!!!!!!

                //SQL Compat may default to 2005 unless stated (NB: 2012 covers 14,16 & 17)
                c.SetDefaultCompatibilityLevel(SqlServerCompatibilityLevel.SqlServer2012);

                //Allow changing DB name from that generated in LLBLGen DTO model
                if (!string.IsNullOrEmpty(newcatalogue))
                    c.AddCatalogNameOverwrite(defaultcatalogue, newcatalogue);
            });

The call to c.AddDbProviderFactory(typeof(SqlClientFactory)); appears to remove the profiler hooks, and they can't be re-added afterwards.

I guess that was left in from the transition of .Core to Standard. Finally! Thanks for the suggestions, and now I can go back to the usual stuff...

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 20-Jan-2018 10:03:21   

Hmm, that's something we might need to look into as it's not obvious. Thanks for the heads up!

Frans Bouma | Lead developer LLBLGen Pro