Getting started with Linq-to-SQL or Entity Framework

Although they were released in 2007 (Linq-to-SQL) and 2008 (EFv1), these two data access technologies and the tools, frameworks, and language features surrounding them are new to lots of people who are just about to start using them.

The following blog post covers some resources (books, blogs, forums) that contain everything you need to get started with and/or understand how Entity Framework, Linq-to-Entities, Linq-to-SQL, or LINQ in general works.

Books and Blogs

Professional ADO.NET 3.5 with LINQ and the Entity Framework and Oakleafblog

Professional ADO.NET 3.5 with LINQ and the Entity Framework by Roger Jennings covers all the new data access technologies that were introduced with .net 3.5. Roger has written 30+ books on everything from operating systems, databases, programming, data access etc. Nowadays he is covering cloud computing in his blog and in his latest book.

Before his interest for cloud computing took over completely, Roger covered just about everything that happened in the .net data access world (Linq-to-SQL, Linq-to-[everything else], Entity Framework, ADO, etc) with daily updates in his blog,
http://oakleafblog.blogspot.com/. All those L2S/EF/ADO articles are still there if you scroll down a bit, and links to lots of useful code samples and tips and tricks.

Programming Entity Framework, Second Edition and The Data Farm

Julie Lerman has written two books on Entity Framework. The first one covered EFv1, the first version of Entity Framework that shipped with .net 3.5 SP1.

Her latest book, Programming Entity Framework, Second Edition, is for Entity Framework 4 or EFv4 that shipped with .net 4 / Visual Studio 2010. Programming Entity Framework, Second Edition is 914 pages covering every little corner and aspect of EFv4.
http://oreilly.com/catalog/9780596807252

Julie has a couple of blogs to go with the book:
http://thedatafarm.com/blog/
http://learnentityframework.com/learnentityframework/

…and she also writes the Data Points column in MSDN Magazine.

Linq in Action and ThinqLinq

Linq in Action by Jim Wooley, Fabrice Marguerie, and Steve Eichert dives into the details of all flavors of LINQ.
http://www.amazon.com/gp/product/1933988169

Jim Wooley also has a blog with lots of useful Linq tips, tricks, and solutions at http://www.thinqlinq.com/ . His blog also has a page with links to various third party tools for L2S and EF:
http://www.thinqlinq.com/default/LINQ-Tools.aspx

Damien Guard’s blog

Damien Guard used to work with the Linq-to-SQL and Entity Framework team at Microsoft. Now he is working with some other team at Microsoft (XBox..?). His blog has a lot of L2S and EF goodies, among those a neat one-page reference to the most commonly used Linq syntax. Very handy to have on the wall when writing code against Linq-to-SQL or Linq-to-Entities: http://damieng.com/blog/2009/08/12/linq-to-sql-cheat-sheet

Damien also has some links to various Linq-to-SQL resources; tools, blogs etc:
http://damieng.com/blog/2009/06/04/linq-to-sql-resources

Alex James’ blog

Nowadays focused more on OData, Microsoft’s Alex James has a lot of EF tips and tricks and useful code samples that can be used with both EF and L2S in his blog:
http://blogs.msdn.com/b/alexj/

MSDN blogs

The ADO.net team has two blogs, one covering EF in general and one with articles about future features in EF:
http://blogs.msdn.com/b/adonet/
http://blogs.msdn.com/b/efdesign/

Forums

MSDN forums

The MSDN forums, run by Microsoft, is a gold mine of useful information on both EF and L2S. Just browsing/searching these forums can reveal a lot of useful information, best practices, tips and tricks etc. If you can't find what you're looking for, post a question and you will probably have a solution within a day.

http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/threads
http://social.msdn.microsoft.com/Forums/en-US/linqtosql/threads

StackOverflow

StackOverflow also has a lot of useful information and helpful people answering questions, whether newbie/beginner questions or advanced stuff. Check out the EF and L2S-related tags:
http://stackoverflow.com/questions/tagged/entity-framework
http://stackoverflow.com/questions/tagged/linq-to-entities
http://stackoverflow.com/questions/tagged/linq-to-sql

Did I miss something?

The above are just a handful of the resources available, but should be good starting points. In all the blogs and forums I have linked to you will come across links to hundreds of other resources with useful information.

Using the Model Comparer to generate difference reports for Entity Framework v4 models

In the previous two blog entries, Introducing the Model Comparer for Entity Framework v4, and What’s new in the latest version of the Model Comparer for Entity Framework 4 I covered the basics of using the Model Comparer to keep EFv4 models in sync within the model and with the underlying database without replacing or losing customizations made to the model.

Now the turn has come to show the latest feature in the Model Comparer: Reports.

The main work area in the model comparer shows database <=> SSDL differences, SSDL <=> database, SSDL <=> CSDL, and CSDL => SSDL differences broken down in three treeviews and allows users to sync (or ignore) individual/selected (or all) differences.

In some situations it may be more useful to generate simple diff reports listing all differences in a readable format; printable/mailable reports come in handy when emailing to colleagues, for use during meetings, to review differences in more detail before applying changes, etc.

The newest feature added to the Model Comparer for EF4 is a "Reports" tab made just for creating reports from EF4 models:

The diff reports are generated from the same model diff comparison as the diff data shown in the treeviews in the differences tab, but the report format allows a lot more details pertaining to unmapped and changed objects can be shown; from database column attributes to SQL Server extended property descriptions, and in-model documentation.

Each type of difference get a section in the report detailing all differences of that specific type:

The Model Comparer compares all available attributes; from entity level down to data types, max size, precision/scale, nullability, default values, default constraints and just about everything else that is reflected in both the database, and the SSDL and CSDL layers of the EFv4 model:

 

Screencast / Video

I have created a short video/screencast demonstrating the basics of the Model Comparer's new report-generator feature:

 

Want to try it out?

If you want to try out the Model Comparer, you can download Huagati DBML/EDMX Tools and get a trial license from http://www.huagati.com/dbmltools/ . (The model comparer is just one of many features for Entity Framework and Linq-to-SQL contained within the add-in. The report viewer was added in version 1.93.)

Keep an eye on this blog for new features; we’re rapidly adding new EFv4-related features to the Huagati DBML/EDMX Tools Add-in. Note that the EFv4-related feature set only works under Visual Studio 2010.

What’s new in the latest version of the Model Comparer for Entity Framework 4

The following is a brief description of some of the new functionality that was just added to the Model Comparer for EF4.

An introduction video to the model comparer is available in the previous blog entry: “Introducing the Model Comparer for Entity Framework v4”.

New Version – new features

Yesterday I released a new version of Huagati DBML/EDMX Tools, and with it a new version of the Model Comparer with a pile of fixes, improvements, and some new features.

The goal of the Model Comparer is to give developers using Entity Framework 4.0 in Visual Studio 2010 better control over differences between the conceptual model (CSDL) and storage model (SSDL), and between the database and the storage model in EFv4 models. It does that by comparing the three layers and showing detected differences in three treeviews. The user can then select individual differences (or all) and either bring them across to the opposite layer or tell the Model Comparer to ignore differences.

The core functionality in the Model Comparer is described in more detail in the intro video in “Introducing the Model Comparer for Entity Framework v4”. If you haven’t used the model comparer or watched the intro video you may want to start with that one to get an idea of what the Model Comparer itself can do and how it works.

To give users even more control over what the Model Comparer takes into account when determining differences between the layers, it has a number of user-controllable settings. In the first version (add-in version 1.91) those settings were stored in XML files but not readily accessible from the UI.

As of version 1.92 there are UI dialogs exposing the most common settings. The settings dialogs are accessible through two new buttons in the lower left corner of the Model Comparer dialog:

The first button, “Settings” controls the behavior of the model comparer, and the second one, “CSDL Name Rules” define the naming rules used when creating CSDL entities and members from SSDL objects.

Model Comparer Settings

Most of these settings are simple on-off options so the settings dialog are cluttered with has a lot of checkboxes. (Yes, I know, checkbox-hell, but hopefully the settings themselves are self-explanatory enough to make it survivable on the rare occasions that these settings may need to be tweaked. It was really down to a choice between checkbox-hell and property-grid-hell and I think checkbox-hell is still easier to get an overview over.)

So, let’s break it down. The settings are grouped by the model area that they correspond to: Database, SSDL, CSDL.

Additionally there is one shared group of settings for SSDL/CSDL member differences, and one group that define what – if any - database default constraints should translate into store generated patterns in the model.

Database-to-SSDL difference settings

The first group of checkboxes controls if the model comparer should detect tables, views, columns, FK constraints, procedures and functions that exist in the database but has no representation in the SSDL:

The next group of checkboxes control what types of differences between database columns and SSDL member properties should be included in the database tree as DB->SSDL differences:

Finally, the last group of database diff settings are for stored procedures and functions; these settings control what type of differences should land stored procedures and database functions on the list of procedures with differences between the database and SSDL:

SSDL difference settings

The second portion of the settings dialog, SSDL settings, controls what types of objects present in the SSDL should be shown in the SSDL tree if not present in the database or CSDL.

The first five settings control the SSDL-to-database missing-objects comparison:

…and the following four settings controls the SSDL-to-CSDL missing-objects comparison:

CSDL difference settings

The next portion of the settings dialog, CSDL, controls if CSDL objects not present in the SSDL portion of the model should be displayed in the Model Comparer’s CSDL tree:

CSDL-to-SSDL difference settings

The CSDL to SSDL settings portion controls what types of differences at entity member level should land entities and their members on the diff list in the CSDL and SSDL trees. These settings are shared between both portions since differences in this area are shown in both trees:

Database constraint settings

The final portion of the Model Comparer’s settings dialog controls which – if any – database default constraints should be treated as StoreGeneratedPattern: Identity or StoreGeneratedPattern: Computed instead of the default StoreGeneratedPattern: None.

This comes in handy if primary key values are generated database-side by a default constraint like NewID or NewSequentialID, or if a table has ‘created date/time’ fields that are populated by the database rather than the client application.

There is also one field that control what the default constraint should be set to if generating SQL-DDL from the model comparer for tables with GUID PKs marked as StoreGeneratedPattern: Identity in the model. The default value is NewSequentialID but it can be changed to NewID or a user-defined function, as needed.

CSDL name rules

The second settings button available in the Model Comparer controls how CSDL entities and CSDL members generated from SSDL artifacts should be named. It allows you to e.g. strip underscores, apply ProperCase/pascal casing to class and member names, control pluralization and singularization, remove (or add) prefixes/suffixes and apply a whole set of other naming rules to ensure that the final classes and member properties conform to .net naming conventions (or your own naming conventions) even if the database objects don’t.

The naming rule settings are applied by the Model Comparer only when adding entities or members to the CSDL portion of the model. For renaming existing CSDL entities and members, the add-in has a separate feature that use the same set of settings but allows renaming existing entities and entity members.

What’s next?

The Model Comparer is a brand new feature in Huagati DBML/EDMX Tools, and it will get new features and improvements in various areas in the near (and far) future. Besides general usability improvements, the next version (1.93) will introduce new reporting features. More on this when 1.93 is released.

Want to try it?

If you want to try out the Model Comparer, all you need to do is head over to http://www.huagati.com/dbmltools/ and download the Huagati DBML/EDMX Tools add-in.

After downloading, click on the ‘trial license’ link to get a trial license, fill out your details, and you will receive a license key that will enable you to use the add-in for free for 20 days. If you’re happy with it and want to continue using it after that, please buy a license (or subscribe for only $15/month/user) to support further development of this and other features.

The add-in includes the Model Comparer for EF4 as well as a whole lot of other useful extensions to the Entity Framework and Linq-to-SQL designers in Visual Studio 2010 and 2008. (Note: Some add-in features such as the EF4 Model Comparer are only available under VS2010)

Introducing the Model Comparer for Entity Framework v4

This is a brief intro to the just-released Model Comparer for Entity Framework. The model comparer is part of the Huagati DBML/EDMX Tools add-in for VS2010, and was added in version 1.91 released on 29 July 2010.

 

The problem

The Entity Framework designer in Visual Studio 2010 has a lot of improvements over earlier versions. Like its' predecessor in VS2008 it has the ability to update the model from the database, but like its predecessor it gives the user a rather limited choice over what to update.

 

Developers often need a more fine-grained control over the diffs and updates; there may be hand-tweaked parts of the EF model that they don't want to change and there may be database changes that should not be propagated over to the model.

 

The model comparer

The model comparer is an attempt to give developers more control over the EF4 designer in Visual Studio 2010 in terms of handling db-model differences and intra-model-differences.

The add-in doesn't replace the EF designer and doesn't remove anything that is part of Visual Studio. It does however give a more detailed overview over differences between each of the layers; database, storage model, and conceptual model. The differences are displayed in three treeviews, and there are a number options for bringing individual or all differences across as well as for ignoring differences.

 

Whenever a model is updated using the model comparer, only the relevant portions of the SSDL, MSL and CSDL are updated. Entities with no changes are left untouched along with any customizations that may have been made to them. This is unlike the VS built in "update model" wizard that often overwrite manual changes to the model when only a specific change should have been brought across.

 

I have made a short intro video showing the model comparer in action in VS2010 against the Microsoft AdventureWorks database. Enjoy!

 

Simplify Entity Framework v4 models with complex types

One neat feature in Microsoft’s Entity Framework is support for complex types in the model. Complex types allow you to group together a bunch of properties in their own type and reuse that type from multiple entities. Complex types have been supported by Entity Framework from v1 although the v1 designer in Visual Studio 2008 didn’t support complex types, so until Visual Studio 2010 models using complex types had to be hand-edited in an XML editor.

The EFv4 designer in Visual Studio 2010 does support complex types, but it still involves a fair bit of manual work to define them, add them to entities and create mappings when working with multiple entities. There is a “Refactor into New Complex Type” feature in the VS2010 EF designer, but it unfortunately only works with one entity at a time.

To remedy this I looked into simplifying complex type creation and usage from multiple entity classes by adding a feature to Huagati DBML/EDMX Tools . The goal is to make generating and using complex types in EFv4 easier for EF models generated from existing databases.

The new feature is quite simple, it lists all seemingly identical entity members in a model, ordered by number of occurrences in the model. A user can then select the members they want to generate a complex type from, and give the new type a name.

While selecting members, the add-in shows which model entities share the selected members. When adding a complex type this way, the underlying entities and the conceptual-to-storage mapping will be automatically updated to incorporate the complex types and map to the correct storage members.

The process can then be repeated as many times as wanted, leading to a less cluttered model diagram with less repeated-over-and-over-again member properties.

…entities without complex types…

…and the same entities after adding complex types…

This feature will be part of Huagati DBML/EDMX Tools version 1.90, together with some other new EFv4-specific features. The EFv4 specific features will only be available when using the add-in from Visual Studio 2010. Previously existing features will still work in both VS2008 and VS2010.

Entity Framework support in Huagati Query Profiler (formerly known as Huagati Linq-to-SQL profiler)

When I first introduced the Huagati Linq-to-SQL Profiler nearly a year ago, I mentioned that it would eventually support other data access technologies than just Linq-to-SQL. Second up was support for LLBLGen profiling released in October 2009. Now the turn has finally come to Microsoft’s Entity Framework 4.0.

The concept is the same, the packaging is the same, and existing licensed users of the profiler can simply install the latest version to add support for Entity Framework query profiling in addition to the already existing Linq-to-SQL and LLBLGen profilers.

Why? Why not use SQL Profiler instead?

Database performance, and conserving db-side resources is often key to app performance in database driven applications. There are many tools around for profiling, and there can sometimes be an overlap between what they do.

The Huagati Query Profiler bridges the gap between SQL Server and OR-mapper code. It collects important information about queries executed by Linq-to-SQL, Entity Framework, and LLBLGen and combines that information with stack traces and other details that make it easier to find out what code in an application is responsible for the most expensive or most long-running database queries. It overlaps with the SQL Server Profiler in collecting query information, with Visual Studio, and with SQL Server Management Studio, but adds the benefit of linking information otherwise available separately in each of the three applications together.

What does it do? How does it work?

The profiler consists of two main parts:

1. A redistributable runtime DLL that you can reference from and include with your applications. There is one runtime logging DLL for each of EFv4, L2S, and LLBLGen. The runtime logging DLL collects information about what queries are executed against the database along with useful information such as timings, I/O cost, execution plans, and various feedback from SQL Server's query optimizer.
2. The profiler log explorer application that is used for exploring logs generated by the runtime DLL, and examining individual log entries in more detail.

Filters

Filters can be set up in both layers; in the runtime component to avoid logging non-costly queries or to narrow down on specific types of query behavior, and in the log explorer to narrow down specific types of queries when examining existing logs.

The logging components have several built-in filters, and custom filters can easily be added if needed.

Code samples

After installing the profiler, Windows Programs menu will get a new program group called Huagati Query Profiler:

The first entry, Code Samples (zip) will open up a zip file containing a handful of sample Visual Studio projects in C# and VB. The sample projects shows how to integrate the runtime component with an existing application, and includes sample queries showing some typical operations. The Entity Framework 4 sample is called AdventureWorksEF and it uses the Microsoft AdventureWorks sample database.

AdventureWorks EF model in VS2010 (click for larger image)

Sample ObjectContext with EF Profiling support added (click for larger image)

The UI of the sample project is simple, a small form with a single button. Behind the button are several sample queries, some doing a simple primary key lookup, others doing group/aggregate queries etc.

Query in the code samples project (click for larger image)

To generate some sample log entries for the log explorer, run the sample project and click on the Test! button.

Code sample project UI: a single button

Before running the sample project, ensure that the connection string in app.config is pointing to where you have installed the Microsoft AdventureWorks sample database.

The profiler log explorer

After generating log entries, start up the Profiler Log Explorer (Start/All Programs/Huagati Query Profiler/Huagati Query Profiler-Log Explorer).

The Huagati Query Profiler Log Explorer main window (click for larger image)

The log explorer's main window is divided in a few different sections:

• The top portion of the screen contains a grid listing all queries in the log or all queries passing the criteria set under the Filters option in the toolbar):

Query list (click for larger image)

• In the lower left portion of the screen it shows the query behind the currently selected log entry, along with visual indicators for I/O, timings, and feedback from SQL Server's optimizer:

Query details (click for larger image)

• In the lower right portion of the screen it shows the call stack that led to the query being executed. If symbols (pdb) were present when the log entry was created, the call stack will contain convenient hyperlinks that can be used to open up the corresponding source code file on a developer machine.

Call stack (click for larger image)

Query information details

Many of the elements in the Query Information portion of the log explorer window will show additional details when hovered over, and/or when clicked on:

“Missing Indexes” alert with details in hover-popup (click for larger image) 


Table scan alert with accompanying tooltip (click for larger image) 


I/O statistics are shown when hovering over any of the I/O numbers or info bars


Timings are available by hovering over the timing numbers or indicator bars

Some of the links, such as the execution plan link or source code links will start up other applications such as SQL Server Management Studio or Visual Studio.

Clicking on the Execution Plan link for example will open up the logged execution plan for the query in SSMS:

Clicking on the “execution plan” link brings up SSMS with the logged execution plan (click for larger image)

Missing indexes sample

The particular sample query shown in the screenshots above has a missing index alert:

Missing indexes alert (click for larger image)

A missing index alert means that SQL Server's optimizer determined that the query in question can be made more efficient by adding indexes to one or more tables involved. Hovering over the index alert will display the optimizer's suggested indexes.

In this case, the optimizer suggested three new indexes:

create index IX_SalesOrderHeader_ShipToAddressID on [AdventureWorks].[Sales].[SalesOrderHeader] ([ShipToAddressID], [OrderDate]) include ([Status], [TotalDue]);

create index IX_SalesOrderHeader_OrderDate on [AdventureWorks].[Sales].[SalesOrderHeader] ([OrderDate], [Status]) include ([ShipToAddressID], [TotalDue]);

create index IX_Address_PostalCode on [AdventureWorks].[Person].[Address] ([PostalCode]) include ([AddressID]);

However, looking closer at the optimizer's suggestions, two of the indexes can be combined into one to avoid overlap:

create index IX_Address_PostalCode on [Person].[Address] ([PostalCode])

create index IX_SalesOrderHeader_ShipToAddressID on [Sales].[SalesOrderHeader] ([ShipToAddressID], [OrderDate], [Status]) include ([TotalDue]);

After re-running the sample app and hitting Refresh in the log explorer we can see what the result of the new indexes were - in this case the query went from 919 reads and a table scan, down to to 54 and index seeks:

Query I/O for sample #1 after adding indexes as per above 

Where do I get it, how do I get started?

The Entity Framework 4 logging component for the Huagati Query Profiler is included as of version 1.31. The EF component is currently marked as a beta version as it is still undergoing testing, but is available for anyone to download and try out. The current download URL for v1.31 (beta) is
http://www.huagati.com/l2sprofiler/download/HuagatiQueryProfiler_131_beta.zip

 

If you have an existing license for Huagati Linq-to-SQL Profiler or Huagati Query Profiler, you can simply install the latest version to get the EF logging component in addition to the Linq-to-SQL and LLBLGen logging components. If you don't have a license you can request a trial license key from
http://www.huagati.com/l2sprofiler/

 

Additionally, during the beta period - if you become a beta tester and the provide feedback from your testing you will get a full license key for the final released version. To apply to become a beta tester, send an email to support (at) huagati.com.

 

Feedback and questions are always welcome, you can send your feedback or questions to support (at) huagati.com, or post it in the support forum, or post a comment in this blog.

Query Profiling for LLBLGen Pro-based applications

When I introduced the first release of the Huagati Linq-to-SQL Profiler back in August, I mentioned that there would be additional profiler runtime logging providers besides the initial one for Linq-to-SQL; "Additional logging providers; if there is enough interest I may extend the runtime logging component to also support Entity Framework, plain ADO.NET, or other data access technologies such as 3rd party OR/Ms.".

The profiler's log file format and the profiler log viewer is not tied in any way to Linq-to-SQL specifically. Although the choice of name for the tool may not be ideal, it was designed to be used with other OR mappers and data access technologies as well.

A few weeks ago I contacted Frans Bouma, author of the popular LLBLGen Pro O/R Mapper Generator. LLBLGen Pro has been around for six years and is packed with great functionality; no doubt the market leading OR mapper for .net. Frans was enthusiastic about the idea, so we exchanged a couple of emails to determine the best approach to integrate profiler logging into LLBLGen based projects without requiring too much of an effort of work by end-users. Frans suggested using a partial class implementation of LLBLGen's DataAccessAdapter class, so that's the direction I went.

Due to some time constraints in other projects I had to suspend work on the LLBLGen profiler logging component for a couple of weeks, but it is now ready for release.

To enable query profiling in a LLBLGen based project, some minor additions are needed in the application to be profiled. A reference to the profiler logging assembly must be added, and a new partial class implementation of the LLBLGen Pro DataAccessAdapter containing calls to the profiler logger need to be included in the same project as the LLBLGen generated code.

The following screenshots shows step-by-step how to enable query profiling in the LLBLGen Northwind Adapter sample project (downloadable from http://www.llblgen.com/pages/files/Example_NorthwindCS1_Adapter_06062008.zip ). Click on the individual screenshots for a full-size version.

Step 1: Add a reference to the profiler logging assembly (HuagatiLLBLGenProfiler.dll) (A), include LoggingAdapter.cs (B) (both are installed together with the profiler itself under C:\Program Files [(x86)]\Huagati Systems Co Ltd\Huagati Linq-to-SQL Profiler\redist ). Next, change the namespace in LoggingAdapter.cs to match the namespace of the application's own DataAccessAdapter class (C).


Step 2: Add a call to one of the InitializeLogging methods in the DataAccessAdapter's constructor(s). There are a few different overloads of InitializeLogging, depending on what logging features, filters, etc that you want to use.


Step 3: Compile and run the application.


Step 4: Start the Huagati Linq-to-SQL Profiler Viewer, open the logging directory used, and have fun with the logs:


Just as when profiling a Linq-to-SQL application, the top part of the window shows log entries and the bottom part shows details such as I/O statistics, timings, call stack etc pertaining to the selected log entry. All blue underlined links are clickable and will bring up additional details; clicking on the execution plan link will open the execution plan diagram in SSMS, clicking on the source code links in the call stack will open up the source file linked to in Visual Studio and so on.

Database-side I/O statistics and timings are shown in easy-to-spot bars indicating the relative cost. Each one has a tooltip containing more detailed information from the database engine:


The call stack portion shows the call stack that led to a certain query being executed, with hyperlinks directly to the source code (whenever debug information and source code is available):


In short, it is as easy to get started with profiling LLBLGen based applications as it is to profile Linq-to-SQL based applications.

The filters available in the LLBLGen logging component are the same as the filters available in the Linq-to-SQL logging component. This means that after adding profiling to a LLBLGen app as in the steps above, the examples shown in "A walkthrough of the newest filters and visual cues in the Huagati Linq-to-SQL Profiler", and "Profiling Linq-to-SQL Applications" will work with the LLBLGen profiler logging component as well. Custom logging filters can of course also be added the same way; by creating a new class inheriting from the ProfilerFilter base class or from one of the pre-defined filters.

The profiler logging component for LLBLGen Pro is included in Huagati Linq-to-SQL Profiler version 1.20 (scheduled for release on Oct 12 2009).