Re: Broken assembly 4.1.0.4000 reference

[Michael Powell]

Hello,

I have what I think is a broken assembly reference.

I am running against Fluent 2.0.3, and I've updated NHibernate to what
I think is 4.1.1.4000, however, the references being called out are
4.1.0.4000, which is not being found. This is well within the
documented reference constraints, such as they are. But if Fluent is
expecting an EXACT match, then the NuGet spec should just say so.

Possibly a build/deployment snafu, methinks?

Not sure if this is an NHibernate issue, or possibly a broken Fluent
reference, per se.

Running against desktop .NET framework, not .NET Core/Standard, at this point.

Thoughts?

Best,

Michael Powell

[Michael Powell]

I am receiving the following exception as well. It's been several
years since anything even touched machine.config, but I've been doing
work since then, so whatever this is, it is recent. I'm not sure why
the NHibernate reference such as it is since I am referencing NuGet
package 4.1.1.4000, supporting FluentNHibernate 2.0.3. If it's not an
NHibernate, or FluentNHibernate, thing, possibly it is a R# thing, at
least given the LOG response.

System.IO.FileNotFoundException was unhandled by user code
FileName=NHibernate, Version=4.0.0.4000, Culture=neutral,
PublicKeyToken=aa95f207798dfdb4
FusionLog==== Pre-bind state information ===
LOG: DisplayName = NHibernate, Version=4.0.0.4000, Culture=neutral,
PublicKeyToken=aa95f207798dfdb4
(Fully-specified)
LOG: Appbase = file:///C:/Users/Michael/AppData/Local/JetBrains/Installations/ReSharperPlatformVs14/
LOG: Initial PrivatePath = NULL
Calling assembly : FluentNHibernate, Version=2.0.3.0, Culture=neutral,
PublicKeyToken=null.
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image
will only be probed in default load context, like with
Assembly.Load().
LOG: Using application configuration file:
C:\Users\Michael\AppData\Local\JetBrains\Installations\ReSharperPlatformVs14\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: NHibernate, Version=4.0.0.4000,
Culture=neutral, PublicKeyToken=aa95f207798dfdb4
LOG: Attempting download of new URL
file:///C:/Users/Michael/AppData/Local/JetBrains/Installations/ReSharperPlatformVs14/NHibernate.DLL.
LOG: Attempting download of new URL
file:///C:/Users/Michael/AppData/Local/JetBrains/Installations/ReSharperPlatformVs14/NHibernate/NHibernate.DLL.
LOG: Attempting download of new URL
file:///C:/Users/Michael/AppData/Local/JetBrains/Installations/ReSharperPlatformVs14/NHibernate.EXE.
LOG: Attempting download of new URL
file:///C:/Users/Michael/AppData/Local/JetBrains/Installations/ReSharperPlatformVs14/NHibernate/NHibernate.EXE.
LOG: Attempting download of new URL file:///G:/Source/Kingdom
Software/Kingdom.Foundations/Prototype/src/Kingdom.Data.Repository.Hibernate.Fluent.Tests/bin/Debug/NHibernate.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
LOG: Attempting download of new URL file:///G:/Source/Kingdom
Software/Kingdom.Foundations/Prototype/src/Kingdom.Data.Repository.Hibernate.Fluent.Tests/bin/Debug/NHibernate/NHibernate.DLL.
LOG: Attempting download of new URL file:///G:/Source/Kingdom
Software/Kingdom.Foundations/Prototype/src/Kingdom.Data.Repository.Hibernate.Fluent.Tests/bin/Debug/NHibernate.EXE.
LOG: Attempting download of new URL file:///G:/Source/Kingdom
Software/Kingdom.Foundations/Prototype/src/Kingdom.Data.Repository.Hibernate.Fluent.Tests/bin/Debug/NHibernate/NHibernate.EXE.

HResult=-2147024894
Message=Could not load file or assembly 'NHibernate,
Version=4.0.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4'
or one of its dependencies. The system cannot find the file specified.
Source=Kingdom.Data.Repository.Hibernate.Fluent
StackTrace:
at Kingdom.Data.Repository.Hibernate.Fluent.FluentHibernateSessionFactoryConfigurationManager`1.CreateManagedConfiguration(TManagerConfig
managerCfg)
at Kingdom.Data.Repository.Hibernate.Fluent.FluentHibernateSessionFactoryConfigurationManager`1.CreateSessionFactory(TManagerConfig
managerCfg) in G:\Source\Kingdom
Software\Kingdom.Foundations\Prototype\src\Kingdom.Data.Repository.Hibernate.Fluent\Core\FluentHibernateSessionFactoryConfigurationManager.cs:line
196
at Kingdom.Data.Repository.Hibernate.Fluent.FluentHibernateSessionFactoryConfigurationManager`1.CreateSession(String
connectionString) in G:\Source\Kingdom
Software\Kingdom.Foundations\Prototype\src\Kingdom.Data.Repository.Hibernate.Fluent\Core\FluentHibernateSessionFactoryConfigurationManager.cs:line
60
at Kingdom.Data.Repository.SessionFactoryManagerBase`3.get_Item(String
connectionString) in G:\Source\Kingdom
Software\Kingdom.Foundations\Prototype\src\Kingdom.Data.Repository\Core\SessionFactoryManagerBase.cs:line
97
at Kingdom.Data.Repository.Hibernate.Fluent.Modules.MigrationManagerModule.<>c__DisplayClass2_0`1.<BuildMigrationManager>b__0(PreparingEventArgs
args) in G:\Source\Kingdom
Software\Kingdom.Foundations\Prototype\src\Kingdom.Data.Repository.Hibernate.Fluent.Tests\Modules\MigrationManagerModule.cs:line
46
at Autofac.Core.Registration.ComponentRegistration.RaisePreparing(IComponentContext
context, IEnumerable`1& parameters)
at Autofac.Core.Resolving.InstanceLookup.Activate(IEnumerable`1
parameters)
at Autofac.Core.Lifetime.LifetimeScope.GetOrCreateAndShare(Guid
id, Func`1 creator)
at Autofac.Core.Resolving.InstanceLookup.Execute()
at Autofac.Core.Resolving.ResolveOperation.GetOrCreateInstance(ISharingLifetimeScope
currentOperationScope, IComponentRegistration registration,
IEnumerable`1 parameters)
at Autofac.Core.Resolving.ResolveOperation.Execute(IComponentRegistration
registration, IEnumerable`1 parameters)
InnerException:

[Alexander Zaytsev]

Hi Michael,

1. NHibernate has fixed assembly version numbers, they do change only when minor/major version change:

- All 4.0.x assemblies have 4.0.0.4000 assembly version number (4000 is a rudimentary from prior version format meaning GA)

- All 4.1.x assemblies have 4.1.0.4000 assembly version number

- All 5.0.x assemblies have 5.0.0.0 assembly version number

- All 5.1.x assemblies will have 5.1.0.0 assembly version number

2. FluentNHibernate 2.0.3 was compiled against NHibernate 4.0.x and was not recompiled again.

3. Because NHibernate has a signed strong name, you would need to have a binding redirect in place when you update to next minor/major version.

Best Regards,

Alexander

--
You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibernate+unsubscribe@googlegroups.com.
To post to this group, send email to fluent-nhibernate@googlegroups.com.
Visit this group at https://groups.google.com/group/fluent-nhibernate.
For more options, visit https://groups.google.com/d/optout.

[Michael Powell]

I wonder if this is a similar AppDomain issue as compared to this?

https://stackoverflow.com/questions/48641137/filenotfoundexception-for-cefsharp-when-running-xunit-test

[Michael Powell]

It seems like to me that, after reviewing the exception/log in a bit
more depth, possibly FluentNHibernate's dependency on NHibernate is
based on the STRONG assembly name? Can anyone say for sure? If that's
the case, however, why depend on a NuGet version RANGE at all? Just
depend on the PRECISE NuGet version. Thoughts?

[mwpowellhtx]

On Tuesday, February 27, 2018 at 3:58:38 PM UTC-5, Alexander Zaytsev wrote:

Hi Michael,

1. NHibernate has fixed assembly version numbers, they do change only when minor/major version change:

- All 4.0.x assemblies have 4.0.0.4000 assembly version number (4000 is a rudimentary from prior version format meaning GA)

- All 4.1.x assemblies have 4.1.0.4000 assembly version number

- All 5.0.x assemblies have 5.0.0.0 assembly version number

- All 5.1.x assemblies will have 5.1.0.0 assembly version number

I'm not sure what this means? From NuGet package dependency perspective? 

2. FluentNHibernate 2.0.3 was compiled against NHibernate 4.0.x and was not recompiled again.

Fine, but let's look at the Fluent NuGet package spec: "FluentNHibernate.nuspec"

Interesting, that the reference is set to specifically: 4.0; which, if I understand NuGet package dependencies, would allow for upgrades in the patch path, i.e. 4.0.1, 4.0.2, etc.

<dependencies>

  <dependency id="NHibernate" version="4.0" />

</dependencies>

 

3. Because NHibernate has a signed strong name, you would need to have a binding redirect in place when you update to next minor/major version.

Which, obviously this is breaking down somewhere in the process. The dependency is apparently seen someone as 4.0.0, in a manner of speaking, in spite of the packaging system allowing for the patch.

So, which is it? Allowing for the version range? If not, then just say so, i.e. 4.0.0.

That said, moving forward, what are the changes coming in the next version from 2.0.3/4.0?

I paid some attention to that discussion, but was curious about what breaking changes there may be assuming that's the recommended path forward following this particular discussion.

Best Regards,

Alexander

To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibern...@googlegroups.com.
To post to this group, send email to fluent-n...@googlegroups.com.

[mwpowellhtx]

On Wednesday, February 28, 2018 at 8:25:23 AM UTC-5, mwpowellhtx wrote:

On Tuesday, February 27, 2018 at 3:58:38 PM UTC-5, Alexander Zaytsev wrote:

Hi Michael,

1. NHibernate has fixed assembly version numbers, they do change only when minor/major version change:

- All 4.0.x assemblies have 4.0.0.4000 assembly version number (4000 is a rudimentary from prior version format meaning GA)

- All 4.1.x assemblies have 4.1.0.4000 assembly version number

- All 5.0.x assemblies have 5.0.0.0 assembly version number

- All 5.1.x assemblies will have 5.1.0.0 assembly version number

I'm not sure what this means? From NuGet package dependency perspective? 

2. FluentNHibernate 2.0.3 was compiled against NHibernate 4.0.x and was not recompiled again.

Fine, but let's look at the Fluent NuGet package spec: "FluentNHibernate.nuspec"

Interesting, that the reference is set to specifically: 4.0; which, if I understand NuGet package dependencies, would allow for upgrades in the patch path, i.e. 4.0.1, 4.0.2, etc.

<dependencies>

  <dependency id="NHibernate" version="4.0" />

</dependencies>

 

3. Because NHibernate has a signed strong name, you would need to have a binding redirect in place when you update to next minor/major version.

Which, obviously this is breaking down somewhere in the process. The dependency is apparently seen someone as 4.0.0, in a manner of speaking, in spite of the packaging system allowing for the patch.

So, which is it? Allowing for the version range? If not, then just say so, i.e. 4.0.0.

It's actually worse than that. Depending on "4.0" to NuGet sees that as NHibernate (>= 4.0). Which is fine as long as we're talking about API compatibility.

Thus far, my take away includes that I am basically stuck a 4.0.0.4000 for purposes of this.

When I specify my version ranges, it depends on the dependency maintainer's policies, of course, but let's say that API compatibility remains consistent for a major version. Then I would want my dependency something like this:

<dependencies>

  <dependency id="NHibernate" version="[4,5)" />

</dependencies>

[mwpowellhtx]

On Tuesday, February 27, 2018 at 3:58:38 PM UTC-5, Alexander Zaytsev wrote:

Hi Michael,

1. NHibernate has fixed assembly version numbers, they do change only when minor/major version change:

- All 4.0.x assemblies have 4.0.0.4000 assembly version number (4000 is a rudimentary from prior version format meaning GA)

- All 4.1.x assemblies have 4.1.0.4000 assembly version number

- All 5.0.x assemblies have 5.0.0.0 assembly version number

- All 5.1.x assemblies will have 5.1.0.0 assembly version number

I'm still confused as to precisely where in the dependency resolution chain this is breaking down. Are you saying that Fluent is referencing NHibernate via strong name? i.e. if the dependency is 4.0 then that is locked to 4.0.0.4000 forever and ever, Amen?

When this is CLEARLY NOT the case when you examine the version history:

https://www.nuget.org/packages/NHibernate/

Just in the case of 4.0, for instance, there have been a handful of patch releases, v4.0.1, v4.0.2, v4.0.3, v4.0.4, never mind a whole MINOR release at v4.1.1. Prior to a 5.x release, upon which Fluent v2.1 depends, v5.0.3 specifically.

https://www.nuget.org/packages/FluentNHibernate

Which is a shame because anyone subscribing to Fluent prior to 2.1 is unable to leverage those patch releases.

For future reference, I will reiterate, what breaking changes there might have been migrating to 2.1?

To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibern...@googlegroups.com.
To post to this group, send email to fluent-n...@googlegroups.com.

[Oskar Berggren]

The "assembly version" is the version of the "API specification" and remains the same withing all 4.0.x releases and 4.1.x releases, respectively. This allows bug fix/security releases/minor improvement releases (e.g. 4.0.1, 4.0.2 etc to be drop in replacement not requiring recompile or binding redirect, since the strong name stays the same).

It is up to the persons releasing FluentNHibernate to provide an updated version of FluentNHibernate that has been compiled with NH 4.1, or if that is not available a binding redirect must be used.

/Oskar

To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibernate+unsubscribe@googlegroups.com.
To post to this group, send email to fluent-nhibernate@googlegroups.com.

[Michael Powell]

What I'm saying is that any strong name reference effectively BREAKS
the migration path. That's not an NHibernate thing but a Fluent thing.
The migration path from an NHibernate POV is established: 4.0 -> 4.0.1
-> 4.0.2, etc. While the package spec may permit that to occur, i.e.
x>=1.0, the strong name reference DOES NOT. THAT is the point here.
Effectively who ever put out the Fluent package isolated the migration
path on the 4.0.0.4000 island.

> You received this message because you are subscribed to a topic in the

> Google Groups "Fluent NHibernate" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/fluent-nhibernate/iNAlKcL1bRI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Michael Powell]

On Wed, Feb 28, 2018 at 1:35 PM, Michael Powell <mwpow...@gmail.com> wrote:
> What I'm saying is that any strong name reference effectively BREAKS
> the migration path. That's not an NHibernate thing but a Fluent thing.
> The migration path from an NHibernate POV is established: 4.0 -> 4.0.1
> -> 4.0.2, etc. While the package spec may permit that to occur, i.e.
> x>=1.0, the strong name reference DOES NOT. THAT is the point here.
> Effectively who ever put out the Fluent package isolated the migration
> path on the 4.0.0.4000 island.

To be fair, I'm on the fence how much of this is Fluent vs R#; I think
possibly R#, but I'm not discounting the underlying NuGet and/or
assembly references themselves until I know more definitively one way
or another.