Using MSSQLServer sink with dnx451: Could not load file or assembly Serilog.FullNetFx

[ghost]

I'm trying to get the MSSQLServer sink up and running in the asp.net 5 web application but this is the exeception I'm getting during the logger creation:

An exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll but was not handled in user code
Additional information: Could not load file or assembly 'Serilog.FullNetFx, Version=1.5.0.0, Culture=neutral, PublicKeyToken=24c2f752a8e58a10'
With the code:

Log.Logger = new LoggerConfiguration() .ReadFrom.Configuration(configuration) .CreateLogger();

Please not I'm also using the Serilog.Settings.Configuration
Here are parts of my project.json
"Serilog.Extensions.Logging": "1.0.0-rc1-final-10092", "Serilog.Settings.Configuration": "2.0.0-beta-6", "frameworks": { "dnx451": { "dependencies": { "Serilog.Sinks.MSSqlServer": "3.0.48" } }
Is that a problem in my configuration or it is simply not working with dnx core yet?
Cheers!

[nblumhardt]

Hi - thanks for the note. The SQL server sink hasn't been ported to .NET Core yet - any assistance with this would be appreciated if you are comfortable with sending a PR. Thanks again!

[ghost]

Sure! I started looking into this. Looks like the plan is that support for using csproj in xproj and vice versa will be part of .NET Cli (in the RC2?) which is not there yet.
I tried to look how other teams / projects are dealing with this and most popular is the approach that EF made to have two seperate solutions (with separated sets of csproj / xproj project files). Are you guys fine with going this way for now?
This is really the discussion that brings the EF idea: dotnet/aspnetcore#621

Just after further reading PCLs are also the option here, as the previous aproach is really more the code sharing.

[nblumhardt]

I think on dev it'd be fine to convert wholly to XPROJ. I'll create the branch now (so far only master in this repo). Thanks for the update!

[nblumhardt]

Done. Default branch on the repo is now dev, new PRs will need to be targeted there. Cheers!

[colin-young]

Ha. I was just looking at this the other day and nearly started working on it. I'll hold off for now, but @mateusz-osojca feel free to ping me if you want some help. I see 2 main things that need to change:

1. Move to the new configuration model. I think Serilog.Extensions.Configuration will help with that.
2. Replace DataTables with something supported, likely SqlCommand and raw, parameterized commands (for general use, I don't think we want to be pulling in a third-party NuGet package like Dapper just to save a few lines of code).

But I've only made a cursory examination of the code.

As I said, I'm happy to help in any way I can.

[ghost]

Hi @colin-young !
Thanks for input!!! I actually started also today on porting to the xproj, didnt get probably that "far" as you but for sure I will ping you soon.

[maartenmensink]

I am willing to help with the conversion to xproj. As i encountered this issues just now :)

How can i help?

[ghost]

Hi Guys!

So here I'm getting a bit frustrating issues. This is important part of the project.json
`"dependencies": {
"Microsoft.Extensions.Configuration": "1.0.0-rc1-final",
"Microsoft.Extensions.PlatformAbstractions": "1.0.0-rc1-final",
"Serilog": "2.0.0-beta-523",
"Serilog.Sinks.PeriodicBatching": "2.0.0-beta-519",
"Microsoft.Framework.Configuration.Abstractions": "1.0.0-beta8",
"Microsoft.Framework.ConfigurationModel": "1.0.0-beta4",
"System.Configuration.Abstractions": "2.0.2.26"
},

"frameworks": {
"dnx451": {
"dependencies": {
"System.Runtime": "4.0.20",
"System.Data.SqlClient": "4.0.0-beta-23516"
}
}
}`

And ofcourse yet I didnt resolve issues that @colin-young mentioned about the DataTables but that is ongoing... But my problems now are I'm having quite a few of those:

Error CS0433 The type 'HashSet<T>' exists in both 'System.Collections, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' Serilog.Sinks.MSSqlServer.DNX 4.5.1

With different type even including Object type. Can you guys help out? My idea is that I'm mixing something with dependencies versions

Cheers!

[colin-young]

@mateusz-osojca, one thing I'll suggest is adopting the frameworks supported in Serilog:

...
"frameworks": {
    "net45": { },
    "dotnet5.1": { }
    "dotnet5.4": { }
},
...

You'll probably only need one of 5.4 or 5.1. Both were needed in Serilog due to differences in how features were implemented in each platform, but I don't think we're going to get into that here. We should aim for 5.1 support, assuming that's possible. You should only include System.* under dotnet5.* since they are included with net45 already. I think that should address your compilation errors.

EDIT: it looks like PeriodicBatching requires 5.2, so dotnet5.2 should be the aim.

[colin-young]

@mateusz-osojca Just wondering if you've had a chance to try out my suggestions about the frameworks. If you've got a fork going, I can take a look at it.

[ghost]

@colin-young .... I definitely did. And that was good point. I was offline for 2 weeks but I'm back to the topic this weekend. I'll update you guys Monday / Tuesday.

[colin-young]

Just wanted to make sure you weren't stuck or anything. As I said before, feel free to ping me with any questions. We did our own implementation here, but it's pretty specialized to our needs. There is probably stuff that would be helpful for a more generic implementation though. I just haven't had a chance to completely sort through it yet.

[nblumhardt]

PR #18 covers the package versions for this sink on .NET 4.5 with Serilog 2. It'd be a useful stepping stone to make that change but will not be of benefit if you're about to drop this one in. Let me know if I should pick up and help with the PR :-) Cheers!

[ghost]

Hi There!

Thats the current state of my project.json:

"frameworks": {
    "net45": {
      "frameworkAssemblies": {
        "System.Data": "4.0.0.0",
        "System.Xml.Linq": "4.0.0.0"
      }
    },
    "dotnet5.4": {
      "dependencies": {
        "System.Data.Common": "4.0.1-beta-23516",
        "System.Xml.XDocument": "4.0.11-beta-23516",
        "System.Data.SqlClient": "4.0.0-beta-23516",
        "Microsoft.Extensions.Configuration": "1.0.0-rc1-final",
        "Microsoft.Extensions.PlatformAbstractions": "1.0.0-rc1-final"
      }
    }
  },

  "dependencies": {
    "Serilog": "2.0.0-beta-507",
    "Serilog.Sinks.PeriodicBatching": "2.0.0-beta-700"
  }

I couldn't really get that compiling for "dotnet5.2" as @colin-young mentioned as
"Microsoft.Extensions.Configuration" and "Microsoft.Extensions.PlatformAbstractions" didnt support it. But I guess in terms of "Serilog.Sinks.PeriodicBatching" it is still ok right?
@nblumhardt I 'm in the middle of moving to new configuration model and I will definitely need help on changing the DataAccess layer. Sorry for some delays here, from now on I will have more time to be consistent.....

[colin-young]

That's unfortunate, We can take a look at that as a separate PR later if necessary.

[merbla]

@colin-young @mateusz-osojca is there a PR yet that is close for dev? @jansoren is looking for one related to #18

[ghost]

@merbla Mine needs around 1 more week, I guess...

[jansoren]

Could we start a new branch with reference to Serilog 2.0.0-beta and create a beta version of serilog-sinks-mssqlserver? It would make my life a little easier :-)

[nblumhardt]

@jansoren dev serves that purpose; I think we can accept the minimal changes in #18 but as per the CI error we'll need to tweak the build to publish a -pre version. I'll add a comment to your PR with the appropriate appveyor.yml to enable that.

[ghost]

@nblumhardt : short question about passing in existing Connection string into Serilog:WriteTo.
In my case I have such an entry:

"Serilog": {
    "Using": [ "Serilog", "Serilog.Sinks.MSSqlServer" ],
    "MinimumLevel": "Error",
    "WriteTo": [
      {
        "Name": "MSSqlServer",
        "Args": {
          "connectionString": "Data:CookingContextConnection:ConnectionString",
          "tableName": "Logs"
        }
      }
    ]
  }

and basically in our extension method that reads the Connection string out of configuration it is pretty hard to reference exisintg Connections string....

Thats because in the Serilog.Settings.Configuration you're injecting only "Serilog" out of the configuration by this line:

return settingConfiguration.ConfigurationSection(configuration.GetSection(DefaultSectionName), libraryManager);
Previously we could easily solve it out as System.Configuration.ConfigurationManager was really accessible everywhere.
Should we then inject whole IConfigurationRoot? Or maybe examine this issue at the level of creating ConfigurationReader in the Serilog.Settings.Configuration to supply it with all references from config and don't pass full caller configuration further on.

Cheers!

[nblumhardt]

@mateusz-osojca that's a good question - it may be one to raise on the serilog-extensions-configuration repository and treat separately. Will need to give the options some thought, anyway...

[ghost]

@nblumhardt You mean to have actually another extension method which responsibility will be only to provide the configuration?

While I'm working on this I get yet another question regarding the configuration.
In the current version we use the MSSqlServerSettingsSection section for configuring extra columns. So following the current state the sample config.json should look like this:

"WriteTo": [
      {
        "Name": "MSSqlServer",
        "Args": {
          "connectionString": "Server=.\\SQLEXPRESS;Database=MyCook;Trusted_Connection=True;",
          "MSSqlServerSettingsSection": {
            "Columns": [
              {
                "Name": "Id",
                "Type": "int"
              },
              {
                "Name": "MealName",
                "Type": "string"
              }
            ]
          },
          "tableName": "Logs"
        }
      }
    ]

Which actually doesnt seem to work with current implementation of Serilog.Settings.Configuration.
Thats because while iterating over "Args" property in GetMethodCalls it is assumed that all args have just string value which is not the case.
So the question is should we maybe first adapt the Serilog.Settings.Configuration to fully support all scenarios we need in here?

[nblumhardt]

Hi @mateusz-osojca - no, I'm not sure what direction we'd take to solve the connection string issue. I think ideally we'd get a basic version (e.g. that requires literal connection strings and probably doesn't cover all scenarios) out in the wild, then pick up the loose ends via some discussions on the configuration repo. Once the initial version here is done, the work can also be assisted by other contributors, which should speed things up and bring some more ideas to the table. What do you think?

Just a note, there's a .NET 4.x-only 2.0 package now published: https://www.nuget.org/packages/Serilog.Sinks.MSSqlServer/4.0.0-beta-83 - thanks @jansoren.

Cheers!
Nick

[ghost]

I totally agree! Then I will focus to get first bits done. I saw the 4.0.0-beta83 but thanks for heads up!

[ghost]

@nblumhardt , @colin-young I'm just ready with first implementation. Just need to polish it a bit and will share on comming days. Just so you get and idea, I did first try of using the new Microsoft.Extensions.Configuration model (that yet doesn't cover all the cases, as you can follow from above messages). I had to replace SqlBulkCopy with own implementation of SqlCommand. Quite some changes and I will most probably need assistance with changes to scripts/ build...

[ghost]

Hi there!

I made a first checkin to dev. I know it requires quite a lot of work..... But the general idea:
I created along the .csproj the .xproj with extra solution file for it "-xproj.sln" (I steal the idea from EF github)
Also most of the files are duplicated with the name ending with ' - those are the files included in .xproj.
Please let me know if I'm anyhow going in proper direction. I was not quite sure how to target both .net Framework SDK and DNX sdk at the same time.

[nblumhardt]

With project.json support now in master I think it's ripe for someone to tackle .NET Core support; I think this ticket has too much history in it now to be clear on what we're aiming for so I'll close it, but a PR with .NET Core support is still very high on our "most wanted" list. Cheers!