Base types, Collections, Diagnostics, IO, RegEx…
Today we're announcing the CTP release of a new add-in for
Visual Studio 2010 that makes it easy to create C# and Visual Basic libraries
that run on a variety of .NET platforms without recompilation.
Download the Portable
Library Tools CTP today (install VS 2010 SP1 Beta first).
The Portable Library Tools CTP adds a new "Portable Class
Library" project template to Visual Studio that can be used to create class libraries
in C# and VB that run on the various .NET platforms without recompiling.
Portable Class Library projects and assemblies can be
referenced and used by .NET 4, Silverlight 4, Windows Phone 7, and XNA for Xbox
Within a Portable Class Library project, you can specify
which .NET platforms the library is intended to run on. Although there is a 'core' set APIs that are
available on all platforms, there are also some APIs that are only available on
certain platforms. An example of an API
that exists on some platforms but not others is MEF. Windows Phone and Xbox 360 do not currently
have built-in support for MEF, but .NET and Silverlight do. If you want to use MEF within a portable
library, the library will currently only run on .NET and Silverlight.
Thus, the project's selected target platforms determine
which APIs can be used within the project.
The APIs that are shown in intellisense and available to the compiler
are automatically filtered based on the selected target platforms, so you don't
need to have any special knowledge about each platform or worry about
inadvertently using an API that doesn't exist on a platform that you're
targeting. The project system takes care
of this for you.
In the future, as the underlying platforms evolve to support
more APIs that could be portable, we'll update the API surface available to
portable libraries as appropriate.
The following table summarizes the high-level functionality currently
available on each platform:
Note: Once you've installed the Portable Library Tools CTP,
you can use the Object Browser in Visual Studio for a more in-depth look at the
individual APIs available for use within portable libraries.
You can write a surprising amount of portable code with the
subset of APIs currently available to portable libraries. Everything from business logic to web service
client proxies can be portable. This
enables you to implement most, if not all, application logic in portable
assemblies (and then use the portable assemblies in apps that have
form-factor-specific UIs for a given platform).
We're still in the process of defining the APIs that will be
available to portable libraries, so expect some minor tweaks and additions before
the final release of the tools. We'd
love to get your feedback on what's currently available in the CTP. Is there anything you think is missing that
should be available to portable libraries?
How easy was it to make your existing libraries portable?
The CTP of the Portable Library Tools is not a "go live"
release. There are still some rough
edges that need smoothing out before the final release. One area that does not currently have a
complete experience is around deploying portable libraries.
Making portable libraries work on platforms such as .NET
Framework 4 and Silverlight 4 required making some minor changes to those
platforms. In order for portable
libraries to work correctly on these platforms, you'll need to ensure the
necessary updates have been applied.
Silverlight for Windows Phone 7 and XNA Framework 4.0 for Xbox 360 do
not require any updates to run portable assemblies.
.NET Framework 4
An update to .NET Framework 4 is required to run portable
libraries. For developers, this update
is automatically installed as part of Visual Studio SP1 Beta, so you shouldn't
need to install it on a machine that already has VS 2010 SP1 installed. A standalone beta of this update is currently
available for download here. The final release of the Portable Library
Tools will provide a way for developers to add a prerequisite to their
installer to ensure the update is applied on end-user machines when your app is
An update to Silverlight 4 is required to run portable
libraries. This update hasn't been
released yet, but the impact in the meantime should be limited. As long as you avoid using the following APIs
in your portable libraries, they will run just fine on Silverlight 4 without
In the meantime, if you need to dispose these objects, you
can wrap them in a using statement or cast the object to IDisposable before
Once the Silverlight 4 update is available, we will provide
instructions on how to specify it as the minimum version required for your
The Add Service Reference is currently disabled for VB
projects. This will be resolved in a
We're excited to make a CTP of the Portable
Library Tools available for you to try out.
Download the CTP today and let us know what you think!
Also, you may be interested in watching Shawn Burke's PDC
2010 session on 3-Screen
Coding: Sharing code between Windows Phone, Silverlight, and .NET, which
provides some more background on portable libraries.
It would be great to hook into Mono MOMA and include Mono as a target.
I second what Gareth said. Mono, MonoTouch/MonoDroid support would be great.
Exactly my thoughts on Mono. Miguel, are you reading this?
What about deploying one of those portable libraries to SQLCLR? As I understand the Core BCL and Core XML (of most of them) could be run from with SQLCLR. Or am I missing something?
Could this be open source? Should this be open source? Being able to help with issues, offer wrappers, and target other platforms (Micro CLR, Mono) would be great reasons.
So can we add a project reference to a "portable library" from both .NET and Silverlight apps? I know the binary compatibility is there as of .NET 4/SL4, but Visual Studio won't let you add a project reference -- you have to browse to the .dll and add a reference to that, and so it doesn't rebuild when it needs to.
Will there be a way to use something better than the absolute lowest common denominator? It would be fantastic to be able to write ViewModel logic, INotifyPropertyChanged, etc. to share between a .NET app and a Silverlight app. I don't care about XNA or phone, so I don't want functionality taken away just because they don't support something.
This is one of the new project types that uses the VBCore functionality implemented in SP1
Yes! We're planning to get in touch with Miguel on this soon.
I'm not too familiar with SQLCLR, but I believe right now SQLCLR only supports the .NET 2.0/3.0/3.5 CLR and portable libraries require .NET 4 with the update mentioned in the blog post. If that's the case, it isn't going to work today. However, in theory, when SQLCLR adds support for the .NET 4 CLR, portable libraries will likely just work, though, this isn't something we're explicitly testing right now. We'll keep it in mind for the future.
Re: Open Source
I'm not sure if we're going to make the tools open source, but we are planning to make it so that other target frameworks can be easily plugged in (without having to recompile the tools).
Re: Project references
Yes, project to project references work as you'd expect. We've made the necessary changes to Visual Studio for this to work without it complaining and forcing you to add references to the .dll instead of the project.
It should be possible to create ViewModels in portable libraries. INotifyPropertyChanged is available. However, the CTP currently doesn't provide INotifyCollectionChanged or ObservableCollection<T>, so you have to use some dependency injection tricks to get things to work, but it is possible. Shawn Burke is planning some blog posts that show how to do it. We're also still tweaking the APIs and will likely make it possible to use ObservableCollection<T> and friends when targeting some of the platforms.
Hope this helps,
Great news! I'm working on a project that compiles to all these platforms (including Mono) and managing all the .csproj has been a real pain.
This is great news. I hope this makes its way into Visual Studio proper in the next release (or even the next service pack!!). This solves problems I face in my job every day, where we have a need to develop common libraries to use across multiple .NET-based platforms. I cannot stress enough how glad I am to see this being given the attention it deserves!
One aspect that is sorely missing is support for .NET Compact. Windows Mobile, now supposedly known as Windows Embedded Handheld, runs on rugged data collection devices in many major enterprises. My employer has spent years and many, many millions of dollars developing applications for this platform, and we have tens of thousands (and growing) such devices in the field, running Windows Mobile 5, 6.x, and even some older 2003 devices. As you no doubt know, these devices run the .NET Compact framework. Unfortunately, .NET Compact represents a different subset of the full .NET than Silverlight does. For the applications that run on these devices, Windows Phone 7 is not even close to being a viable option, so for the foreseeable future we will continue to run on the current platform.
It does seem that Microsoft is still trying to figure out the future direction of Windows Embedded Handheld (WEH). That said, assuming backwards compatibility remains important and the .NET Compact framework eventually gets upgraded to v4 and gains Visual Studio 2010 support, I would suggest that adding the .NET Compact framework to the Portable Library Tools would be in order. I'm not sure exactly how the subset of .NET representing the compact framework would mesh with the BCL Core, XML Core, HTTP Core, etc. If it ends up just being a few isolated classes or methods, hopefully those can make their way into the next release of Silverlight and Windows Phone 7, to maximize the available capabilities of libraries made to be shared across platforms.
If .NET Compact could get upgraded to the latest version of .NET, have Windows Mobile/WEH get Visual Studio 2010 support, and support added to the Portable Library Tools, this would represent a *huge* step forward for many large enterprises that rely on that platform for their critical line of business applications!!
Thanks again for prompting compatibility across the different .NET platforms!
Is there a reason that the SP1 beta is taking over an hour to install? It doesn't seem to be frozen since it's now installing a different component than it was 20 minutes ago.