I'm looking at different logging frameworks and it seems like Serilog is quite mature.
I am confused by all the different version numbers. How do I know what sinks belong to what versions of the core framework? Why aren't the version numbers standardized?
Serilog core hasn't broken backward binary compatibility since 2.0 in June 2016 (a long time ago, in .NET terms), so all maintained sinks work with the latest Serilog core package.
You should just need to pick the latest stable version of Serilog and of each sink you wish to use, and everything will just work.
(Sinks may have other dependencies that overlap and conflict, but this would be unusual to encounter.)
Related
At the time of this post there are two Azure Service bus SDKs sitting within sdk/servicebus:
Microsoft.Azure.ServiceBus
Azure.Messaging.ServiceBus
They have both been updated very recently (past week).
This ms doc (written two weeks ago) states;
This quickstart uses the new Azure.Messaging.ServiceBus package. For a
quickstart that uses the old Microsoft.Azure.ServiceBus package, see ....
Where as this document (also written two weeks ago) says;
There are two supported Azure Service Bus .NET SDKs. Their APIs are
similar, and it can be confusing which one to choose. Refer to the
following table to help guide your decision. We suggest using the
Microsoft.Azure.ServiceBus SDK as It's more modern, performant, and is
cross-platform compatible. Additionally, it supports AMQP over
WebSockets and is part of the Azure .NET SDK collection of open-source
projects.
This document goes on to mention Microsoft.Azure.ServiceBus as newer and (yet another SDK) WindowsAzure.ServiceBus as older. It does not mention Azure.Messaging.ServiceBus at all.
Does anyone have any advice on which SDK should be used for a new .NET Core 5.0 project?
(I have already reviewed this question which has not helped)
For projects that have no dependency on the older packages, use Azure.Messaging.ServiceBus. For everything else, look at the dependencies. For example, Azure Functions cannot use the latest package today. It will likely be addressed in the future just not ATM. I wrote a blog post awhile ago about these 3 packages. May (or may not) help you with your question.
I have an application which loads some external data based on gremlin.
I want to use it to load the data into a Neo4j database.
I saw that there was partial support for gremlin in previous versions but couldn't find any solution for latest version.
I'll be happy to hear if it is still possible and how can it be done.
At this point, TinkerPop expects to support 3.4.11 in its future 3.5.0 release (here) which is yet several months away. For TinkerPop to support 4.0 it would need a fresh release of the neo4j-tinkerpop-api-impl to be released with that version. It seems an issue has been created for that here.
Why does not FSharp.Core.dll contain major version in its name? Won't it help to solve binary compatibility issues?
As far as I understand when authoring a library developed in F# it should have a dependency on FSharp.Core.dll NuGet package with upper version limit as <CurrentMajor+1. Upper version mustn't stay unconstrained because binary compatibility is guaranteed only between libraries having same major version. Just a semantic versioning model.
Let's now imagine a library which is useful, has no bugs and logically finished. In other words there is no more need to support it. Period.
Then F# 5 is released and ... users of the library cannot use it anymore in projects referencing libraries created with F# 5.x
Ok, the upper statement is a mistake
(For F# 2, F# 3 and F# 4 FSharp.Core library had versions 4.x.y.z.)
Nevertheless, the question stays valid.
At some point in time major version will be increased to 5. This supposedly will break binary compatibility. (Why otherwise would you make an increment?)
Here is what I mean:
Project references NuGet.New and NuGet.Old.
NuGet.Old references FSharp.Core.dll [4.x.y.z, 5.0.0.0)
NuGet.New references FSharp.Core.dll [5.0.0.0, 6.0.0.0)
NuGet won't allow it. It is a version conflict.
Actually I confronted with the similar problem yesterday (4th Dec 2018) when EF Core 2.2 NuGet package was already available, but Sdk for ASP.NET Core 2.2 did not.
Micrsofot.AspNetCore.App metapackage pinned version of EF Core to the range [2.1.0, 2.2.0). After I referenced EF Core 2.2 in my DAL project the whole solution stopped building because of version conflict.
However, if it were FSharp4.Core.dll and FSharp5.Core.dll they could work side by side.
Yes, conventions and shapes of CLR types which represent same concepts of F# 4.x and F# 5.x can differ, but compiler can tag a type with its major version. This will not only help to distinguish new objects from the old ones, but can allow new compiler to silently create code for adapting old types to new version.
The major language version is the first number in the package and binary version as of F# 4.5.
FSharp.Core is binary compatible. In your scenario, Users of F# 5 would still be able to use the older library. Failing to do so would be a bug.
Using the .NET Core 2.1.1 Alpine (the SDK and the runtime) leads to several errors:
A. Fatal Internal connection when connecting to an SQL Server Database
B. After a few hours, the app boxes throw System.OutOfMemory exceptions regardless of the load and the available processing power.
If you get this, then you're out of luck! Please do not make the same mistake as we did with adopting Alpine-based NETCore 2.1 for what's about to become a production-ready app in a few months. After weeks of hunting weird bugs, we came to realise that .NET Core 2.1 in the Alpine falvor is fully experimental. Basic functionality is hindered by gross bugs. One can only wonder the range of detailed, more context-specific bugs that you're likely to encounter in production.
A. You'll need to install the icu-libs package. Connecting a .NET app to an SQL Server database is probably the most popular db connection of the language. One would think that the .NET team would test that their spanking new Alpine images so that MVC apps can properly connect to, but no. The 2.1.1 runtime image cannot automatically convert Windows string format to Linux ones.
Here's a link showing that Microsoft is aware of the issue but does not list this as a known bug:
https://github.com/dotnet/corefx/issues/29147
B. Turns out that the 2.1.1 Alpine-based runtime for .NET Core is having some serious memory leaks. Microsoft's own .NET team is fully aware of the issues:
https://github.com/dotnet/corefx/issues/30652
Sadly, however, the .NET team appears to be hiding the problems in the Github discussions. Plenty of users have signaled similar errors but instead of letting devs know that the 2.1.1 Alpine-based runtime image is severely broken, it looks like the issue is just covered up by Microsoft. Please note that the issue is not listed among the known issues of .NET Core 2.1.
Shaml looks awesome for project kick-start.
Would be great if it could be configured to also include NHibernate Search and other Contrib projects. Any plans for this?
Although the 1.x versions of NHibernate were very stable under mono, the recent version 2.0.1 and 2.1beta have many issues (like the lazy loading not working). I hope the 2.1 final will be much more stable under mono, and all the other projects (I'm mostly interested in NHibernate.Linq) will work without major problems too. Until that point I try to minimize the dependencies on external stuff and/or send patches to the maintnainers of the different projects (like DNOA). If you happen to succesfully integrate NHibernate 2.1 and/or NHibernate Search feel free to fork the github project.