2.0 goes stable

[Gleb Chermennov]

As year end approaches, I thought I'd tie up loose ends - 2.0 stable release just hit NuGet. Vintage package will upgrade later today or tomorrow, release notes to follow.

Nothing glorious this time. Code was tested with NH 4.0.2.x, so you shouldn't have any problems. 

Another thing to notice - due to a glorious popularity of NuGet package targeting .NET 3.5, its last release will be next year. If someone interested in further bug fixes, I'd be happy to transfer package ownership. For me maintenance costs are far more than the outcome. I did have fun merging rake script between two branches, though.

[Andreas Eriksson]

Great news, i am looking forward to trying out the new release.

[Gleb Chermennov]

I screwed up a bit - informational version of published assemblies still says it's alpha. But it's not :)

[Andreas Eriksson]

The dll is not signed. I get this error in visual studio.

Error    73    Assembly generation failed -- Referenced assembly 'FluentNHibernate' does not have a strong name

[Gleb Chermennov]

I have no intention on adding strong name. It was dropped since version 1.4.0, I believe.

2014-12-22 16:28 GMT+03:00 Andreas Eriksson <andreas.o...@gmail.com>:

The dll is not signed. I get this error in visual studio.

Error    73    Assembly generation failed -- Referenced assembly 'FluentNHibernate' does not have a strong name

--
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/IJ97IPPUc8Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fluent-nhibern...@googlegroups.com.
To post to this group, send email to fluent-n...@googlegroups.com.
Visit this group at http://groups.google.com/group/fluent-nhibernate.
For more options, visit https://groups.google.com/d/optout.

--

С уважением,
Чермённов Глеб

[Andreas Eriksson]

May I ask why it was dropped?

I think this can cause issues for everyone that signs their assemblies as the FluentNHibernate.dll must now be manually signed before building.

P.S. It worked in 1.4.0

[Gleb Chermennov]

I'm against it. For me and thousands of .NET developers, it's just a necessary constraint. 

[Alexander Zaytsev]

"thousands .NET developers"? Oh no... I believe the correct number is 5 or 10 persons.

--
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-nhibern...@googlegroups.com.

[Gleb Chermennov]

I think the only popular OSS project that provides signed assemblies is AutoMapper. But I didn't check explicitly.​

[Alexander Zaytsev]

Basically every package from first 2 pages on nuget provides strongly named assembly

Json.NET

AutoMapper

Antlr3

Nunit

Log4Net

Moq

HtmlAgilityPack

itextsharp

WPFToolkit

Unity

Autofac

NHibernate

EntityFramework

Ninject

Castle.Windsor

The only popular packages which do not provide strong name are StructureMap and ServiceStack (provides both signed and unsigned versions).

But you can not relay on the fact that someone else uses (or not) SN.

[Gleb Chermennov]

I guess I'm in good company 

[Andreas Eriksson]

Why is it a "constraint" to use strong name? I think a lot of people would appreciate a strong name version as it is required for ClickOnce and visual studio plugins.

You can still do drop in replacements by using binding redirects or by only updating the file version and not the assembly version when releasing a bugfix.
http://msdn.microsoft.com/en-us/library/eftw1fys%28v=vs.110%29.aspx

I think a privatelely kept signing key (shared between inner devs) that is not part of the repository and a public key in the repository is good for everyone, as it allows users that download the nuget package to verify the source of the dll. I guess you already keep the username/password for publishing the nuget package outside of the repository so this is not much different.

/Andreas

[Gleb Chermennov]

​And what are the odds of Fluent NHibernate being used to write Visual Studio plugins?​ ClickOnce is theoretically possible, but I still find it highly unlikely that you query your database from client application directly.

I understand we come from completely different perspectives. If you need latest release signed - you're welcome to create a separate nuget package and maintain your own fork.

[Andreas Eriksson]

Was kinda hoping not having to create my own as it takes away the simplicity of using nuget.

May I ask what the reason was for not using strong name?

[Gleb Chermennov]

Jeremy Miller wrote a post about it, it sums up all the problems pretty well.

I heard strong naming is absent from future .NET releases, so even Microsoft is giving up on that. 

Why is it that you want strong name for Fluent NHibernate? Do you build libraries or NuGet packages that depend on it?

[Andreas Eriksson]

We use strong name signing for our corporate product which means that every loaded assembly must be strong named as well.
Everything else we use is strong named, NHibernate, log4net etc.

Jeremy only lists his problems and manual errors and it seems that thoose could have been soved with binding redirects.

You still didn't answer my question. What is the reason for not using strong name in Fluent NHibernate?

[Alexander Zaytsev]

On Wed, Dec 24, 2014 at 1:25 AM, Gleb Chermennov <thebitt...@gmail.com> wrote:

Why is it that you want strong name for Fluent NHibernate? Do you build libraries or NuGet packages that depend on it?

I do.

[Alexander Zaytsev]

Ah my gosh. Now I need to rebuild all my libraries which depend on FNH. WTF!

[Alexander Zaytsev]

According to NuGetMustHaves there are 91 packages dependent on FNH http://nugetmusthaves.com/Package/FluentNHibernate