What's the best idea to manage resources in Silverlight? - asp.net

I need to create my silverlight framework that has all following features about resources.
Partial loading. So, I can't use sample resource file(*.resx).
Strongly-typed resource file. Because It's very easy to debug.
Easy to edit with sample text editor. Because you can't use some complex editor like visual studio in web server.
Easy to detect missing resources.
Hint
My framework is built on with Visual Studio Integration Package project. So, I can modify most of Visual Studio features like editor,toolbox, menu.
update#1
If it's impossible, So, I will create some resource edit on web server to manage this resource.
Thanks,

I'm not sure what you are trying to do as your question was rather vague, but I can shed some light on how resources can be managed on the Silverlight platform.
Silverlight resources can be embeded within any XAML as all visual elements have a ResourceDictionary which is accessible via the Resources property.
<Grid>
<Grid.Resources>
<DataTemplate x:Key="MyTemplate">
</DataTemplate>
</Grid.Resources>
</Grid>
However, it is best practice to use special XAML files called "Resource Dictionaries".
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
<DataTemplate x:Key="MyTemplate">
</DataTemplate>
</ResourceDictionary>
Silverlight 3, brings the ability to automatically merge these resource dictionaries into the application's main resource dictionary.
<Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="Resources/A.xaml"/>
<ResourceDictionary Source="Resources/B.xaml"/>
<ResourceDictionary Source="Resources/C.xaml"/>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary>
<Application.Resources>
In order to merge a resource dictionary with your Application's resources, the resource dictionaries must reside within the compressed XAP package that is used to deploy Silverlight applications down to the client.
However, if you wanted to, you could store the XAML resource dicationaries on the web server and bring them into your Silverlight application by using WebClient to download the file, then using XamlReader to construct the object model in memory from the XAML string you retrieve from the file.
Resource dictionaries are inherently strongly typed but not type-safe. In that, you will not get a compile time error if you have an improperly typed element in XAML. If there happens to be an error in one of your resources you will find out only when a reference to it is initialized and the rendering engine attempts to instantiate your resource.
So in short:
Yes.
Yes.
Yes.
No.

Related

How can I add a Xamarin.Forms XAML file to an FSharp project?

How can I add a Xamarin.Forms XAML file to an FSharp project?
By default, XAML files have C# code-behind.
I tried moving a XAML file with C# code-behind to an F# project.
I then changed the file extension to ".fs".
However, my attempt crashed VS2017.
EDIT
C# Views & F# ViewModels
I'm guessing WPF and Xamarin.Forms will see this the same way. You can define all your views in your C# project and have your ViewModel logic in a Portable Class Library (PCL). You can refer your ViewModels directly in your C# project when the View needs its DataContext. This way, it'll behave the same way as it would with a C# ViewModel.
If you'd like a working example of this, I found this that shows exactly what you could do: MVVM with F#
F# MVVM
If you'd prefer to have an entire application that has F# business logic and XAML in the same project, you can download the following extension: Windows App in F#. By pointing to the FSharp.ViewModule in your directives, you'll be fine.
The view model which will handle all UI logic. Inherit view model from
ViewModelBase
You'll also be able to find a working sample of this kind of thing right here
"Code behind" files don't exist in F# (lack of partial classes), and even in C# many people recommend keeping those files empty.
You can load the Xaml file using .LoadFromXaml and access objects using .FindByName<'t>. See Wintellect sample. You need to specify the names as strings and the types so there isn't compile-time safety.
It is not as clean as on WPF, where there is a type provider (FsXaml) which gives typed access to the objects. A type provider for Xamarin Forms may appear in future.
I personally prefer to avoid Xaml and do everything in code, where everything is typed and there is no reliance on strings.

UWP app errors when built in .Net Native

We've got a Windows 8.1 app that we've converted to a Windows 10 UWP app. The app works fine in debug, but when running in Release (.Net Native), we are getting a runtime error on app load. It's not at all clear what's causing the error. The error happens in the OnLaunched event in App.xaml.cs where some data is being initialized. The error:
An exception of type System.NullReferenceException occurred in
System.Private.CoreLib.dll
Additional information: Arg_NullReferenceException
We're using the latest versions of MVVM Light.
I know this isn't a lot of info, but it's really all we have right now and are pretty stumped. Anyone seen and issue like this or know where to start in tracking it down?
If, you're still using SQLite or any Reference.
Please Right Click to your Project => Add => Reference => Make sure your DLL of Nuget is checked.
Please Check this solution.
I had this exact problem in that I converted an 8.1 app to UWP. This was resolved by including a file called Default.rd.xml in the Properties folder. This was not mentioned in the migration guide that I had used.
Not including it means some pretty common coding patterns such as reflection will not work, and this includes in imported .dll's.
A basic Default.rd.xml file looks like the following ...
<!--
This file contains Runtime Directives used by .NET Native. The defaults here are suitable for most
developers. However, you can modify these parameters to modify the behavior of the .NET Native
optimizer.
Runtime Directives are documented at https://go.microsoft.com/fwlink/?LinkID=391919
To fully enable reflection for App1.MyClass and all of its public/private members
<Type Name="App1.MyClass" Dynamic="Required All"/>
To enable dynamic creation of the specific instantiation of AppClass<T> over System.Int32
<TypeInstantiation Name="App1.AppClass" Arguments="System.Int32" Activate="Required Public" />
Using the Namespace directive to apply reflection policy to all the types in a particular namespace
<Namespace Name="DataClasses.ViewModels" Serialize="All" />
-->
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
<Application>
<!--
An Assembly element with Name="*Application*" applies to all assemblies in
the application package. The asterisks are not wildcards.
-->
<Assembly Name="*Application*" Dynamic="Required All" />
<!-- Add your application specific runtime directives here. -->
</Application>
</Directives>
If this does not work, then try creating a new empty UWP project to get the latest format for the file.

MVVM Light in Class Library...something is holding onto the ViewModelLocator when I free all associated views

Using Ninject and MVVM-Light in a Class Library DLL. When I free up all Views that call for the DataContext
<UserControl.Resources>
<vm:ViewModelLocator x:Key="ViewModelLocator"/>
</UserControl.Resources>
<UserControl.DataContext>
<Binding Path="DataViewsViewModel" Source="{StaticResource ViewModelLocator}" />
</UserControl.DataContext>
...it appears to NOT release the ViewModelLocator.
Using ANTS Memory Profiler, the only references remaining are to the ViewModelLocator.
I suppose more detail is in order, and would welcome any guidance on what information is most beneficial to resolve this issue. I am learning on the fly here :).
What I'm trying to accomplish is the complete Cleanup of an instance of a class object so that when a new one is instantiated it will start completely new.
p.s. this Class Library is our way of adding WPF into an MFC C++ application. We are calling up "controls" as needed and want to completely cleanup or dispose when no longer needed.

How do I get rid of the xmlns="" from the root node of my XML?

I have a send port with a pipeline with an XML assembler. All my files that it creates look like this:
<?xml version="1.0" encoding="utf-8"?>
<Root xmlns="http://LMS.OIv2.Sierra.SierraRouteUpdate">
<Orders OrderCode="" SCAC="" CarrierName=" />
<Orders OrderCode="" SCAC="" CarrierName="" />
</Root>
How can I get rid of that xmlns attribute from the root node?
The use-case for this type of message processing is when integrating with legacy systems that do not implement a fully compliant XML parser. While "in theory", all systems should be able to handle valid XML, back in the real world I find a lot of applications still treat XML in the same way they treat a string or flat-file.
I've updated my blog post to include a sample Visual Studio project, showing the implementation of the code inside a BizTalk pipeline component. I hope this helps.

WPF XAML namespace refactoring

Consider a ViewModel and a View that uses it, where the DataContext is set to the VM in the code behind file.
When they are both at the project namespace, the view runs without exceptions with binding statements along the lines of:
ItemsSource="{Binding Path=PrefixFilterChoices}"
where PrefixFilterChoices is a property on the VM.
When I refactor the project so that ViewModels and Views are each in their own namespace within the project, I now get a runtime error:
(System.IO.IOException' occurred in PresentationFramework.dll, cannot find the resource projectView.xaml).
1) I can't figure out who is looking for the resource though, so I'm not sure what the fix is. The code behind is still setting the DataContext and it has the new namespace for the ViewModel. Must I add it to the XAML also? Must I alias it and now qualify the Path for all of the bindings?
2) I use resharper, which has always been spot on the money at refactoring namespace changes; but it isn't helping even a little with the XAML. Are there any tools that do better XAML refactorings?
Cheers,
Berryl
Part of the answer is that refactoring the namespace affected the application StartupUri. I couldn't get the format right in the xaml so I just set the MainWindow in an application startup event.

Resources