Error with NinjectValidatorFactory after updating FluentValidation with Nuget - asp.net-mvc

I have the following line of code in my NinjectModule:
Bind<IValidatorFactory>().To<NinjectValidatorFactory>().InSingletonScope();
This used to work fine, but after doing a bunch of updates with Nuget, I'm getting the following errors:
Error 3 The type 'Ninject.Web.Mvc.FluentValidation.NinjectValidatorFactory' cannot be used as type parameter 'TImplementation' in the generic type or method 'Ninject.Syntax.IBindingToSyntax.To()'. There is no implicit reference conversion from 'Ninject.Web.Mvc.FluentValidation.NinjectValidatorFactory' to 'FluentValidation.IValidatorFactory'. D:\Projects\Current...\Configuration\MainModule.cs 19 13
Error 4 The type 'FluentValidation.ValidatorFactoryBase' is defined in an assembly that is not referenced. You must add a reference to assembly 'FluentValidation, Version=2.0.0.0, Culture=neutral, PublicKeyToken=a82054b837897c66'. D:\Projects\Current...\Configuration\MainModule.cs 19 13
It's true that I don't have a reference to FluentValidation Version=2.0.0.0, but I do have a reference to FluentValidation Version=3.4.0.0.
According to the metadata...
IValidatorFactory and ValidatorFactoryBase are defined in Assembly FluentValidation.dll.
NinjectValidatorFactory is defined in Assembly Ninject.Web.Mvc.FluentValidation.dll.
In my References folder, I have FluentValidation v3.4.0.0 and Ninject.Web.Mvc.FluentValidation v3.0.0.0.
I don't get why the compiler thinks I need FluentValidation Version=2.0.0.0.
Am I doing something wrong, or is this an issue with the Nuget package?

It looks as if the problem is that FluentValidation used to be a signed assembly but is now an unsigned assembly. Ninject.Web.Mvc.FluentValidation, however, still thinks FluentValidation is signed.
If you look at these two assemblies in ILSpy, you will notice the following:
Ninject.Web.Mvc.FluentValidation references FluentValidation with the following attributes: FluentValidation, Version=2.0.0.0, Culture=neutral, PublicKeyToken=a82054b837897c66
The latest version of FluentValidation, however, has different attributes: FluentValidation, Version=3.4.0.0, Culture=neutral, PublicKeyToken=null
Note that PublicKeyToken has changed to null (unsigned).
Hopefully, there will be a fix to this soon. Meanwhile, the options are to roll back to the previous FluentValidation or fix the reference via a new fork.
Update
Just posted a bug report to Ninject.Web.Mvc.FluentValidation. Hopefully, this will ensure that the issue is resolved quickly.
Update 2
Just in case anyone missed it, the comment from #dismissile below contains a good solution. I gave it a try and it pretty much works. Here's a slight variation with more detail:
Remove all Nuget packages that contain "FluentValidation".
Use Nuget to install FluentValidation-Signed.
Use Nuget to install FluentValidation.MVC3-Signed (or MVC4-Signed)
Using Package Manager Console, enter the following:
Install-Package Ninject.Web.Mvc.FluentValidation -IgnoreDependencies
Note: I didn't need to manually add a binding redirect to my Web.config (although the Nuget package added one automatically).

The problem is correctly identified by DanM. Here is the comment from the project coordinator
"Going forward the primary nuget package will no longer be strongly named.
A separate package, FluentValidation-signed can be used if you absoloutely need strong naming, but it is recommended that you use the unsigned version." Jeremy Skinner

Related

Nesper engine always tries to load types from Nesper.dll first

Every time I try to add a new type to my nesper engine, I get the following exception thrown in the nesper engine.
Could not load type 'K2Common.Order' from assembly 'NEsper, Version=4.8.0.0, Culture=neutral, PublicKeyToken=null'.
The engine eats the exception and then finds the proper type in my assembly as it iterates over each loaded assembly.
Is there a way to prevent nesper from searchign for a type in the nesper.dll first?
Among the configuration settings, there is a "import" list that you could try to clear out.
You can also define the SearchPath (assemblies in this case) that NEsper will use to find its assemblies. Though in practice, the best answer is to use the AssemblyQualifiedName. Using the typed functions i.e. AddEventType() will automatically use the AssemblyQualifiedName.
In the end I resolved the problem by using the Qualified assembly name
configuration.AddEventType("OrderEvent", typeof(Order).AssemblyQualifiedName);
instead of the below:
configuration.AddEventType("OrderEvent", typeof(Order).FullName);

[A]System.Data.SQLite.SQLiteConnection cannot be cast to [B]System.Data.SQLite.SQLiteConnection

I've got a bit of a heisenbug on my hands now, and I'm looking to find some help with it.
I have a Windows service that uses System.data.sqlite. In rare cases (apparently only on Windows Vista, but this may be a red herring), the exception occurs: [A]System.Data.SQLite.SQLiteConnection cannot be cast to [B]System.Data.SQLite.SQLiteConnection...
Unfortunately, we haven't been able to repeat this bug here in the office, and have limited access to the machines where it occurs. I've tried messing with the GAC (registering and de-registering assemblies of different versions and providence using gacutil), and the app seems to do fine on my development machine.
Any idea how I might try to reproduce this or what kinds of situations can cause this? Have you run into bugs like this that only occur on Windows Vista?
Here is the fullest stack trace I have:
[A]System.Data.SQLite.SQLiteConnection cannot be cast to [B]System.Data.SQLite.SQLiteConnection.
Type A originates from 'System.Data.SQLite, Version=1.0.66.0. Culture=neutral, PublicKey Token=db937bc2d44ff139'
in the context 'Default' at location 'C:\Program Files\ultracorp\System.... [yes, ellipses are the best I have right here, I know...]
Server stack trace:
at System.Data.SQLite.SQLiteCommand.set_DbConnection(DbConnection value)
at System.Data.Common.DbCommand.set_Connection(DbConnection value)
at System.Data.Common.Utils.CommandHelper.SetStoreProviderCommandState(EntityCommand entityCommand, EntityTransaction entityTransaction, DbCommand storeProviderCommand)
at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
at System.Data.Objects.Internal.ObjectQueryExecutionPlan.Execute[TResultType](ObjectContext context, ObjectParameterCollection parameterValues)
at System.Data.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption)
at System.Data.Objects.ObjectQuery`1.System.Collections.Generic.IEnumerable<T>.GetEnumerator()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
at System.Data.Objects.ELinq.ObjectQueryProvider.<GetElementFunction>b__1[TResult](IEnumerable`1 sequence)
at System.Data.Objects.ELinq.ObjectQueryProvider.ExecuteSingle[TResult](IEnumerable`1 query, Expression queryRoot)
at System.Data.Objects.ELinq.ObjectQueryProvider.System.Linq.IQueryProvider.Execute[S](Expression expression)
at System.Linq.Queryable.FirstOrDefault[TSource](IQueryable`1 source)
at UltraCorp.DataWrangler.Models.WidgetsTable.getWidget(WidgetsEntities dbConn)
at UltraCorp.DataWrangler.Models.WidgetsTable.getWidget()
at UltraCorp.DataWrangler.Models.WidgetsTable.getUser()
at UltraCorp.DataWrangler.Infrastructure.DataWranglerTray.getUser()
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
Edit: In my app.config, I have provider=System.Data.SQLite; in a couple of places. Notice that there's no strong name or version number. I suspect what may be happening is that in some instances, the DLL containing the data models gets loaded, and when Entity Framework sees that that provider is requested, it chooses a System.Data.Sqlite to use. Then, later when some code happens, a different DLL is loaded according to the referencing rules. This DLL, however, has a different version or strong name than the one loaded by EF, and hence the exception.
I found two other posts from users who've experienced the same issue here:
http://sqlite.phxsoftware.com/forums/t/2554.aspx
and here
http://forums.sabnzbd.org/viewtopic.php?f=6&t=3097&start=150
Are you using the GAC to deploy the SQLite assemblies?
Are you also deploying System.Data.Sqlite.Linq.dll?
You can try to deploy the SQLite dependencies to your bin folder and use strong name assembly references in your configuration file to avoid this issue for example.
I'm thinking maybe this can be reproduced by having conflicting versions of System.Data.Sqlite.dll and\or System.Data.Sqlite.Linq.dll on the same system, but the built-in .net framework assembly resolver will attempt to load one of the in-compatible versions anyway because the dependencies are not strongly referenced by version and\or public key token information.
For debugging \ logging purposes, you can hook into the AssemblyLoad and\or AssemblyResolve AppDomain events:
http://msdn.microsoft.com/en-us/library/1dw188c1.aspx
As a work-around to resolve the issue without re-compiling, copy the missing dependencies to the bin folder and update the configuration file accordingly.
Edit
Also see these posts for more information and a tested solution:
http://sqlite.phxsoftware.com/forums/p/2021/8867.aspx
http://sqlite.phxsoftware.com/forums/p/2333/9615.aspx
I also received this error when trying to create an ADO.NET Entity Data Model.
My solution was loading the design type components for Visual Studio 2013. My download was 'sqlite-netFx451-setup-bundle-x86-2013-1.0.99.0.exe' found on:
https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
My Nuget Packages for SQLite were not matching my designer components.
Try to manually delete the files in ProjectFolder/Packages, remove the references to SQLite from your project and download the new package versions from NuGet or whereever you download them from.

FSharp.Core.sigdata not found alongside FSharp.Core

I'm trying to use F# for an ASP.NET MVC application. One my controller actions sends an F# list to the view, so I write:
<%# Page Language="C#" Inherits="ViewPage<FSharpList<int>>" %>
Of course, for this to work, I have to add Microsoft.FSharp.Collections to the namespaces element in my web.config:
<add namespace="Microsoft.FSharp.Collections"/>
and add a reference to FSharp.Core, in the assemblies element:
<add assembly="FSharp.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
As soon as I add this assembly reference, every view (whether it uses an F# type or not) fails with this error:
error FS1221: FSharp.Core.sigdata not found alongside FSharp.Core
I can work around this by not having any F# specific types in my views, but what's the reason for this error? Also, where's FSharp.Core.sigdata ? It's not in my GAC and I can't find it anywhere.
You'll find it with the Reference Assemblies, as sigdata and optdata are design-time things (but I guess CodeDom needs them too?), e.g.:
C:\Program Files\Reference Assemblies\Microsoft\FSharp\2.0\Runtime\v2.0\FSharp.Core.dll
C:\Program Files\Reference Assemblies\Microsoft\FSharp\2.0\Runtime\v2.0\FSharp.Core.optdata
C:\Program Files\Reference Assemblies\Microsoft\FSharp\2.0\Runtime\v2.0\FSharp.Core.sigdata
If you copy those next to the FSharp.Core that the app is using, it will probably work.

T4MVC renderpartial and Spark views

#Html.RenderPartial(MVC.Shared.Views._Sorter);
throws error =>
There is no build provider registered for the extension '.spark'. You can register one in the section in machine.config or web.config. Make sure is has a BuildProviderAppliesToAttribute attribute which includes the value 'Web' or 'All'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Web.HttpException: There is no build provider registered for the extension '.spark'. You can register one in the section in machine.config or web.config. Make sure is has a BuildProviderAppliesToAttribute attribute which includes the value 'Web' or 'All'.
Any ideas what might be wrong?
Adding this to web.config=>system.web=>compilation
<buildProviders>
<add extension=".spark" type="System.Web.Compilation.PageBuildProvider" />
</buildProviders>
Forces app to build spark view as webforms view and produces ${Something.something} all around. So - what's an equivalent for spark viewengine?
Can you please try to make the following change to T4MVT.tt. In the method ViewsFolderInfo.AddView, change the line:
Views[viewFieldName] = GetVirtualPath(item);
to
Views[viewFieldName] = viewFieldName;
If that works well, we can just add a switch to the settings file that makes it do this instead of the default full path.
Let me know how that goes!
Note that MVC.Shared.Views._Sorter is just a constant with the path to the view. If you were to write this code without T4MVC, what exact string would you pass in there?
Maybe Spark has different requirements in the type of view paths it accepts here? If needed, we can tweak T4MVC to make this work, but I'd like to fully understand the Spark behavior outside of T4MVC first.

Spark View Engine "An assembly with the same simple name" error

I am trying out the Spark view engine with ASP MVC but get the error below when displaying a view. The view references model objects that are in a different assembly to the main web application (MyApp.Model.dll). I am stuck on the cause or resolution to this.
Dynamic view compilation failed.
0,0): error CS1704: An assembly with the same simple name
'MyApp.Model, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
It sounds like you're referencing the same assembly multiple times in your view. Instead of using the <use assembly=""> element you might want to use the <use namesace=""> element
Craig I got the same problem, if I modify some class in assembly X and do a build, I got this error at runtime for the assembly X.
But after a "rebuild" (not "build") it's working.
For me it has been in the middle of a project. It comes maybe from an update ?
Matthieu

Resources