I am trying to deserialize a JSON string that was serialized by JSON.Net 4.0 r3 itself. The settings are the same for serialization and deserialization. The following exception occurs:
Could not find type
'System.Collections.Generic.List`1[[System.Drawing.PointF,
System.Drawing]]' in assembly '"mscorlib, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"'
After turning on "stop when BindingFailure is thrown", I see the problem is in the following part (JSON.Net source code, DefaultSerializationBinder.cs):
if (assemblyName != null)
{
Assembly assembly;
#if !SILVERLIGHT && !PocketPC
// look, I don't like using obsolete methods as much as you do but this is the only way
// Assembly.Load won't check the GAC for a partial name
#pragma warning disable 618,612
assembly = Assembly.LoadWithPartialName(assemblyName);
#pragma warning restore 618,612
#else
assembly = Assembly.Load(assemblyName);
#endif
if (assembly == null)
throw new JsonSerializationException("Could not load assembly '{0}'.".FormatWith(CultureInfo.InvariantCulture, assemblyName));
Type type = assembly.GetType(typeName); // BindingFailure here
if (type == null)
throw new JsonSerializationException("Could not find type '{0}' in assembly '{1}'.".FormatWith(CultureInfo.InvariantCulture, typeName, assembly.FullName));
}
The error shown at the point of BindingFailure is
The assembly with display name 'System.Drawing' failed to load in the
'LoadFrom' binding context of the AppDomain with ID 1. The cause of
the failure was: System.IO.FileNotFoundException: Could not load file
or assembly 'System.Drawing' or one of its dependencies. The system
cannot find the file specified.
The operating system is Windows 7, 64-bit. I am using Visual Studio 2010 and targeting this application for Framework v4. The target is not Silverlight or PocketPC.
Why would it fail to load "System.Drawing" in this case? Where should I start investigating whether this is a JSON.Net issue or a problem with my Framework 4.0 installation?
Thanks in advance.
It turns out the issue is related to JSON.Net. I used to use the following setting
jsonSerializerSettings = new JsonSerializerSettings
{
TypeNameHandling = TypeNameHandling.All
};
This was because of a suggestion in a post (that involved deserializing generic collections like List). It was suggested that full type information would help with JSon.Net errors about the "Cannot instantiate abstract base classes" error message.
If I change it to
jsonSerializerSettings = new JsonSerializerSettings
{
TypeNameHandling = TypeNameHandling.Auto
};
it works fine. Interestingly, some type information does not get emitted, I do not get the BindingFailure and the deserialization works fine. I have no idea why it did not work with "Auto" in the first place.
Related
I want to unit test my cshtml files to ensure they compile successfully as recently I've had some issues where at run time there were failures due to the views expecting properties that weren't present. I am trying to use RazorEngine to check this, and here is my attempt at a unit test:
public void LayoutCshtml_AnyCase_ViewCompilesSuccessfully()
{
var model = new Model();
var templateName = File.ReadAllText("PathToView/_Layout.cshtml");
var result = Engine.Razor.RunCompile(templateName, "key", typeof(Model), model);
//Assertion will go here
}
I will add the assertion later but at the moment just want the view to compile. The templateName correctly picks up the right .cshtml but the result fails because of error:
The predefined type
'System.Runtime.CompilerServices.ExtensionAttribute' is defined in
multiple assemblies in the global alias;
Is anyone familiar with using RazorEngine to test please?
In my ASP.NET MVC 5 application I'm trying to access the Request.InputStream property but I get the following exception:
System.NullReferenceException: Object reference not set to an instance of an object.
at Telerik.Web.UI.Upload.RequestParser.MergeArrays(Byte[] array1, Byte[] array2)
at Telerik.Web.UI.Upload.RequestParser.get_FirstBoundary()
at Telerik.Web.UI.Upload.RequestParser..ctor(Byte[] boundary, Encoding encoding, RequestStateStore requestStateStore)
at Telerik.Web.UI.Upload.ProgressWorkerRequest.get_Parser()
at Telerik.Web.UI.Upload.ProgressWorkerRequest.UpdateProgress(Byte[] buffer, Int32 validBytes
at Telerik.Web.UI.Upload.ProgressWorkerRequest.GetPreloadedEntityBody()
at System.Web.HttpRequest.GetEntireRawContent()
at System.Web.HttpRequest.get_InputStream()
As you can see, the exception is thrown by a Telerik component. I'm indeed using Telerik web controls in my project but none of them are related to this controller. The exception occurs even if I generate a request using a tool. Looks to me like Telerik somehow injected this ProgressWorkerRequest object into my HttpRequest.
Any clues on how to get rid of it?
It doesn't have to be related to your controller. It is related to the process that the Telerik uploader is conducting and is not something to "get rid of". Basically, it is telling you that the Telerik uploader process didn't complete because it didn't find what it was expecting to.
Since Telerik controls are generally straightforward to use, you should only need something like this to get the input stream for your file:
public ActionResult UploadFile(IEnumerable<HttpPostedFileBase> fileUploader)
{
if (Request.Files.Count == 1)
{
string fileName = Request.Files[0].FileName;
Stream s = Request.Files[0].InputStream;
int size = Request.Files[0].ContentLength;
byte[] myFile = new byte[length];
s.Read(myFile, 0, size);
// Now, myFile should have the file, in bytes
}
}
If you are not getting the file, I would ensure the application has the permissions via the account it is acting under (either yours, or a service account, if a web application) to the resource you are pointing at.
MVC3 EF5. It's running well. But when I update model from database, builds successfully but I got the exception above on the last line. When I last updated from database it was 2-3 months ago, and it was fine.
public static ObjectContext GetContext()
{
Assembly testAssembly = Assembly.GetExecutingAssembly();
Type calcType = testAssembly.GetType("Model.Entities");
return (ObjectContext)Activator.CreateInstance(calcType);
}
Newer versions of Entity Framework provide DbContext, as opposed to the ObjectContext that was <= EF 4.0. However, it is still possible to return a reference to the ObjectContext via IObjectContextAdapter
Assembly testAssembly = Assembly.GetExecutingAssembly();
Type calcType = testAssembly.GetType("Model.Entities");
var entities = (DbContext)(Activator.CreateInstance(calcType));
return ((IObjectContextAdapter)entities).ObjectContext;
Personally however, I would instead look at upgrading your code to return the DbContext, as it is more advanced.
I have got my PCL model to build now, which took a bit of time making plug-ins, however now in my Android UI project I get two errors when building it.
First error is:
The type 'System.Collections.ObjectModel.ObservableCollection`1<T0>' is defined in an assembly that is not referenced.
You must add a reference to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e,
Retargetable=Yes'. C:\ENM\Main\src\prod\Mobile\Stakeholder\UI.Android.vNext\Views\LocationsMapView.cs 40 32 UI.Android.vNext
The second error is:
foreach statement cannot operate on variables of type
'System.Collections.ObjectModel.ObservableCollection`1<BK.EMS.Stakeholder.Model.ViewModels.LocationViewModel>'
because 'System.Collections.ObjectModel.ObservableCollection`1<BK.EMS.Stakeholder.Model.ViewModels.LocationViewModel>'
does not contain a public definition for 'GetEnumerator'
C:\ENM\Main\src\prod\Mobile\Stakeholder\UI.Android.vNext\Views\LocationsMapView.cs 40 32 UI.Android.vNext
I have referenced the System.Windows assembly from the System.Windows.Droid project, which is supposed to forward ObservableCollection<>.
The lines where the error occurs:
private void AddLocationOverlays()
{
if (_itemizedOverlay.Size() > 0) _itemizedOverlay.ClearOverlayItems();
RunOnUiThread(() =>
{
foreach (var location in ViewModel.Locations)
{
_itemizedOverlay.AddOverlayItem(location);
}
_mapView.Invalidate();
});
}
The Locations property in my ViewModel looks like this:
public ObservableCollection<LocationViewModel> Locations
{
get { return _locations; }
set
{
_locations = value;
RaisePropertyChanged(() => Locations);
}
}
Nothing too complicated and works fine in the non-PCL models...
So how do I get around and fix this?
We now have a solution to this problem - see fix from Daniel Plaisted in Portable Class Library strong assembly reference problems in MonoTouch/MonoDroid
This fix is checked in at https://github.com/slodge/MvvmCross/commit/f6a88048467838e5ac5ca687744dc0b2d1958aa8
Update : See other answer. It appears we now have a solution to this problem!
I believe this is linked to this problem - Portable Class Library strong assembly reference problems in MonoTouch/MonoDroid
Which is linked to: https://github.com/slodge/MvvmCross/issues/41
This is raised with Xamarin as a bug: https://bugzilla.xamarin.com/show_bug.cgi?id=8035 and
I'm afraid I don't understand the recommended Strong Signing solutions right now.
Please upvote the bug report to alert the Microsoft PCL and Xamarin teams about this. The MS and Xamarin teams are talking to each other on this (albeit through me!), and I am hopeful we will find a way for either Microsoft or Xamarin to ship some signed DLLs.
In the meantime, some possible workarounds are:
Use IEnumerable access instead of ObservableCollection - the collection can still be an ObservableCollection instance, just don't reference it as an ObservableCollection in the UI code.
Try putting your iterating code in a class library rather than in an application project - bizarre as it feels, the compiler seems perfectly happy building the same code when its in a library rather than in an application
Try building in MonoDevelop with the Mono compiler - this doesn't seem to have the same strong name reference checks.
Looking at your sample code I would just try:
private ObservableCollection<LocationViewModel> _locations;
public IEnumerable<LocationViewModel> Locations
{
get { return _locations; }
set
{
if (value != null && !(value is ObservableCollection<LocationViewModel>)
{
throw new Exception("You must Set an ObservableCollection");
}
_locations = (ObservableCollection<LocationViewModel>)value;
RaisePropertyChanged(() => Locations);
}
}
then AddLocationOverlays could stay the same.
The only problem with this would be if you then wanted to bind to INotifyCollectionChanged on this collection - but I think you can find a way around this too if needed - e.g. you could somehow expose another INotifyCollectionChanged hook, or you could try using a hack involving an intermediary class library.
I accept that for now these are workarounds not solutions :/
I have MVC areas in external libraries which have their own area registration code just as a normal MVC area would. This area registration gets called for each dll (module) and I have verified the RouteTable contains all the routes from the loaded modules once loading has been completed.
When I reference these external areas in the main site they get pulled into the bin directory and load up fine. That is, when a request is made for a route that exists in an external library, the correct type is passed to my custom controller factory (Ninject) and the controller can be instantiated.
Once I move these dll's outside of the bin directory however (say to a Modules folder), there appears to be an issue with routing. I have checked that the RouteTable has all the required routes but by the time a request makes its way into the ninject controller factory the requested type is null. From reading here an SO link here this behaviour seems to occur when ASP.NET MVC cannot find the controller matching the requested route or does not know how to make sense of the route.
When loading the modules externally I have ensured that the modules that I want loaded are loaded into the app domain via a call to Assemby.LoadFrom(modulePath);
I did some research and it appears that when attempting to load a library outside of bin you need to specify private probing in app.config as pointed out here;. I have mine set to 'bin\Modules' which is where the mvc area modules get moved too.
Does anyone have any ideas why simply moving an mvc area project outside of the bin folder would cause the requested type passed into the controller factory to be null resulting in the controller to be instantiated?
Edit:
All routes registered in external areas have the namespace of the controller specified in the route
Below is a fragment of code that creates a new Ninject kernel, reads a list of module names from a file to enable, and then goes searching for the enabled modules in the bin/Modules directory. The module is loaded via the assembly loader, has its area(s) registered and then loaded into the ninject kernel.
// comma separated list of modules to enable
string moduleCsv = ConfigurationManager.AppSettings["Modules.Enabled"];
if (!string.IsNullOrEmpty(moduleCsv)) {
string[] enabledModuleList = moduleCsv.Replace(" ", "").Split(new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries);
_Modules = enabledModuleList ?? new string[0];
// load enabled modules from bin/Modules.
var moduleList = Directory.GetFiles(Server.MapPath("~" + Path.DirectorySeparatorChar + "bin" + Path.DirectorySeparatorChar + "Modules"), "*.dll");
foreach (string enabledModule in enabledModuleList) {
string modulePath = moduleList.Single(m => m.Contains(enabledModule));
// using code adapted from from AssemblyLoader
var asm = AssemblyLoader.LoadAssembly(modulePath);
// register routes for module
AreaRegistrationUtil.RegisterAreasForAssemblies(asm);
// load into Ninject kernel
kernel.Load(asm);
}
}
This is the crux of the Ninject controller factory that receives the aforementioned Ninject kernel and handles requests to make controllers. For controllers that exist within an assembly in bin/Modules the GetControllerType(...) returns null for the requested controller name.
public class NinjectControllerFactory : DefaultControllerFactory
{
#region Instance Variables
private IKernel _Kernel;
#endregion
#region Constructors
public NinjectControllerFactory(IKernel kernel)
{
_Kernel = kernel;
}
protected override Type GetControllerType(System.Web.Routing.RequestContext requestContext, string controllerName)
{
// Is null for controller names requested outside of bin directory.
var type = base.GetControllerType(requestContext, controllerName);
return type;
}
protected override IController GetControllerInstance(System.Web.Routing.RequestContext requestContext, Type controllerType)
{
IController controller = null;
if (controllerType != null)
controller = _Kernel.Get(controllerType) as IController;
return controller;
}
}
Update on Ninject Nuget Install
I couldn't get it to install Ninject.MVC3 via NuGet for some reason. Visual Studio was giving some schemaVersion error when clicking the install button (I have installed other Nuget packages like ELMAH btw).
I did find out something else that was interesting though, and that is that if I pass in the extra module assembilies to the NinjectControllerFactory I have and search those when the type cannot be resolved it finds the correct type and is able to build the controller. This leads to another strange problem.
The first route to be requested from an external module is the /Account/LogOn in the auth and registration module. The virtual path provider throws an error here after it has located the view and attempts to render it out complaining of a missing namespace. This causes an error route to fire off which is handled by an ErrorHandling module. Strangely enough, this loads and render fine!
So I am still stuck with two issues;
1) Having to do a bit of a dodgy hack and pass in the extra module assemblies to the NinjectControllerFactory in order to be able to resolve types for Controllers in external modules
2) An error with one particular module where it complains about a namespace not being found
These two issues are obviously connected because the assembly loading just isn't loading up and making everything available that needs to be. If all these mvc areas are loaded from the bin directory everything works fine. So it is clearly a namespacing/assembly load issue.
LoadFrom load the assembly into the loading context. These types are not available to the other classes in the default Load context. Probably this is the reason why the controller is not found.
If you know which assemblies have to be loaded then you should always use Assembly.Load(). If you don't know which assemblies are depolyed in the directory then either guess from the filesnames the assembly names or use Assembly.ReflectionOnlyLoadFrom() (preferably using a temporary AppDomain) to get the assembly names. Then load the assemblies using Assembly.Load() with the assembly name.
If your assemblies contain NinjectModules you can also use kernel.Load() which does what I described above. But it only loads assemblies containing at least one module.
Read up http://msdn.microsoft.com/en-us/library/dd153782.aspx about the different assembly contexts.
Here is a small extract from the Ninject codebase. I removed the unnecessary stuff but did not try to compile or run so probably there are minor issues with this.
public class AssemblyLoader
{
public void LoadAssemblies(IEnumerable<string> filenames)
{
GetAssemblyNames(filenames).Select(name => Assembly.Load(name));
}
private static IEnumerable<AssemblyName> GetAssemblyNames(IEnumerable<string> filenames)
{
var temporaryDomain = CreateTemporaryAppDomain();
try
{
var assemblyNameRetriever = (AssemblyNameRetriever)temporaryDomain.CreateInstanceAndUnwrap(typeof(AssemblyNameRetriever).Assembly.FullName, typeof(AssemblyNameRetriever).FullName);
return assemblyNameRetriever.GetAssemblyNames(filenames.ToArray());
}
finally
{
AppDomain.Unload(temporaryDomain);
}
}
private static AppDomain CreateTemporaryAppDomain()
{
return AppDomain.CreateDomain(
"AssemblyNameEvaluation",
AppDomain.CurrentDomain.Evidence,
AppDomain.CurrentDomain.SetupInformation);
}
private class AssemblyNameRetriever : MarshalByRefObject
{
public IEnumerable<AssemblyName> GetAssemblyNames(IEnumerable<string> filenames)
{
var result = new List<AssemblyName>();
foreach(var filename in filenames)
{
Assembly assembly;
try
{
assembly = Assembly.LoadFrom(filename);
}
catch (BadImageFormatException)
{
// Ignore native assemblies
continue;
}
result.Add(assembly.GetName(false));
}
return result;
}
}
}