Nancy.Validation.FluentValidation compile-errors when upgrading to FluentValidation to version 7.

[PureKrome]

Description

When running a simple Nancy website with Nancy.Validation.FluentValidation and FluentValidation v 7.x the compiler throws an error about failing to find the correct FV assembly:

System.IO.FileLoadException
Could not load file or assembly 'FluentValidation, Version=3.4.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at Nancy.Validation.FluentValidation.FluentValidationRegistrations..ctor()
   at lambda_method(Closure , Object[] )
   at Nancy.TinyIoc.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options)

If I downgrade the two projects to FluentValidation v 6.4.1 (the latest in the 6.x series) the code runs fine.

I've provided a simple repo solution here.

Also, I've tried (but this is not in the provided solution) to use Binding Redirects to help fix this but I've failed to get that right .... if that is the correct answer in this case.

For reference, this is the release notes for FV.

Steps to Reproduce

• Clone my repo which has everything setup.
• Compile and Run-all-tests

or

• Create a new empty NancyFX website
• Add Nancy.Validation.FluentValidation and update all nugets to latest.
• Add a simple POST route
• Bind to a model and validate.
• Create a Test project (I was using xUnit)
• Create a test that hits that POST endpoint. 💥

System Configuration

• Nancy version: 1.4.3
• Nancy host
  
  
  
  • OWIN
  
  
• Other Nancy packages and versions:
  
  
  
  • Nancy.Owin 1.4.1
  
  
  • Nancy.Validation.FluntValidation 1.4.1
  
  
  • Nancy.Testing 1.4.1
  
  
• Environment (Operating system, version and so on):
  
  
  
  • Windows 10 Pro
  
  
  • VS 15.2 (26430.12)
  
  
• .NET Framework version: 4.7

Update:

• Fixed correct Nancy version.

[PureKrome]

CC @phillip-haydon

[xt0rted]

Binding redirects won't work, they changed the api in v7.

src\Nancy.Validation.FluentValidation\AdapterBase.cs
@@ -43,7 +43,7 @@
             {
                 return new MessageFormatter()
                     .AppendPropertyName(displayName ?? rule.GetDisplayName())
-                    .BuildMessage(validator.ErrorMessageSource.GetString());
+                    .BuildMessage(validator.ErrorMessageSource.GetString(null));
             };
         }
     }

I can send a PR for this in a little bit.

[thecodejunkie]

Aye, we can never guarantee that any of our packages work with any other version, of a 3rd party dependency, than the one we've built against 😉

[PureKrome]

@thecodejunkie Sure - so is the problem with Nancy or with FV?

if FV have changed their signature(s) then shouldn't we look at upgrading nancy's packages, then?

---

@xt0rted mate - thanks! Did u just

• clone 1.4.3 version of nancy (whatever branch that is .. ?? master??)
• update FV package to v7
• compile ... and boom...

[thecodejunkie]

The problem is with neither, it's just how thing works. They've changes signatures so we're binary compatible with that version anymore. We should look into bumping our dependency version (we're due checking all our third party dependencies), but we have to think about what that means for the end user since there could be breaking changes when we bump the version of a 3rd party dependency, especially when we bump a major version

• Their API can have changed which would require changes to the Nancy integration code
• Their API can have changed which requires no changes from us, but would require changes to usages of the dependencies API in user applications

[PureKrome]

but we have to think about what that means for the end user since there could be breaking changes when we bump the version of a 3rd party dependency, especially when we bump a major version

So - is there a process for this? As in ... do you get a PR with a major semver bump and then ... what? How do you guys decide if there could be serious ramifications down the pipeline for other users?

Is it a simple -> "_what (if?) has broken in Nancy with the latest package version .. and if there are any busted bits because of serious API signature changes, then we (Nancy team) have a chat and see if it's OK or fix and bump, etc.... ?_"

[thecodejunkie]

Pretty that.. either we or the community PR a version bump. You'll immediately know if there are breaking changes between Nancy -> 3rd party dependency when you bump the version, since you'll most likely get either compiler errors or failing tests. As for breaking changes in the 3rd party user API.. that's pretty much always going to be the case when they've bumped a major version, and in most cases we roll with it. I'd say that's particularly true right now since we're in the process of baking 2.x so we might as well roll with the latest versions

[xt0rted]

I was on the wrong branch so that diff was from master not the 1.4 branch. It looks like Fluent Validation 6.4 is when they changed their target framework to .NET 4.5+ so there's no incoming PR. Sorry ☹️

I was planning on updating my project this week so I'll probably just fork the Fluent Validation adapter project and update it to .NET 4.5 and Fluent Validation 7.

[PureKrome]

@thecodejunkie cheers!

@xt0rted

it looks like Fluent Validation 6.4 is when they changed their target framework to .NET 4.5+ so there's no incoming PR.

um, I don't understand this quote. Do you mean: "_FV v6.4 is .net 4.5.1 (and greater) and Nancy.Validation.FV is .net 4.5 (or 3.5 .. basically < 4.5.1) ... so you need to update more things across the board to use FV .._" ??

[xt0rted]

um, I don't understand this quote. Do you mean: "FV v6.4 is .net 4.5.1 (and greater) and Nancy.Validation.FV is .net 4.5 (or 3.5 .. basically < 4.5.1) ... so you need to update more things across the board to use FV .." ??

Nancy 1.4 targets .NET 4 and FV 5.6 targets .NET 4.5 (not sure how I got 6.4 in my first comment) so you can't update the package without also retargeting the project to .NET 4.5 or greater.

[xt0rted]

@PureKrome I just threw together a project for this, will look at it more tomorrow. You can get the package off AppVeyor or my MyGet feed if you'd like to see if it works.

[PureKrome]

@xt0rted will this be going up to nuget.org in the future or always be an unofficial fork?

[xt0rted]

@PureKrome it'll go up on nuget.org once I've had a chance to test it on my project

[thecodejunkie]

If you are going to upload it to nuget.org, then please do not use the Nancy logo.. the package name is very similar to ours and I'd like to avoid confusion

[xt0rted]

@thecodejunkie is there an "official" 3rd party package logo that could be used? Serilog has one that's their logo but has a community label on it. https://github.com/serilog/serilog/issues/344#issuecomment-76080273 example 1, example 2

Could the logo guidelines be updated to mention how it should/shouldn't be used with 3rd party packages?

[thecodejunkie]

@xt0rted currently not, but we've talked about it before and I still think it's a relevant thing. @grumpydev ?

[thecodejunkie]

Perhaps something like this

There's also the option of using the inverted version for community stuff (since we use black silhouette on a white backdrop for our packages)

I think I personally prefer the black version, with just _COMMUNITY_ written on it (bottom left one)

@NancyFx/most-valued-minions

[thecodejunkie]

Oh and that's using the same font as we use in the logo 😄

[khellang]

Yes! I've proposed doing something like serilog earlier. I love the bottom left one. White on black with just "community" on it :heart:

[khellang]

What about introducing some colors and have "bootstrapper", "authentication", "host" etc. as well?

[PureKrome]

Just to get some clarification, we are talking about the Nancy.Validation.FluentValidation package right? If yes, I've always assumed the Nancy.* packages were all 'official' ones (based on the meta data in the package info, etc).

[xt0rted]

The Nancy.Validation.FluentValidation package is official, it's in this repo, but my fork isn't. That's why @thecodejunkie doesn't want me using the same package icon that the official ones use. As for the others on NuGet...there's quite a few named Nancy.* that aren't official, I'm even guilty of that with Nancy.Validation.DataAnnotations.Extensions.

I cleaned up the naming of the package and tested it out briefly in my project. So far it seems to work ok. I've pushed a pre-release up to NuGet. If you installed one of the CI builds you'll need to uninstall it and then reinstall the new one since the package name changed. I'll push a stable build once I can test it out some more. If you could give it a try as well that'd be 🎉

[PureKrome]

Hmm.. if this is a _fork_ .. then can we just get the original fixed instead?

can we start to have that discussion about "what impact will upgrading some 3rd party deps, have/do" ? I don't really want to start having forks and more random nugets up there, tbh.

[xt0rted]

We can talk about updating the v2 implementation but v1.4 targets .NET 4 which fluent validation no longer supports, hence needing to fork this.

[PureKrome]

OK - so any of the v1.4 packages will _not_ be getting reviewed+updated then?

[thecodejunkie]

@PureKrome The 1.x code branch has been in maintenance mode for quite some time now

[PureKrome]

Ah sweet! That answers things then :) Cheers!

[leonibr]

If it matters to anyone, although the required version is 3.4, the maximum version it compiles is 6.4.1