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:

@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.

1. Use ILSpy to output the class definitions inside Windows.winmd (yes, it works).
2. Hidden a bunch of namespaces temporarily to focus on Windows.Foundations.* and Windows.Storage.*
3. Cleanup the existing code so that it compiles (no implementations behind the scenes so plenty of warnings)
4. Grab the latest build of NLog and add to source.
5. Create a new class library targeting NETFX_CORE to test for compilation.
6. 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.