LLBLGen Pro Runtime Libraries and ORM Profiler interceptors are now available on nuget

Tuesday, February 10, 2015

I caved. For years I’ve denied requests from customers to publish the LLBLGen Pro runtime framework assemblies on nuget, for the reason that if we had to introduce an emergency fix in the runtimes which also required template changes, people with dependencies on the nuget packages would have a problem. While this might be true in theory, in practice it’s so uncommon that this will happen, it more and more turned into an excuse.

Add to that that customers started publishing the runtimes themselves on nuget, it was time to bite the bullet and publish the runtimes ourselves, officially. So we did. At the same time we published the interceptor assemblies of ORM Profiler on nuget.

The URLs

For LLBLGen Pro:

For ORM Profiler:

https://www.nuget.org/packages/SD.Tools.OrmProfiler.Interceptor.EFv6/
https://www.nuget.org/packages/SD.Tools.OrmProfiler.Interceptor.NET45/
https://www.nuget.org/packages/SD.Tools.OrmProfiler.Interceptor/

Who are these assemblies for?

The assemblies are for customers who want to stay up to date with the latest runtimes. Every time we publish a new build, the runtimes and interceptor dlls are automatically updated with the latest build. We never introduce breaking changes in released assemblies, so they’re safe to use in code and update to the latest version.

How are they versioned?

The LLBLGen Pro Runtime Framework assemblies are versioned as: 4.2.yyyymmdd, where yyymmdd is the build-date. The ORM Profiler interceptors are versioned as: 1.5.yyyymmdd.

What’s in the packages?

The DQE packages come with a single DLL, the DQE dll, and have a dependency on the ORMSupportClasses package. The ORMSupportClasses package contains both the .NET 3.5 build and the .NET 4.5 build with async support: if your project targets .NET 4.5 you automatically will reference the .NET 4.5 build with async support.

The Interceptor packages contain the interceptor dll and support dlls which don’t need their separate package. The Entity Framework interceptor has a dependency on Entity Framework 6.

Do the DQE packages depend on ADO.NET provider packages?

No, as all DQEs work with the DbProviderFactory system and don’t need the using project to reference an ADO.NET provider reference. The ADO.NET provider has to be present on the system, but as the provider assembly doesn’t need to be referenced by the VS.NET project the DQE package doesn’t need a direct dependency on the related ADO.NET provider package as that would mean the ADO.NET provider dll would be directly referenced after the DQE package has been installed.

Hope this helps the customers out who have asked us for so long for this feature Smile

The URLs

Who are these assemblies for?

How are they versioned?

What’s in the packages?

Do the DQE packages depend on ADO.NET provider packages?

2 Comments