First off, here's a puppy with a warning:
This could be nothing, or people might be interested in it.
I was skimming over some old Win8 posts today, and got to thinking "What other crazy things could I start up?"
So I tweeted something:
an experiment in crowd-sourcing - what problems would you like to see me tackle for WinRT dev? add your ideas here github.com/shiftkey/winrt…
— Brendan Forster (@shiftkey) July 3, 2012
And this reply came back:
<script src="//platform.twitter.com/widgets.js" charset="utf-8"></script>@shiftkey Port Windows.Foundation to Desktop CLR. And errrr, blog about it I guess.
— Paul Betts (@xpaulbettsx) July 3, 2012
So I've taken Paul's suggestion and gone a bit further:
- Provide an interface which is forward-compatible but works on their current platform (for some subset of the .NET ecosystem)
- Allow library authors to migrate existing code gradually
- As WinRT favours interfaces for much of its core, testability of existing libraries should not be harmed
What sorts of libraries did you have in mind?
- Libraries which depend on the filesystem
- ? Libraries which depend on the network
- Scenarios where Portable Class Libraries is not suitable (TODO: which?)
- ????
What sorts of libraries are not suited to this approach?
- Libraries which use reflection heavily
- ????
Hell, I'm not even sure if this is legal. But anyway, here's what I've done so far.
- Use ILSpy to output the class definitions inside Windows.winmd (yes, it works).
- Hidden a bunch of namespaces temporarily to focus on Windows.Foundations.* and Windows.Storage.*
- Cleanup the existing code so that it compiles (no implementations behind the scenes so plenty of warnings)
- Grab the latest build of NLog and add to source.
- Create a new class library targeting NETFX_CORE to test for compilation.
- Use FileTarget (for example) to pull in enough files to get the code to compile
So for this case there's these three classes missing (without modifying any code):
- FileStream
- StackTrace
- System.Threading.Timer
Which leads to an interesting topic:
I've been experimenting with a number of .NET OSS projects over the past few months to see where their pain points are and its generally come down to these sorts of behaviours:
- this code is real important, and I want to run it on a different platform without modifying source
- this code is real ugly, and I'd love an option to keep supporting the existing code and clean it up
- i know this code isn't going to be supported in the future, so I need a way to switch it off
And these are the sorts of strategies I've used:
- extension methods (for example, reflection) with minimal changes in the source to allow the implementation to be swapped out. Aliases is another one (used very well in JSON.NET)
- an adapter to map the existing implementation to a new interface (less friction, short-term fix) or expose the new interface with the existing implementation behind it (more friction, long-term fix).
- conditional compilation (although partial classes may be an option if the code can be refactored to separate core and platform-specific code).
- Experiment with how we can apply different shims/strategies to migrate NLog with minimal interruption
- Expand the code porting process to identify more things
- Prove this is feasible
Yes. I've got evidence from co-workers who agree with you. Your point?
I'm looking for OSS projects you'd like to use in Metro Style apps but haven't been brought across.
Skip these types of libraries:
- testing and mocking libraries (something I'm already looking at - with the help of others, requires a different approach altogether)
- ORM/data access libraries (they're likely dependent on ADO.NET - which just isn't there. Unless you've got a bright idea on this of course).
- anything UI-specific - I'm drawing the line here for now. Nothing personal.
And of course you can bug me on Twitter about any of the above.