In my ShellViewModel PlatformProvider.Current results in a XamlPlatformProvider as expected. In another ViewModel navigated to in a Frame PlatformProvider.Current results in a DefaultPlatformProvider.
Furthermore if I trigger a function in the ShellViewModel I can see that PlatformProvider.Current still results in a XamlPlatformProvider, so that ViewModel isn't affected.
This results in errors on Caliburn.Micro.Execute.OnUIThread and other platform specific calls such as using a BindableCollection.
It started happening after updating a large project to Caliburn.Micro version 4.0.173 from version 3.2.0.
I've been unable to reproduce the error in a smaller test project, so I can not show meaningful code.
I've tried replacing the whole bootstrapper with a minimal one and still see the error.
EDIT:
Creating a UI component from code within Caliburn.Micro.Execute.BeginOnUIThread gives the error:
"The calling thread must be STA, because many UI components require this".
Altering a BindableCollection gives the error:
"This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread."
The above scenarios work if I wrap them in a Application.Current.Dispatcher.Invoke which indicates that Caliburn.Micro fails to use the Dispatcher/UI thread.
I'm using C# on .NET Framework 4.8.
The second ViewModel, which was throwing errors was in a second project that included the NuGet package Caliburn.Micro.Core instead of Caliburn.Micro. Updating both to the same version solved the issue.
I had used NuGets Consolidate function to update Caliburn.Micro in the whole solution and had missed Caliburn.Micro.Core.
Related
I'm in the process of porting a Asp.Net Core Website targeting the full framework to a website that targets Asp.Net Core 3.
In that process I have hit a snag. The website references the Newtonsoft 11.0.3 NuGet package and among other things uses the Newtonsoft.Json.Serialization.DynamicValueProvider class.
Interestingly that class exists when targeting the full framework but does not exist when targeting netcoreapp3.1 and so Visual Studio is producing compilation errors stating that the class doesn't exist. At first that seemed crazy to me, but I checked the source code for the class and sure enough it contains the following conditional compilation statement wrapped around the whole class
#if HAVE_REFLECTION_EMIT
Apparently the netStandard 2.0 dll in the NuGet package that my netcoreapp3.1 project would use causes the conditional compilation statement to not include the DynamicValueProvider class.
So I did some poking around in the Newtonsoft.Json.Serialization namespace and I see that there is a ReflectionValueProvider class available that does not contain such conditional compilation and is available when targeting netcoreapp3.1
I've looked at the source code for both the DynamicValueProvider class and the ReflectionValueProvider class and I'm unclear on the difference. Both appear to get or set the value of a property or member type based on the MemberInfo passed in into the constructor. Both appear to use reflection to accomplish their work. As I mentioned, apparently DynamicValueProvider needs reflection Emit ability and ReflectionValueProvider does not. Emit ability apparently is used to Emit IL as best I can tell.
So I wonder if perhaps the two are drop in replacements for each other except that maybe DynamicValueProvider might be faster since it apparently leverages IL Emitting. But that's just a hunch. I'd prefer to have a more concrete understanding of the differences between the two classes before I start swapping the one for the other in this existing codebase as a way to get to .Net Core 3.
Can you provide me with better insight into the differences between the DynamicValueProvider
class and the ReflectionValueProvider class, or at least confirm my hunch?
We had updated Newtonsoft.Json from 9.* to 12.0.3 version, and observed performance degradation on paths that includes json serialization. All paths lead to DynamicValueProvider. Fortunately, we had global descendant for DefaultContractResolver, and I was able to overload CreateMemberValueProvider method to return ReflectionValueProvider.
For now we are continue testing the new version, but I can say that from performance perspective ReflectionValueProvider works faster than DynamicValueProvider.
I think there is a correlation with the fact that NetStandard 2.0 is also used to build Xamarin.Forms applications for iOS which require an AOT compilation.
As written here:
Limitations of Xamarin.iOS
"Since applications using Xamarin.iOS are compiled to static code, it is not possible to use any facilities that require code generation at runtime."
and
"No Dynamic Code Generation.
The System.Reflection.Emit is not available"
For example, this is a System.Text.Json limitation that actually cannot be used in Xamarin.Forms projects for iOS. More info here.
System.Text.Json Serializer does not appear to work on Xamarin iOS
I have a Xamarin.Forms PCL project, and in it we are using JSON.NET to Serialize and deserialize. This works for 3 of our developers. On our 4th developers computer, anything that uses the deserialize function works fine, however if a line runs that uses Serialize, he gets the error:
System.MissingMethodException: Method 'Newtonsoft.Json.JsonConvert.SerializeObject' not found.
I'm having trouble figuring out how:
1) One method cant be found from a library, even though another one is working fine from the same library
2) How this is happening only on one developers machine?
We are using nuget to manage packages, and he has tried force reinstalling the latest version of json.net with no luck.
Does anyone have any idea what might fix this?
I am currently developing a custom JavaFX 8 control and was about to make the first release available when Oracle released JDK u20. After upgrading to this version my control now triggers a long list of CSS warnings that look like this:
"Could not resolve '-fx-base' while resolving lookups for
'-fx-background-color' from rule '*.test' in stylesheet
test.css".
Note: I am not calling any of these suspicious methods: applyCSS(), layout(), or impl_processCSS().
What could be the possible reason for this?
The messages were caused by changes made by Oracle to the CSS engine. Custom controls that implemented the method Control.getUserAgentStylesheet() were likely to trigger them. There were a couple of work-arounds that were suggested to fix this but in the meantime release 8u40 moved the method to Region and it is now fully supported again. However, if your project also uses ControlsFX then you will still see them until you upgrade to ControlsFX 8.40.9.
I have a previous project running Ninject 2.0 runtime version 2.0 and now I am using Ninject in a new project and using the new Ninject, ninject web.mvc version 2.2 for runtime version 4.0.
Every single time I get the error no parameterless constructor
Invalid Operation exception
An error occurred when trying to create a controller of type HomeController'. Make sure that the controller has a parameterless public constructor.
What am I missing. All the bindings are registered.
Do I need to now define interfaces for Controllers as well such as HomeController as IHomeController as I have seen in some examples, Or do I get back to using the older version
There is one version that does not show activation exceptions properly but show this exception instead. Most likely the problem is a duplicated binding.
In addition to what Remo Gloor said, you might want to check that MVC is set up to use Ninject correctly. I was doing some things manually on an older version of the MVC plugin and ended up needing to just bite the bullet and make Global extend the NinjectHttpApplication class, which I had previously been avoiding.
The error you're getting is the error you would get if MVC tries using its built-in controller factory to produce controllers. So you may want to create a custom method binding on your controller class and put a breakpoint inside to make sure it's even being invoked.
You may also want to switch to version 2.3. You can pick up the latest builds of Ninject and all its extensions here.
I have seen this issue mentioned couple of times on forums where there is no direct answer, here is the solution to the above problem, i.e., working with latest ninject
Download the latest Ninject from github.
The ninject I got for MVC2 is named as Ninject.Web.Mvc2-2.2.0.0-release-net-4.0 (runtime version 4)
Now during adding reference add Ninject.Web.Mvc.dll(check the version is same as above by right click properties in VS)
Now Add Ninject.dll from the lib folder in same parent folder (check the version as above)
Now Add CommonServiceLocator.NinjectAdapter.dll from the extensions folder in lib parent folder (check the version as above.)
The missing link in all these have been the commonserviceLocator.dll and the correct version should match. This should be tried if you are sure your bindings are correct as mine were and check to see if your project work with older version.
Thanks to everyone, and good luck :)
In the designer I get this error: "Error Creating Control: Object Reference Not Set to an instance of an object". The page itself runs fine. One of the objects, possibly an objectdatasource has to be failing at design time. But how to find which one?
The project was originally designed with a XSD for the data pointing to SQL Server queries. All based on typical Microsoft demonstrations which don't really take the product lifecycle into account.
I have had to refactor a number of things in the database, and the XSD designer doesn't automatically show you what you need to fix, you just have to run and get a runtime error. Obviously this means that some of the many individual adaptor methods are probably still incorrect, and I'm going through and updating them to match the new database model, and then tracking through the effects through all the bound controls and everything. And eventually, I may get away from a lot of this wizard-generated code and have something a bit more able to be statically checked by the compiler during the build.
But for now, how do I find out which object reference is the problem?
Problem appears to be due to a null Context in code in a base class which worked fine in VS 2008 which was being called in design-time