Fix dependency specification of logging packages to the exact same explicit version of Castle.Core package

[DianaLaa]

Hi all,

I had some trouble getting Castle NLog integration to work.

I'm using:

Castle.Core v4.1.1
Castle.Core-NLog v3.3.3
Castle.LoggingFacility v4.0.0
Castle.Windsor v4.0.0
Castle.Windsor-NLog v3.4.0
NLog v4.4.1.1
NLog.Config v4.4.1.1
NLog.Schema v4.4.1.1

Now, when I setup a simple installer:

public class Installer : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        // Install logging facility
        container.AddFacility<LoggingFacility>(f => f.LogUsing(LoggerImplementation.NLog)
                                                     .WithConfig("NLog.config"));
    }
}

and write a straightforward test

[TestClass]
public class InstallerTests
{
    protected WindsorContainer Container;
    
    [TestInitialize]
    public void Initialize()
    {
        Container = new WindsorContainer();
    }

    [TestMethod]
    public void Install_ShouldInstallLogger()
    {
        // Arrange
        Container.Install(FromAssembly.Containing<Installer>());

        // Act
        ILogger result = Container.Resolve<ILogger>();

        // Assert
        Assert.IsNotNull(result);
    }
}

I got the error:

Could not convert string 'Castle.Services.Logging.NLogIntegration.NLogFactory,Castle.Services.Logging.NLogIntegration,Version=4.0.0.0, Culture=neutral,PublicKeyToken=407dd0808d44fbdc' to a type. ---> System.IO.FileLoadException: Could not load file or assembly 'Castle.Services.Logging.NLogIntegration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

In order to resolve this, I had to add in app.config:

  <dependentAssembly>
    <assemblyIdentity name="Castle.Services.Logging.NLogIntegration" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="3.3.0.0" />
  </dependentAssembly>

What is causing this behavior? How can I resolve it in a better way? Or is this the right way?

[jonorossi]

You should not mix different versions of Castle Core's packages, i.e. if you use Castle.Core 4.1.1 you should also use Castle.Core-NLog 4.1.1. The same applies to Windsor facilities and those logging dependency packages.

It unfortunately wasn't mentioned in the Windsor 4.0.0 release notes but we dropped those logging dependency packages (Castle.Windsor-log4net and Castle.Windsor-NLog) because they were literally just an empty package that specified a dependency because they are unnecessary.

Are you following a tutorial somewhere that we need to get updated?

[jonorossi]

I'm not sure how to get the new .NET CLI MSBuild-based tools to create an output package with the dependency version set as requiring an exact version not a range.

Currently Castle.LoggingFacility 4.0.0 defines a dependency Castle.Windsor >= 4.0.0 which is not desirable as mentioned above.

The project file uses a project reference so not sure how to override the output dependency range:
https://github.com/castleproject/Windsor/blob/v4.0.0/src/Castle.Facilities.Logging/Castle.Facilities.Logging.csproj#L21

[DianaLaa]

jonorossi,

Thanks for your reply.
I removed the dependency on Castle.WIndsor-NLog and updated all Castle assemblies to 4.0.0.0

Castle.Core v4.0.0
Castle.Core-NLog v4.0.0
Castle.LoggingFacility v4.0.0
Castle.Windsor v4.0.0
Castle.Windsor-NLog REMOVED
NLog v4.4.1.1
NLog.Config v4.4.1.1
NLog.Schema v4.4.1.1

I have removed the redirects in my app.config an it works like a charm. Thanks

P.S. For some reason, I hadn't seen Castle.Core-NLog 4.0.0, which added to my confusion. Furthermore, I'm using Moq, which was asking for Castle 4.1.1.0. I've now downgraded to Moq v4.7.25, the last version that works with Castle 4.0.0.0. Hope this helps someone in the future :)

[stakx]

I'm not sure how to get the new .NET CLI MSBuild-based tools to create an output package with the dependency version set as requiring an exact version not a range.

Currently Castle.LoggingFacility 4.0.0 defines a dependency Castle.Windsor >= 4.0.0 which is not desirable as mentioned above.

The project file uses a project reference so not sure how to override the output dependency range[.]

Is there a specific reason why a project reference is used? Given that Castle.LoggingFacility and Castle.Windsor end up being separately distributed artifacts on NuGet, I would expect that the former depends on the latter via a package reference. I understand project references to be references to an "internal" dependency that will be included in the distribution, while package references are for "external" (i.e. separate) dependencies.

One solution might be to turn the <ProjectReference> into a <PackageReference>, which allows you to specify a version. Then put the exact required version in square brackets as explained in Specifying dependency versions for NuGet Packages: Version ranges.

You might end up with something like this:

<PackageReference Include="Castle.Windsor" Version="[4.0.0]" />

[jonorossi]

I'm using Moq, which was asking for Castle 4.1.1.0. I've now downgraded to Moq v4.7.25, the last version that works with Castle 4.0.0.0

@DianaKoenraadt Castle Core and Castle Windsor are separate projects, their versions don't have to match. You can upgrade Castle Core to 4.1.1, Castle Windsor's most recent release is 4.0.0 which supports Castle Core 4.1.1.

[jonorossi]

Is there a specific reason why a project reference is used? Given that Castle.LoggingFacility and Castle.Windsor end up being separately distributed artifacts on NuGet, I would expect that the former depends on the latter via a package reference. I understand project references to be references to an "internal" dependency that will be included in the distribution, while package references are for "external" (i.e. separate) dependencies.

@stakx good question. We've always used project references for projects in the same Git repo because tooling always stuffed up without doing that, e.g. MSBuild wouldn't detect the dependency had changed when you rebuilt or ran unit tests.

I don't know how the tooling works for PackageReference but I assume it would try to resolve the dependency within the same solution first before going off to a remote repository?

If we did make this change we'd have to use the MSBuild property we've got for the version: https://github.com/castleproject/Core/blob/v4.1.1/buildscripts/common.props#L14.

It looks like others are using project references and also trying to lock the version, there is a workaround in one of the following issues but completely ugly:

• Project reference version when packing project NuGet/Home#5540
• Specify exact version of a project dependency NuGet/Home#5525

With the new MSBuild tooling can you even pack two assemblies into the same package? When should project references be used, only for applications where you don't pack but publish?

Lol - So it is not just me then. I had to write this to make things work for fluentwindsor.

Would you guys like me to raise a PR that does this with a custom MsBuild task for now?

*** Edited ***

Failing that we can wait for v2.0 of netcore

We could revert back to packing using nuspec files. The custom MsBuild task would then consistently include explicit versions as pre-build step honoring the BuildVersion property. This would mean taking a step back from where we are when it comes to NuGet packing and versioning and using the SDK(or the dotnet cli for that matter).

The release for dotnet core 2.0 appears to be very close though, anyone played with version suffixes yet?

[jonorossi]

Failing that we can wait for v2.0 of netcore

Are you saying this is fixed with the .NET CLI 2.0 tooling?

@jonorossi - I am currently investigating this, will ping back if I hit a positive result.

[jonorossi]

@Fir3pho3nixx did you get a chance to look at this one?

It sounds like project references are going to deprecated, and we should be moving to package references anyway:
dotnet/announcements#31

@jonorossi - this is all starting to come together nicely.

We had some uglyness in that crept up with logging down in Windsor here which might have been the root cause of this issue. We have hard coded assembly references in the LoggingFacility which means no matter what every new Core release will break Castle.Facilities.Logging on NuGet when people upgrade.

My fix is nuclear, it requires a breaking change to facilities logging in windsor. I have a PR ready here

It did however lead me to the conclusion that all that facility stuff should live in a separate repository anyway and we should use Castle.Windsor in the facilities repo as a PackageReference. I asked you for the new repo here. This will naturally start moving us in the right direction.

Thoughts?