Assembly MvvmCross.HotTuna.CrossLibraries.4.0.0-beta3 / Cirrious.MvvmCross.dll

[PeterBurke]

After upgrading my workings to latest, all the projects except for the PCL have compilation errors.

The error is of the form: error CS0012: The type 'MvxViewPresenter' is defined in an assembly that is not referenced. error CS0012: The type 'IMvxViewPresenter' is defined in an assembly that is not referenced. You must add a reference to assembly 'Cirrious.MvvmCross, Version=4.0.0.0, Culture=neutral, PublicKeyToken=e16445fd9b451819'.

So I completely removed these packages both as references and physically removed the download from the packages directory, and then re-downloaded and reinstalled the package: MvvmCross.HotTuna.CrossLibraries.4.0.0 Beta3 from Nuget.

The issue does not go away. The issue is that the downloaded assembly 'Cirrious.MvvmCross, Version=4.0.0.0, Culture=neutral is not signed as required by the package referencing it. That package presumably is Cirrious.MvvmCross.Forms.Presenter 4.0.0 Beta2 from NNuGet.

I will now get the latest source for this package and investigate further, possibly building temp versions to fix the code.

I do not ask questions because I know you are all busy, plus I have not completely identified the issue. But if if you can help as it being something you did recently, let me know.

[martijn00]

I think this might be related to https://github.com/MvvmCross/MvvmCross/pull/1095

If you don't get the versions right things will break.

[Cheesebaron]

A binding redirect would probably also fix this.

[PeterBurke]

I now have proof that my hunch was correct i,e.Cirrious.MvvmCross.Forms.Presnter.Core references Cirrious.MvvmCross requiring version 4.0.0.0 plus public key. The version numbers match but the later has not been signed.

I have highlighted the assembly name attribute in each of these screenshots.

Not sure about using an assembly redirect, doubt that it would work because the versions are the same, and also security must surely make it very difficult to substitute another assembly that does not have a strong name and same key.

It would seem that I need to REPO the forms presenter project and recompile it without a strong name, but that might be thwarted by the rule that once you give an assembly a strong name then all of its references must also have a strong name. So I might have to request that Cirrious.MvvmCross 4.0.0.0 be given a strong name and the NuSpec updated. Heaven knows what else that might break!

I do understand the issue 1095 but it seems that everything or nothing should have a strong name!

[martijn00]

I guess there has been a mistake somewhere. We decided some time ago to not use strong naming. Maybe this was changed somewhere?

[PeterBurke]

Thanks Matijn

I cannot find any specific previous discussions where this issue was resolved one way or the other.

Backtracking from MvvmCross/pull/1095 to MvvmCross/issues/740 to octokit.net/issues/405 provides a clear statement.

There is a difference between signing an assembly with private key in an sn file that anyone can download from GitHub, and signing it with an SSL Certificate. Signing it with an open source sn file still happens even though it offers no real protection because without the sn the assembly delivered to NuGet cannot be referenced by someone writing another assembly that will have an sn.

Shiftkey lists popular packages that have sn's: Newtonsoft.Json, NUnit, NLog, Ninject, DotNetOpenAuth, log4net, AutoMapper, Castle. There is a vague reference by david fowler that the need for a strongly named assembly not to be able to reference weakly named assemblies will go in vNext. But we are not there yet.

I will get around my immediate problem via a local REPO, but I think we need to decide this issue, and I would like to hear Cheesebaron's opinion.

[martijn00]

You say to decide this issue, but what is the solution then? Should we revert the version numbers to fix this?

[PeterBurke]

After cloning the MvvmCross-Forms repo it appears that the strong name reference is in the csproj files. It only impacts two of the referenced assemblies and the output FormsPresenters themselves do not have strong names.

This is the 4.0.0.0-Beta2 of MvvmCross-Forms updated by Tomasz about a month mostly just the version number. More than likely Tomasz was unaware that he had referenced two SN assemblies. The mystery though is where they came from. This is why I want Tomasz to advise on what to do.

I am happy to issue a pull request that will remove them if that's what we want to do.

[martijn00]

Yes a PR for this would be good. I think we might have to check the other repo's for this too.