Archive for category Silverlight

Using WP7′s ProgressIndicator with Caliburn.Micro

The Windows Phone SDK 7.1 introduced a new control to show the progress of long operations or interactions, ProgressIndicator. As I love much the Caliburn.Micro framework I got some time to integrate neatly ProgressIndicator with the rest of application and services using Caliburn’s container.

First of all, let’s define our application facing progress service:

public interface IProgressService {
    void Show();
    void Show(string text);
    void Hide();
}

Pretty simple, yes…

The implementation was partly inspired by Jeff Wilcox’s article about creating a global ProgressIndicator.

It’s pretty simple and straightforward: we’re getting the Root Application Frame and hooking up to the Navigated event. His arguments contain the page being navigated to. Then we’re attaching our instance of ProgressIndicator to that page. And the service uses Show/Hide methods to manipulate the state of indicator. The code:

public class ProgressService : IProgressService {
    const string DefaultIndicatorText = "Loading...";
    private readonly ProgressIndicator progressIndicator;

    public ProgressService(PhoneApplicationFrame rootFrame)
    {
        progressIndicator = new ProgressIndicator {Text = DefaultIndicatorText};

        rootFrame.Navigated += RootFrameOnNavigated;
    }

    private void RootFrameOnNavigated(object sender, NavigationEventArgs args)
    {
        var content = args.Content;
        var page = content as PhoneApplicationPage;
        if (page == null)
            return;

        page.SetValue(SystemTray.ProgressIndicatorProperty, progressIndicator);
    }

    public void Show()
    {
        Show(DefaultIndicatorText);
    }

    public void Show(string text)
    {
        progressIndicator.Text = text;
        progressIndicator.IsIndeterminate = true;
        progressIndicator.IsVisible = true;
    }

    public void Hide()
    {
        progressIndicator.IsIndeterminate = false;
        progressIndicator.IsVisible = false;
    }
}

The last piece of this mini-puzzle is wiring up the service to container and made it available to the rest of application:

public class AppBootstrapper : PhoneBootstrapper {
    private PhoneContainer container;

    protected override void Configure()
    {
        container = new PhoneContainer(RootFrame);
        container.Instance<IProgressService>(new ProgressService(RootFrame));

That’s all. Now declare a dependency on IProgressService whenever you need it and show/hide to give a nice feedback to the User when your application is doing something long. You never forget that User is the ultimate chief and judge in our business, right?..

,

3 Comments

The Life After Silverlight 5

There is a lot of panic in Microsoft eco-system caused by some rumors that Silverlight 5 will be the last of the family. Developers are crying about skills being buried and managers fearing about the future of in-house enterprise-grade projects.

And everyone is guessing what will be Microsoft pushing in the segment currently occupied by Silverlight. Now we have two available options, the new guy in the block – the HTML 5, and the good old and trusty WPF. Won’t mention Windows 8 here as it’s way to the Enterprise is too long to be considered as an option.

So, everyone is watching the next move of Microsoft as there is not a clear winner – HTML 5 is too young to be considered seriously and WPF is too old to be considered as a long-time investment. When Silverlight was a competitor the choice was rather easy, now picture is much more blurred.

In my view

XAML & .NET will stay with us. Will it be WPF, Metro or anything MS will roll out for Desktop and LOB applications it will be based on those two pillars. At least for 7-10 years we’re assured.

I’ll make few guesses, what MS’s steps will be after Silverlight end will be announced (it will be interesting to read it in a year or two):

  • A promise that Silverlight 5 will be supported for next 3-4 years
  • A tool for a relatively easy migration from Silverlight to WPF (and/or Windows 8 programming model) will be available
  • Newer versions of WPF will promote features previously hyped as Silverlight’s exclusives (in-browser apps, sandboxing, web deployment & updates and others) minus the ability to run in browsers on various platforms.

As for companies struggling with the choice right now (and it will probably true for near future), you’ll have to decide:

  • Interaction and Data intensive applications, Rich User Experience, Resource Intensive application, deep OS integration – embrace the WPF and be happy (if you don’t mind to lock yourself to MS and Windows).
  • Platform independent, high user base, moderately interactive UIs, presentation and manipulation of small amounts of data – your best bet is the Web: HTML5, CSS3 and JavaScript will be your tools.

And if you still struggle with the choice the best thing you can do next is to look at your current development team. If they are more experienced and efficient with Web technologies you’re set. If they are mostly Desktop specialists then you’d want to explore their productivity to the max and get the release date closer. You’re sorted.

And the last word: don’t be a mono-disciplinary developer. Don’t lock yourself exclusively in Desktop or Web, Microsoft or LAMP or whatever. The day you’ll fail to pick, learn and use efficiently a new tool/framework will mean your career as a Professional Software Developer is done. Be open. Look around, there are so many amazing things in Software Development industry. Just pick something new and learn. It will be one of the best investments you can do in your future. You can do it right now…

Leave a Comment

How to make Caliburn.Micro and Silverlight resources in MergedDictionaries play nicely together

I’ve fixed an error in our codebase that prevented Caliburn’s bootstrapper and application resources to live happily together. That was manifesting like warnings in xaml about missing resources and styles, no right styles in Visual Studio designer and so on.

Now, to reproduce the problem we have to follow Caliburn’s guidelines then make few changes:

  • Create new Silverlight 4 application
  • Add Caliburn.Micro NuGet package
  • Configure your application to bootstrap Caliburn
  • Add new Resource Dictionary to host your common styles/brushes/whatever
  • Include your dictionary in MergedDictionaries section
  • Add a fancy color brush and use it in ShellView.xaml by referencing it as a static resource
  • Build your app

Your application will compile and run fine. However, you can spot few issues with your code:

  • ShellView.xaml:
    • Xaml editor displaying warning: “The resource could not be resolved”
    • VS Designer will not use your resource on design surface
  • App.xaml
    • Xaml editor displaying warning: “The designer does not support loading dictionaries that mix ‘ResourceDictionary’ items without a key and other items in the same collection. Please ensure that the ‘Resources’ property does not contain ‘ResourceDictionary’ items without a key, or that the ‘ResourceDictionary’ item is the only element in the collection.”

To solve this problem you have to modify your App.xaml.

The original App.xaml fragment, as by following recommendations:

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Themes/Generic.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
        <local:AppBootstrapper x:Key="bootstrapper" />
    </Application.Resources>

Now, the corrected version that removes all issues I’ve described earlier:

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Themes/Generic.xaml" />
                <ResourceDictionary>
                    <local:AppBootstrapper x:Key="bootstrapper" />
                </ResourceDictionary>
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

Actually, this fragment is the recommended way of instantiating boostrapper for WPF version of Caliburn.Micro. Why it isn’t recommended also for Silverlight? I don’t know. For our rather large project I haven’t seen any downgrades and issues using this approach. Just few annoying bugs were gone…

1 Comment

Integration of Caliburn.Micro and Telerik’s Silverlight controls

I’ve wrote already about how to use Telerik’s RadTabControl with Caliburn.Micro and profit from Caliburn’s conventions. That post is still getting considerable attention in my blog and also there are people are asking in Caliburn’s discussion list about such kind of integration. So, I’ve decided to spend some of my time and provide a more coherent experience in this domain. Rob Eisenberg suggested to create a dedicated project for it and, why not, to create a NuGet package. That sounded very interesting for me as it would allow me to scratch another itch – the NuGet package manager. We’ve been using it in our projects with great success but I have never explored the part with creation and publication of packages.

How do you get it

Caliburn.Micro.Telerik source code on GitHub. Feel free to pull the code & use only parts you need. There are two main classes, you can copy&paste them in your projects. If you want to contribute, I’d appreciate a push request with new conventions, better code samples or bug fixes. Report issues if you’ve found any…

Caliburn.Micro.Telerik as a NuGet package. “Add  Library Package Reference …” from Visual Studio & start using it. My package has a dependency on Caliburn.Micro.1.1.0 so you can just reference it and Caliburn will be pulled in automatically.

What’s in

First of all, conventions. I’ve put inside conventions we’ve been using in our projects and plan to add more. So far there are conventions for:

  • RadTabControl
  • RadBusyIndicator
  • RadDateTimePicker (affects also RadTimePicker and RadDatePicker)

Then you have a basic implementation of IWindowManager, the RadWindowManager class. Nothing fancy, pretty basic stuff. And I plan to extend it to offer also an unified interface to Telerik’s custom dialogs like Confirm, Alert and Prompt.

And third, there are two sample projects, one showing how to use conventions and other makes use of RadWindowManager.

How to use conventions

Add a line in your Bootstrapper’s Configure() method to enable conventions:

public class AppBootstrapper : Bootstrapper<IShell>
{
   protected override voidConfigure() {
        // …

        TelerikConventions.Install();
    }

Check it out and let me know if you found it useful or how it’s possible to make it better…

16 Comments

How we get inspiration…

That’s interesting to observe how we’re getting influenced by things around us. How world we see and experience is determining what and how we do. Most of the time we’re not sensing the source of our actions and decisions. It’s very subtle. And often the “it feels right” moments are a sign that experience we’ve got, processed and incorporated is applied without realizing what exactly is done right…

But not this case:

image

I’m working on Windows Phone 7 application (yes, mGitHub and btw it’s already available in marketplace) in my spare time and weekends and I own a WP7 device which I really like. So, there was no surprise when I’ve seen that Metro UI, the visual style of Windows Phone 7 platform, influenced me and leaked in this screen that is part of a Silverlight application.

Asked people what they think, got mostly positive appreciations. It would be interesting to see how this concept will evolve. It’s only an early sketch, done by a “more developer than designer”. How you like it?

Leave a Comment

Telerik’s RadTabControl and Caliburn.Micro

* A more complete solution is available in this blog post
It contains code, examples and a NuGet package

Well, again a story about having a problem, searching for a solution and finally sharing it :)

So, this time it’s about trying to marry the RadTabControl from Telerik’s control set with Caliburn.Micro. I’m evaluating Telerik for our pilot project in Silverlight since I would like to speed up our development process in few areas. And then we’re using happily Caliburn.Micro in it’s Silverlight flavor.

Scenario: a RadTabControl should contain multiple individual TabItems composed in runtime and backed each by a View Model. And it should be completely ViewModel driven.

Let’s start with ViewModel, as a central piece of our code:

public class MainPageViewModel : Conductor<IScreen>.Collection.OneActive
{
    private readonly FirstTabItemViewModel first;
    private readonly SecondTabItemViewModel second;

    public MainPageViewModel(FirstTabItemViewModel first, SecondTabItemViewModel second)
    {
        this.first = first;
        this.second = second;
    }

    protected override void OnInitialize()
    {
        base.OnInitialize();
        Items.Add(first);
        Items.Add(second);

        ActivateItem(first);
    }
}

Pretty straightforward.

Now, we have to wrap this model in a view. In better traditions of Caliburn.Micro it’s extremely succinct and simple:

        <telerik:RadTabControl x:Name="Items">
            <telerik:RadTabControl.ItemTemplate>
                <DataTemplate>
                    <TextBlock Text="{Binding DisplayName}" />
                </DataTemplate>
            </telerik:RadTabControl.ItemTemplate>
        </telerik:RadTabControl>

It looks nice, but it actually doesn’t work. Yet… Caliburn.Micro is handling this way the TabControl from WPF but that of Silverlight is horribly broken (and MS isn’t in hurry to fix it). To have it work nicely with Telerik’s Silverlight RadTabControl we have to add another convention to Caliburn to hint how he should be dealing when doing bindings for RadTabControl. The code is very similar to binding conventions for WPF’s TabControl, I’ve simply adapted it to handle new case.

We will be adding new convention and we should do that in our override of Configure method in our Bootstrapper. The code:

ConventionManager
    .AddElementConvention<RadTabControl>(RadTabControl.ItemsSourceProperty,
                                                      "ItemsSource",
                                                      "SelectionChanged")
    .ApplyBinding = (viewModelType, path, property, element, convention) =>
    {
        if (!ConventionManager.SetBinding(viewModelType, path, property, element, convention))
            return false;

        var tabControl = (RadTabControl)element;
        if (tabControl.ContentTemplate == null
            && tabControl.ContentTemplateSelector == null
            && property.PropertyType.IsGenericType)
        {
            var itemType = property.PropertyType.GetGenericArguments().First();
            if (!itemType.IsValueType && !typeof(string).IsAssignableFrom(itemType))
                tabControl.ContentTemplate = ConventionManager.DefaultItemTemplate;
        }
        ConventionManager.ConfigureSelectedItem(element,
                                                RadTabControl.SelectedItemProperty,
                                                viewModelType,
                                                path);

        if (string.IsNullOrEmpty(tabControl.DisplayMemberPath))
            ConventionManager.ApplyHeaderTemplate(tabControl,
                                                  RadTabControl.ItemTemplateProperty,
                                                  viewModelType);
        return true;
    };

And it works.

I’ve posted complete source code with my solution on GitHub, RadTabControlAndCaliburn.

Update 14/04/2011: Updated convention code to work with latest Caliburn.Micro 1.0 RTW.

3 Comments

mGitHub Sample Application. Using Caliburn.Micro to build Windows Phone 7 applications

* mGitHub.SampleApp on GitHub

** mGitHub – the real app – is available in Marketplace

The story

I’ve been very excited when Microsoft announced a new & shiny mobile platform, the Windows Phone 7. Mostly because it gave me the chance to explore new things using very familiar tools: Visual Studio 2010, C# and Silverlight. I never had enough time to start digging in this area. When I’ve read that Rob Eisenberg announced a Caliburn.Micro contest and having lost the passion for doing my job at company I’m working now, I’ve decided to participate.

I’ve decided to go with an interesting idea – writing a WP7 app to work with GitHub. Mainly because I’m sure that I will use such app myself. GitHub is an awesome service that lets you host and collaborate on your projects freely once they are open source or if you want private projects you can have it too for a fee. I like idea and this sample application so much, the whole development process went so smooth and easy so that I’ve decided, along with participation in CM contest and publishing sources of my sample app on GitHub, to continue developing it by adding more features to offer a complete and user friendly application to work with GitHub (later about this).

The app

mGitHub.SampleApp allows to browse few preselected projects and repositories on GitHub. You can see user/repository details, navigate trough user’s own repositories, watched repositories, view contributors and so on…

The use of Caliburn.Micro, which is (not only) a MVVM framework, implies that application is View Model driven. Main screen is baked by a view model, then everything else – application flow, user interactions, service calls are done within View Model classes (with few small inclusions of WP7 navigation model, view based).

WP7 controls like Panorama and Pivot were also used with MVVM in mind. For example, here is the code for main View Model that is serving a Panorama-based view:

public class MainPageViewModel : Screen {
    public MainPageViewModel(MostViewedViewModel mostViewed,
                             FavoritesViewModel favorites,
                             AboutViewModel about)
    {
        MostViewed = mostViewed;
        Favorites = favorites;
        About = about;
    }

    public FavoritesViewModel Favorites { get; protected set; }
    public MostViewedViewModel MostViewed { get; protected set; }
    public AboutViewModel About { get; protected set; }
}

So, here we’re just injecting our View Models for individual Panorama pages in MainPageViewModel and then SimpleContainer takes care to provide required instances. Since in a Panorama control all pages are visible (active), we’re using a simple Screen (from CM) as our base class for our VM. Then, this is how the panorama view is defined:

        <controls:Panorama Title="mGitHub sample app "> <controls:Panorama.Background> <ImageBrush ImageSource="PanoramaBackground.jpg"/> </controls:Panorama.Background> <controls:PanoramaItem x:Name="Favorites" Header="my favorites" /> <controls:PanoramaItem x:Name="MostViewed" Header="interesting" /> <controls:PanoramaItem x:Name="About" Header="about" /> </controls:Panorama> 

It’s nice and clean, with very good separation of concerns: each panorama page has it’s own View and a corresponding View Model. The work to glue it together is done by Caliburn.

The Pivot is a bit different. This control is basically a well known TabControl, it has headers and only one item is active at a time. For a PivotViewModel we’ll use a Conductor class with one active item:

[SurviveTombstone]
public class PivotViewModel : Conductor<IScreen>.Collection.OneActive {
}

Then the two application Pivots, UserPivotViewModel and RepositoryPivotViewModel will just ask from container the view models of individual pages and add them to Items collection of Conductor class:

[SurviveTombstone]
public class UserPivotViewModel : PivotViewModel {
    private readonly UserDetailsViewModel details;
    private readonly UserRepositoriesViewModel repositoriesViewModel;
    private readonly UserWatchingViewModel watchingViewModel;

    public UserPivotViewModel(UserDetailsViewModel details,
                              UserRepositoriesViewModel repositoriesViewModel,
                              UserWatchingViewModel watchingViewModel)
    {
        this.details = details;
        this.repositoriesViewModel = repositoriesViewModel;
        this.watchingViewModel = watchingViewModel;
    }
    protected override void OnInitialize()
    {
        base.OnInitialize();

        Items.Add(details);
        Items.Add(repositoriesViewModel);
        Items.Add(watchingViewModel);

        ActivateItem(details);
    }

The view, again, is very simple, grace of Caliburn.Micro magic:

        <controls:Pivot x:Name="Items" Title="{Binding PivotTitle}" SelectedItem="{Binding ActiveItem, Mode=TwoWay}"> <controls:Pivot.HeaderTemplate> <DataTemplate> <TextBlock Text="{Binding DisplayName}" /> </DataTemplate> </controls:Pivot.HeaderTemplate> </controls:Pivot> 

That’s why I enjoy using this framework, it makes some development tasks extremely simple.

Also, application make use of INavigationService,  wrapper API for Launchers/Choosers and is aware of Thombstoning. I tried to keepcode small enough to be easily followed and read, so it will not be too hard to find those places in project’s source code…

Another (probably interesting) piece of code in this project is communication with GitHub using their API. It’s not exactly the IGitHubHost service that I want to highlight, it’s pretty trivial. Take a look at two wrappers around RequestProcessor class, both added in order to improve User Experience when working with mGitHub.SampleApp on the phone:

  • ProgressAwareRequestProcessor – will show a view with PerformanceProgressBar during any remote call
  • CachingRequestProcessor – providing a extremely simplistic data cache, storing requests and their results

These wrappers are registered in container and View Models even don’t know about their abilities, for them it’s just issuing a call and displaying a result. Separation of concerns is always good principle to follow…

Screenshots

Few screenshots, to get the sense of how UI looks like:

12

34

 

Final notes

This application surely contains bugs, it probably has few strange design decisions and graphics are done by professional developer (me). But it works. It serves it’s main purpose to show how you can write an application for Windows Phone 7 using Caliburn.Micro. And I had a lot of fun working on it…

I’ll surely improve this sample, fix reported bugs and will listen carefully to improvement ideas. So, any feedback is welcome.

But in the meantime, I’m doing everything possible to release a real application to Marketplace that will be called mGitHub and will offer essentially improved experience and more features. So, if you like the idea, if you like GitHub and will most likely use the app on your phone, I would be glad to hear from you. Next time when I’ll be planning features your feedback will be considered.

This application weren’t tested on a real phone. I’m counting the hours until my hands will get the ordered Samsung Omnia 7 and I’ll be testing this app on real hardware. If everything goes well, expect yearly next week a feedback (and probably fixes & improvements) after using the app on WP7 device.

Code of this application is licensed under MIT license and available on GitHub.

Credits

Thanks to:

Special thanks to:

  • my friend Dumitru Cantemir for helping me with some code.
  • my daughter, for letting her dad working on this app. Even if sometimes it was …

DadAtWork

3 Comments

Handling Mouse Double Click event in Silverlight with Caliburn.Micro

There are times when you want to handle a “MouseDoubleClick” event in your code and execute something in your ViewModel as a response to the event . Back in the day, I’ve done few implementations of mechanism that will allow do this, for both WPF and Silverlight platforms, with different degrees of success and (developer) satisfaction. The one I’ll be talking is, so far, the prettiest and I like how it works. Mostly because of using Actions from Caliburn.Micro framework. The Actions mechanics gives a very neat way to execute logic in VM’s as a response to UI events. A typical example for declaring an action will be:

<Button Content="Remove"
        cal:Message.Attach="[Event Click] = [Action Remove($dataContext)]" />

Back to the Mouse Double Click or, better said, to lack of such event in Silverlight.

Most of implementations you’ll find in internet will play with catching sequential clicks or “MouseLeftButtonUp” events and then deciding, it was a double click or not (using TimeSpan and distance between clicks, sample implementation). The interesting bit however was to link this event to an Action to be executed by Caliburn.Micro on your ViewModel and reuse that for any visual elements.

First, I’ve set the API how I want to see it:

        <TextBlock Text="{Binding DisplayName}"
                   Behaviors:DoubleClickEvent.AttachAction="Open($datacontext)" />

It will be a behavior that can be attached to any UI Element. In Action string we’re skipping specification of what event will be the Action attached to, because we are emulating one event – DoubleClick.

Attaching of the Action string to MouseLeftButtonUp is the tricky part. Mostly because to achieve that I had to modify declaration of one method in Caliburn.Micro for making it public.  See this changeset in my CM fork if you’re interested in details, but I’ll be asking CM’s authors to incorporate the change in main repository.

Attaching action string:

private static void AttachActionToTarget(string text, DependencyObject d)
{
    var actionMessage = Parser.CreateMessage(d, text);

    var trigger = new ConditionalEventTrigger
    {
        EventName = "MouseLeftButtonUp",
        Condition = e => DoubleClickCatcher.IsDoubleClick(d, e)
    };
    trigger.Actions.Add(actionMessage);

    Interaction.GetTriggers(d).Add(trigger);
}

ConditionalEventTrigger is a small class that wraps EventTrigger and adding a condition that will be checked before raising event. If it’s false, event will not be raised. Snippet:

public class ConditionalEventTrigger : EventTrigger
{
    public Func<EventArgs, bool> Condition { get; set; }

    protected override void OnEvent(EventArgs eventArgs)
    {
        if (Condition(eventArgs))
            base.OnEvent(eventArgs);
    }
}

I’ll not show here DoubleClickCatcher class because it’s not small, but you can find all related classes in this gist on GitHub.

So far, I’m satisfied by this solution. Neat, simple and it works like a charm for us. I’ve used it with ListBox and DataGrid controls, but I think it should work on pretty any other visual element.

Complete source code. Use with care. Any suggestions, remarks or bug reports are welcome.

6 Comments

Visual composition and extensibility are done right…

… when in order to look at some debug data in runtime you’re not writing log messages, not inspecting with debugger your data, not dumping structures to files. Instead, you’re taking the most confortable route, which is write a Widget and show it in the Dashboard of your app. Oh my, that was really fun to discover.

How to cook it – Silverlight, Castle Winsor and Caliburn Micro. Add a good part of ‘conventions over configuration’. Mixing together you’re implementing the Concept – Dashboard and Widgets. After internal mechanics are done (and tested), adding new Features (concrete Widgets) are piece of cake.

Additional reading  – Ayende about Concepts and Features.

Leave a Comment

Multi-targeting with Project Linker by example: Castle.Core for Silverlight 4

In this post I would try to explore multi-targeting of a .NET project/solution using Project Linker tool. My main driver is desire to target one of our internal projects to Silverlight. I’ve picked Castle.Core to serve as an example, since his Silverlight build is now broken and (from what I’ve seen) there is no convenient way to work with this project in Visual Studio while targeting Silverlight.

For more details and screenshots of Project Linker, please refer to this MSDN article.

Let’s go, step by step instructions:

  1. Go to Extension Manager in VS 2010 and search for Project Linker.
  2. Install Project Linker extension
  3. Create new solution, say Castle.Core-SL
  4. Add to this solution the existent Castle.Core project (targeted for NET 4 Client Profile)
  5. Add to solution new Silverlight 4 project, named Castle.Core-SL
  6. Click on Castle.Core-SL project and from context menu choose “Add project link…”
  7. In “Select Source Project” dialog choose the Castle.Core project, click OK.
  8. To verify that projects are linked correctly, in VS Project menu choose “Edit links”: Source Project should be set to “Castle.Core”, and Target Project – “Castle.Core-SL”.
  9. In order to trigger real linking process (Project Linker is observing file changes in source project) I have a trick for you. Go to Castle.Core project, then select all folders containing source files (Components.DictionaryAdapter, Core and DynamicProxy) and click on “Exclude from project” in context menu. Then, after enabling “Show all files” options, add them back. Here Project Linker will kick in and will link all added source files to Target Project.

Then, we can do the same for project containing unit tests.

In case of Castle.Core there is another manual intervention required: filter out CastleBuild.snk file from being linked. To do that you have to open project file for your project and find an attribute in it called ProjectLinkerExcludeFilter. Add to the end of that value the string “;\.snk”. After that you should “Ad As Link” the key file manually.

If you want to “re-sync” both projects, you have to repeat only the 9th step.

Now, you’ll have your Castle.Core targeted to Silverlight with all source files from original .NET project. You’re now should be confortable enough exploring the code in Visual Studio and, why not, contribute…

Leave a Comment

Follow

Get every new post delivered to your Inbox.