Any plan for universal project?

May 14, 2014 at 11:26 PM
I am wondering if there is any plan for a version supporting the new universal project type. I think most of code (or all?) can go straight into a portal class library for the universal project supporting W8.1 and WP8.1. Am I overly optimistic?
May 15, 2014 at 12:04 AM
I've started working on it and it is actually close to working state, but I'm still fighting some weird problems that make it hard to predict when I will be done with it.

I got everything to compile and even display the charts on the phone correctly, but some problems with management of the content files, xbfs etc. still need to be resolved and then there's the problem of how this will be made available.

The current plan is:
  1. I am dropping support for Windows 8.0. You can still grab an older version of the source code that I plan to keep available from the currently checked in version which is the last one to support 8.0 and also you should still be able to get the last version of the NuGet package that supports 8.0, but I don't want to having to keep looking at that code, compiling it, testing etc. I am only one person working on this project for most of the time and I'd like to focus more on new features and supporting new platforms.
  2. The libraries will NOT be WinRT PCL. I could perhaps extract some of the code that's fully shareable between the platforms, but I expect there will be slight API differences and especially XAML/template differences (e.g. mouse/keyboard/focus rectangle support) and I won't have enough time to maintain both a shared PCL library and platform specific versions. Right now I'm trying to work with shared projects that come with VS 2013 Update 2 and so most of the code is going to live in a shared project with only different parts gradually getting separated into platform specific class libraries as I find the need to make the implementations different. I might use partial classes or #ifdefs as well depending on how much code can be shared and how much will be platform specific.
  3. I'm not going to make WinRT components to support C++ for now. This is more work and might limit the range of features I can build. It might happen some day for specific parts, but I don't have the time right now. I'm also assuming that if you have the resources to invest into building an app in C++ - you can invest to get my code working for C++. Perhaps just implementing a .NET based WinRT Component to wrap around my class libraries would work.
  4. For NuGet I'm planning to remove the 8.0 code from the current packages and create new packages for Windows Phone 8.1 since I feel like putting both platform versions in a single package might not make sense. Then again - perhaps I'll leave the old packages there and create new ones for Windows with different names. I haven't decided yet.
I'm open to any comments or suggestions.
May 15, 2014 at 12:49 AM
Thanks a lot for the effort. I look forward to the release.
As a user who loves this toolkit, the ideal package would be a project of the following type (in VS2013 update 2): Class Library (Portable for Universal Apps). Since you have been encouraging people to use the source code and I have also found the source code is handy when some minor changes need to be made or some understanding by looking at the source code is useful, I would love to just drop a Class Library (Portable for Universal Apps) project to my solution, and reference the library in every universal project. Is this the least time consuming approach for you?

I have created my own utility Class Library (Portable for Universal Apps), and I was happily surprised by how little change I need to make to port my Windows Store class library to this universal project library. Actually I don't think I made any substantial change of the code of dozens of methods beyond some naming changes when porting the code. Microsoft has apparently done a fantastic job in porting the code of W8.1 to WP8.1.
May 17, 2014 at 6:49 AM
The problem with PCL for WinRT is that it would need to have the same code for both W8.1 and WP8.1 and while most of the code in the toolkit can be shared - there are elements of it that can't - platform specific APIs, input APIs, control templates etc. It will actually be easier to have two separate libraries since I can then easily make any differences between them that might turn out to be necessary.
May 17, 2014 at 10:36 AM
Sorry for misunderstanding what you meant by WinRT PCL. It is apparently what I meant by PCL for universal apps. Two separate libraries will do it, and make little difference for users because references need to be added to W8.1 and WP8.1 projects separately anyway.

If you are using the new universal apps project, would that be sufficient for users like me who use source code? If I had the code, I would just reference that project in both W8.1 and WP8.1, and that would be all needed. Would this be the quickest approach? If it were available now, I would use it today for a universal apps project I am working on now.
May 19, 2014 at 5:04 PM
I pushed an early preview of the code to git. You can download it from

It will still require a lot of work to get everything right. For now I got it to display chart controls in an AlternativeFrame, but...
  1. The AlternativePage doesn't support BottomAppBar. I think I'll probably put a regular Page somewhere in the AlternativeFrame and have a BottomAppBar property on the AlternativePage forwarded to that standard Page control.
  2. The visual tree debugger kind of works on a phone, though obviously having a Window on the small phone screen is less than ideal and you currently have to manually walk the visual tree since you can't do Ctrl+Shift on the phone. I might finally have to go and make it work from a separate window.
  3. Templated controls look slightly different on the phone and so it will require some time to fork and polish all the templates. I haven't moved all the controls to a shared project yet.
  4. I will probably have to create phone versions of all the test/sample pages so I can test/fix the controls and templates which will be fairly time consuming.
  5. Creating NuGet packages of all of this will take time too.
I work on the toolkit in my free time when I am not working on the Windows Photos app, spending time with my family or doing chores, which isn't much, so please mind that things might take a while to happen. While creating one or two controls for Windows 8.0 or porting somethign from Silverlight Toolkit, with few users could be a quick job, now with all the libraries and tools and multiple platforms - one person doesn't scale anymore, so One Dev Job is a one slow job. :)
May 20, 2014 at 4:57 PM
Thanks a lot for the preview version.

I am trying to add it to my solution. When I compile WinRTXamlToolkit, I get the following error:
Error 141 The name 'AlternativeApplicationView' does not exist in the current context

Could you offer a tip on how to get around this?
May 21, 2014 at 1:22 AM
After I added "WINDOWS_APP" to the build conditional compilation symbols of WinRTXamlToolkit.Windows, the building is fine now.
May 21, 2014 at 2:11 AM
Is there a plan to port CameraCaptureControl to WP8.1?
May 21, 2014 at 2:41 AM
May 21, 2014 at 2:54 AM
Fantastic! I have noticed that you moved most controls from Windows to Shared.

Could you offer some tips on which projects should be included in a solution using WinRTXamllToolkit? I tried importing the entire solution into mine, but the results are not very good. I got a bunch of "The parameter is incorrect" errors, there is a problem with SharpDX. When I was importing just a few projects, it worked out fine.
May 21, 2014 at 1:46 PM
Running the sample (WinRTXamlToolkit.Sample.Windows) keeps making VS hang. I have restarted VS a few times. Everything builds fine. It gets stuck at "Registering the application to run from layout...".

I cannot add the sample project to my solution because it cannot get over an issue related to SharpDX. This is OK. I think it is better to check the sample project in the WinRTXamlToolkit solution.
May 21, 2014 at 5:17 PM
It really depends on which parts you're using. Personally I mostly use WinRTXamlToolkit and WinRTXamlToolkit.Debugging. You might also want the DataVisualization one if you use charts. If you target both Windows and Windows Phone - you'd include three projects for each - the .Windows, .WindowsPhone and .Shared. If you don't target .Windows - you can skip that and so on. You shouldn't need the .Composition one these days since that one made sense for Windows 8.0, but is largely obsolete with the RenderTargetBitmap class that came in Windows 8.1.
May 21, 2014 at 5:29 PM
Thanks a lot for clarification. Everything is ready to go now. Rebooting the machine solved the problem of running the sample project. I will start with the handy CameraCaptureControl.