I have a PRISM based silverlight solution under source control. In regards to theming I have a project for each theme, for example 'Theme_Summer', 'Theme_Winter' projects. In reality there may be over 30 of these theme projects. Each theme project contains a selection of resource dictionaries to hold the styles etc along with the images, sounds etc that are required.
Each of these projects also has a Main.xaml merged resource dictionary that ties together all the resources in that theme project. My main application then just uses the Main.xaml resource dictionary from whatever theme project it needs to use.
The problem I have is I need these 30 or so themes in my solution so they remain under source control and manageable but they all get compiled into the XAP which is obviously not good as the app gets deployed somewhere and only requires 1 theme.
My question is really what do people think would be a suitable approach? Having a seperate solution for each theme so that it gets compiled into a seperate XAP and loaded dynamically seems like a lot of work. Is there a way to externally load these while they are part of the same solution?
Thanks for your time
Disclaimer: What I am recommending may not be the best for you. I only know a tiny bit about your project and know nothing about what you have told the customer (or boss) what you would deliver them.
If you are going to have x (where x is between 2 and 30-ish) themes. You will probably want to spend some time building a framework for supporting x themes. Since you won't want to change this framework every time you add a new theme, PRISM is perfect for you.
I would move everything out into x-ish silverlight class libraries. Obviously you could package similar themes together, like Seasons or Holidays, which would widdle down on the numbers of projects. Now don't forget that your Visual Studio Solution can have more than one project in it (Simply right click on the project and select Add->New Project).
Using PRISM is rather simple and there are a lot of resources to help you dynamically load xap files. It sounds like you may eventually want to rid yourself of problems associated with compiling in a bunch of similar logic.
Is there a way to externally load these while they are part of the same solution?
The answer is yes! You will have to compile your individual silverlight applications into XAP files and load them with PRISM.
It may seem like a lot of work, but when you've created the first few of them, it becomes second nature and really simple to add more XAP's to your list.
http://development-guides.silverbaylabs.org/Video/Silverlight-Prism
http://msdn.microsoft.com/en-us/magazine/dd943055.aspx
http://www.sparklingclient.com/prism-silverlight/
Related
I have a Silverlight 3 App that became quite big over the time. So I began to try to break it in several smaler Applications that will be dynamically loaded in my Main Application on demand. But I run into a strange problems with my VS 2008.
When I add a new Silverlight Application project to my solution and copy User Controls from my old Main Application into this new project it happens from time to time (about twice a day) that the XAML files and their code behind files loose their association. When this happens and I try to build the project, the compiler complains that he cannot find all the Ccontrols like buttons, labels etc. in the code behind files that I added to the class in the XAML-file. And the build fails of course.
The only workaround that I found so far is to add another Silverlight Application project and move all the content from the first added project to it. Than everything works fine for a while until the problem occurs again.
But that's not really a solution.
Any Ideas what happens here and what i can do?
Best Regards,
Rocko
I have seen issues like this before when changing the namespaces on controls in silverlight. The issue crops up when you don't change both the namespace on the control class, and the full name of the class in the x:class attribute on the root element of the control.
Not sure if this fits your situation or not, but it's the only time I've run into similar issues.
So far I have been creating Silverlight apps with all logic crunched into a single xap file. But as the application grows in size,
I seriously think I should break my Silverlight application into smaller multiple independent applications.
I would like to know how others solve this increasing size problem??
If you're looking to make some changes to your application, by refactoring it and splitting out parts, consider all of these.
Custom controls get their own control assembly
Definitely create control assemblies for any custom controls you develop. Not only do you get the benefit of self-contained controls, and optional use in your current and future projects, you can
take advantage of default control styles
use the cached assembly feature with them
share components with other projects
invest in your core code and controls, instead of investing in cleaning up application logic (if you're using static or style analysis, for instance) - spend your time where it will make the most impact
Consider dynamically loading new assemblies
There are some methods available for dynamically loading additional code into your app domain, it may be possible to abstract out less-often used parts of your app, and use this to load in those components. This is a more complex and involved app, but it can improve start-up performance.
It'll take time to split out the code into other assemblies when you're looking at a large application, and testing it can be a challenge. But you can end up with "sub-pages" and parts of your app being loaded only as needed.
Taking the time to design a system to load in new functionality and parts of your app, and architecting this framework, can take time to do right. This typically is using AssemblyPart to load a new assembly that you can reflect into and instantiate new objects from.
Merged Resource Dictionaries
Resource dictionaries can allow you to store styles, control templates, and other resources outside of pages, and outside of your App.xaml.
Cached Assemblies
Once you move to Silverlight 3, you can use the cached assemblies feature to store individual assemblies outside your .Xap, alongside, on your server - and as a bonus, those assemblies will be cached on the machine for quite some time.
A resource diet
Are you really using all of your graphic assets, XAML, controls, string resources, etc., that are stored inside your XAP file? Audit it from time-to-time and make sure you're getting the most bang for your byte.
A splash screen
If you're simply trying to improve the performance (download time) for your application initially, consider creating a splash screen. The Silverlight Toolkit samples have one - it's a simple Silverlight page that will load and display while your .Xap downloads.
Remote graphics
Instead of including image resources right inside your application/XAP, move your images to your CDN or server, so they can be loaded only as needed. This is often a nice and quick win.
Simplify your app
Make sure you actually need it to be XAML-heavy, graphic-heavy, etc. Maybe it can be simplified!
You should distribute your Silverlight modules using PRISM or MEF frameworks.
Visit http://mef.codeplex.com/
I'm having a little trouble as I decide how to structure my projects. This question is slightly subjective, but I'm having trouble conceptually.
If I create a wpf blend project (sketchflow right now), it creates two projects, "Project" and "ProjectScreens". Is this the best layout to use?
The issue is, I have classes and code (networking, file i/o, etc.) that I need to reference within the screens (i.e. they click a button, it creates a network connection), and the core code needs to reference the screens. This creates a circular dependency.
I've tried merging them all as a single project, which works, but it stops becoming a sketchflow project at that point.
I guess the big thing, what's the best way to structure this with my core code and my sketchflow prototype?
Check out the Model-View-ViewModel design pattern. You'll find it fits well for WPF (and Sketchflow) projects because it keeps your business logic independent of your UI and supports the binding-oriented development model of WPF.
The SketchFlow project is separated into 2 assemblies so that you can do all of your work in the screens assembly, and then later re-use what is in the screens assembly elsewhere if you want.
The main project is a very simple wrapper that enables the use of the SketchFlow runtime player.
Quick intro: I have some Silverlight 1 content that people have been editing and putting into HTML pages. Unfortunately, this means a lot of repetative creation of Storyboards, etc. We can use Silverlight 2, but not everyone here is familiar with C#/has Visual Studio. What I would like to do is create some custom controls in C#, output to a DLL, then reference the DLL in the XAML file (just as if it was part of a Silverlight project in VS).
I've tried adding this:
xmlns:mycontrol="clr-namespace:MyControl;assembly=../../content_GLOBAL/controls/MyControl/MyControl"
in the Grid tag that is my root. I know the path to MyControl.dll is correct. When I actually try and use it, though (I add <mycontrol:MyControl></mycontrol:MyControl> to the grid) and I get a parser error. It all seems OK if I don't add the control, even if I leave in the xmlns.
I suppose on some level, this makes sense--looking for an assembly is useful if you are going to build something, and since this XAML isn't in VS, it isn't actually building anything. Is there another way that I can reference, and use a custom control in SL2 in a stand-alone XAML file?
Let me first make sure that I understand you correctly: You have a Silverlight app that doesn't use any managed code and is not packaged in a .xap file. The <object> tag refers to a loose xaml file.
This is the Silverlight 1 app model and can still be used in SL 2, and such apps are referred to as "v1-style apps" (even though they target SL 2 and may use features not present in v1). When an application in this form is used, the Silverlight plugin does not load any of the managed components of the runtime (e.g. the CLR, etc.), so referencing a dll from a v1 style app is not going to work.
However, there might be work-arounds to the challenge you are facing here. One solution might be to use a v2 style app that is packed into a .xap and uses managed assemblies. One of the reasons you gave for not doing this is that other developers one the team are not familiar with C#. This should not be an issue as C# is not a requirement for building apps in SL, you can continue to program against it in JavaScript. And if you are just writing JavaScript code, Visual Studio is not a requirement, since there is nothing to compile. They can just edit the .html/.js files and use the .xap/.dll files that were already compiled. Does this make sense?
I'm having real difficulties with XAML files in Silverlight since they get very big very fast when using Blend. It just becomes a wall of text after only a handful of controls are added and animated.
I'm hoping a better vesion of Blend will come out soon, so that our designers will never even have to see XAML. For now, though, that is not a solution - XAML still needs to be managed manually and it is a depressing task.
Has anyone found a solution to this? How do you keep your XAML files in order? How do you understand them when they get big?
Edit: I am especially interested in Silverlight solutions, since the most obvious WPF solution - splitting things up into resource dictionaries - is not supported in Silverlight.
It does require a little bit of work to maintain XAML files, but basically, what you need to do is split them up in resource files (XAML Resource Dictionaries) using a scheme that makes sense to you.
For example we use a scheme where we have a folder structure like this:
Resources (contains XAML Files that represent the user controls and pages)
Stencils (XAML files with Shapes)
Styles ( XAML Files with styles)
Brushes ( ... )
Shared
Templates ( ... )
Your structure might vary but, separating all resources in different files really makes maintenance more easy in the long run.
I have been using Silverlight 2 since January when it was in private release, and we ran into this problem, all our XAML was in one big file. What we did as best practices was to break up the user interface into separate user controls based on visual categorization (header, footer, navigation controls etc..) Originally we tried to use nested canvases (grids had not been added to the framework yet) and this turned into a maintenance nightmare later.
In Blend you can actually select a Canvas/grid etc... from the Objects and Timeline window, right click on it, and you are given the option "Make Control.." This made for speedy re factoring and modularizing our main XAML file. We then used Events to allow the user controls to communicate between each other.
Hope this helps, and good luck!
I'm a Creative Developer and work in Blend extensively.
I published a few thoughts last year on keeping XAML clean.
Silverlight currently does not support MergedResourceDictionaries so it's hard to break out the XAML into separate ResourceDictionary files as I suggested in another post.
Paul Stovell also has some interesting guidelines for XAML.