I've found a topic describing NullReferenceException in Windows Phone designer, however I believe this is a somewhat different issue, since it happens in all platforms and not related to MvvmCross plugins.
Designer (VS2012, Store/WP8/WPF apps) works fine for earlier versions of MvvmCross. I tried to compile a version that corresponds to 3.0.6 NuGet packages, and I can see that design-time model is loaded in all platforms.
Recent MvvmCross version causes all designer to raise NULL reference exception ("Object reference not set to an instance of an object") on all platforms.
Attempt to debug a VS instance didn't help: the call stack doesn't say much, and there is no MvvmCross code there.
The error is not related to the actual view/view model: I can remove all controls from the view, and the error is stil raised. The view model constructor code is never reached.
So it looks like there's some MvvmCross code (not from MvxView) that is unsuccessfully executed in at design-time. I wonder if this is a known issue and/or if there is a workaround to get designer work.
UPDATE. I created a GitHub issue with steps to reproduce the problem: https://github.com/slodge/MvvmCross/issues/347
This question moved to GitHub where there was lots of discussion and a few samples - https://github.com/slodge/MvvmCross/issues/347
From these samples, I believe we concluded the Nuget release 3.0.8.1 :
supports time data based on Blend-generated XML data files
supports design-time data based on simple C# classes
does not support design-time data where the data uses MvvmCross MvxViewModel as a base class
It isn't entirely obvious that developers should want to do the third thing (designtime data isn't real data?), but given that the overall MvvmCross manifesto broadly speaking aims to enable developers and to give them choice, then future MvvmCross will make this easier in the future.
In the meantime, if anyone wants to initialise objects at design-time, then there are a few helper classes around to enable this.
For example, the color plugin (and a small part of MvvmCross IoC) can be made available in the design-time environment using the MvxColorDesignTimeHelper - see:
https://github.com/slodge/MvvmCross/issues/323 (linked to MvvmCross throws NullReferenceException in Windows Phone Designer)
https://github.com/slodge/MvvmCross/blob/TibetBinding/Plugins/Cirrious/Color/Cirrious.MvvmCross.Plugins.Color.WindowsPhone/MvxColorDesignTimeHelper.cs
https://github.com/slodge/MvvmCross/blob/TibetBinding/CrossCore/Cirrious.CrossCore.WindowsPhone/Platform/MvxDesignTimeHelper.cs
Related
Attempting to submit a Windows Phone Silverlight 8.1 app to the store. Solution has several projects, including a Models, Contracts and a Shared DLL. These 3 projects/dlls are failing the Windows App Certification Kit tests with:
File XXX.Shared.dll has failed the NXCheck check
File XXX.Contracts.dll has failed the NXCheck check
File XXX.Models.dll has failed the NXCheck check
Microsoft say the problem is a Security threat issue, because these dlls are running code that is stored in a data segment.
The suggested resolution from Microsoft is to add the /NXCOMPAT switch to the Linker options, however, I do not have a Linker page in the properties in any of the 3 offending projects. I've tried adding this to the compilation symbols, but no change.
These DLLs are low payload - they contain not much more than POCO data objects, interfaces and a few static methods. I've built a new default blank Windows Phone app and added these projects to the Solution. If I reference any one of these projects in the main phone app project, the certification fails with the same result.
So the problem is definitely isolated to these 3 projects. There are other projects of the same type included in the solution, but these do not exhibit the same problem.
Does anyone have any ideas as to what these DLLs could contain which causes this Binary Analyzer failure?
I've compared compiler / build options and checked the project properties etc, but can't see any obvious differences.
This was due to a post-compile Build Event referencing an obfuscation library in each of these projects. Solution was to remove it as the library was third party.
I am currently working on a legacy web app which uses newtonsoft.json.dll version 1.3.0 and vb.net.
I added four new fields in the application. This source code is shared by another application and it posts into my application and it breaks it.
See image for error.
[]
The error is:
Could not find member x on object of type runtimetype.
The stacktrace breaks at:
newtonsoft.json.jsonserializer.setobjectmember(jsonreader reader,object target, type targettype, string membername)
I did some research. The folks reportedly solved such an issue by upgrading DLL version and didn't have a direct solution to fixing it via code change. I know its very old and the application is high impact any upgrade has huge ripple. However they are planning a rewrite of the application.
Can someone please share any ideas that i should pursue in order to solve this?.
I am expected to make it quick and under pressure.
https://smugmugc3.codeplex.com/workitem/10024
My problem is very similar to what is described in the link above.
I am going to upgrade my version of json converter after convincing my boss and I see that is the only way out of this problem.
After which I will update this thread if I find issues.
I'm trying to create a cross platform application using MVVMCross and portable class libraries, which interacts with an api and displays some data asynchronously.
Currently I am trying to generate a SHA512 hash value for a sign key that will be sent along to the api.
I am not exactly sure how I can implement the cryptology portion. I have tried using the SHA512 class, however it appears to be unavailable. I tried manually adding a reference to System.Security.Cryptology which didn't help.
I also tried additional packages on nuget such as SharpCrypt to see if they would help generate a hash value, however I see the error "the type or namespace name 'CryptSharp' could not be found" after adding the package from nuget.
I am targeting:
.Net Framework 4.5+
Windows Store apps
Silver light 5
Windows Phone 8
I'm quite a beginner so maybe I am missing something extremely obvious, any help or examples would be much appreciated.
Thanks!
I believe some of the crypto classes may also be available portably using the PCLContrib project - http://pclcontrib.codeplex.com - but I don't think this is yet available beyond Windows.
Where functionality isn't available portably, you can inject implementations into portable class libraries via an interface from each UI platform:
there's an example of this in the first part of N=31 in http://mvvmcross.blogspot.co.uk
there's a full introduction to MvvmCross dependency injection in https://github.com/MvvmCross/MvvmCross/wiki/Service-Location-and-Inversion-of-Control
I'm writing a plugin but I need a specific implementation for each Windows Phone version.
The problem is that the plugin system will try to load the platform plugin assembly based on a convention. In this case, "WindowsPhone".
We may try to override CreatePluginManager but then it will affect the rest of the plugins you may need.
I'm thinking of generating two different projects with different names but the same assembly and namespace. This, I think, would solve the problem of loading the specific plugin but I don't really know how to face an eventual publication to Nuget.
Best regards,
Roberto.
Generating assemblies with the same name is a viable way to go - it is something that the Microsoft Pcl teams do quite frequently - it is how the reference assemblies work.
The nuget distribution of these shouldn't be an issue - but would be a "faff" - as the nuget zip file would use different folders for the different files. There might, however, be some work to do at the .targets level if you want a single project to build both wp7 and wp8 configurations (this is similar to the effort needed for x86/x64/arm variants of assemblies in winrt nuget packages).
In fact, the main reason I can think for not using the same name is the very simple reason that it's far too easy to get in a muddle that way.
If for this one plugin, you wanted to override the plugin manager during setup, you could provide custom loading functionality based on
inheriting from https://github.com/slodge/MvvmCross/blob/v3/CrossCore/Cirrious.CrossCore/Plugins/MvxFilePluginManager.cs
and then overriding protected virtual string GetPluginAssemblyNameFrom(Type toLoad) to add a special based on some property of toLoad - eg if (toLoad.Name.EndsWith("Foo")) toReturn += PlatformPostfix
If this pattern becomes common - whether for wp or for the other versioned platforms - then we could include something back into the framework - it would be easy enough to try a version-neutral load followed by a version-specific load for every plugin.
There are also other ways you could go about this too...
E.g. Another possibility/opportunity is that your plugin core file could try loading multiple platform adaptions itself - eg using code like
public void EnsureLoaded()
{
var manager = Mvx.Resolve<IMvxPluginManager>();
manager.TryEnsurePlatformAdaptionLoaded<PluginLoader>();
manager.TryEnsurePlatformAdaptionLoaded<Sub1.PluginLoader>();
manager.TryEnsurePlatformAdaptionLoaded<Sub2.PluginLoader>();
}
This would try loading three child assemblies for that plugin - MyPlugin.WindowsPhone, MyPlugin.Sub1.WindowsPhone and MyPlugin.Sub2.WindowsPhone although you would only package one of these on each platform.
After installing .NET 4.5 beta, I noticed that my calls to Assembly.LoadFrom with a network path succeed without explicitly specifying "loadFromRemoteSources=true" in the application configuration file (whereas with .NET 4.0 this used to result in "System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework.")
I wonder if this, if it indeed is new behaviour and not something special in my setups (I've not yet decompiled the respective reflection classes or debugged the loading process to examine the differences), is an intentional change in policy and will remain in the RTM version?
The docs don't seem to indicate this change in behaviour. http://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx. And I would have expected a notice of it.
If it does work this way, then you're granting full trust by default and invisibly to a potentially dangerous assemblies and I can't imagine that would be the order of the day.
Have you got it added to machine.config per chance?
Also I would create a small program and target it to the 4.0 platform and induce this exception. Then I would retarget it to 4.5 and see if indeed it's true. Then I'd move the binaries to another machine and test there.