Great addition that was desperately needed for multi-platform. It's not perfect yet, but is a great stride forward to delivering a cross-platform runtime. Please keep adding namespaces such as the new ones introduced in .NET 4 and 4.5. Thank you!
It is great tool, but as the other said, please add the namespace System.XML.Linq and System.ComponentModel.DataAnnotations.dll since they are available in new .net framework. http://support.microsoft.com/kb/2600211
This is an extremely useful tool. It has helped me a lot when designing data models for projects where the target platforms have not yet been finalized and where leaving open the option to add additional platforms in the future is desirable.
Love the tool!
I'm using the VS2012 portable libraries as supplemented by WP8. The titular member is supported by all platforms except XBox. In particular, it's supported on these platforms but not by portable libraries on these platforms: net40, net403, sl4, sl5, wp70, wp71. It *is* included for portable libraries on these platforms: net45, win8, wp8.
Could you add it to the earlier platforms as well? They already have SynchronizationContext, but I need SetSynchronizationContext in particular.
(VS2012/Win7x64 with KB2468871)
If I install Microsoft.Bcl.Async version 1.0.12-beta (and its dependency Microsoft.Bcl version 1.0.11-beta) into a new .NET 4.0 (or .NET 4.0.3) class library, I get warnings like:
The primary reference "Microsoft.Threading.Tasks" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0.3". To resolve this problem, either remove the reference "Microsoft.Threading.Tasks" or retarget your application to a framework version which contains "System.Runtime, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
If I attempt to use TaskEx, then these warnings cause an actual error.
Also, if I have a class library that is SL4 using MS.Bcl.Async, or if I have a class library targeting net40 or sl4 that references a pcl using MS.Bcl.Async, then I get warnings like this:
Consider app.config remapping of assembly "System.Runtime, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "184.108.40.206" [...\Test\bin\Release\System.Runtime.dll] to Version "220.127.116.11" [...\packages\Microsoft.Bcl.1.0.11-beta\lib\sl4\System.Runtime.dll] to solve conflict and get rid of warning.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly.
These warnings then cause the first warning/error when those libraries are used by a platform-specific library (net40 or sl4).
With regards to the Silverlight warning, can you go to the output window and paste the text around the MSB3247 warning? MSBuild will output the assemblies that are the cause. It's likely that a lack of an App.Config is also the problem.
I just tried extending my portable class library from .Net 4.5 and .Net Store Apps to include WP8 and now have a whole bunch of VB language related issues. Whilst I can work around some easily enough, it looks like I can't use Modules. That's not a big issue by itself, but it seems to take Extension Methods down with it. Not being able to use the = sign with strings also seems a bit dodgy.
I'm beginning to wonder if the WP8 SDK actually installed properly. I might test it on another machine...
Apologies for the inconvenience. We shipped a bug in the VB template that prevents this from working when targeting just those three platforms. You can workaround it by opening the project file in a text editor (Right-click -> Unload, Right-click -> Edit) and adding <VBRuntime>Embed</VBRuntime> just under the <ProjectTypeGuids> element.
It's not official but the Silverlight 5 compiler *does* already support automatically looking up caller members to alleviate implementing INotifyPropertyChanged.
You'd have to add the class System.Runtime.CompilerServices.CallerMemberNameAttribute manually in your library, believe it or not!
Weird. So, would be nice if the Portable Class Library would support this and provide the class out-of-the-box and officially.
Thanks for the suggestion. If you wait a couple of more days, your wish will be granted. :) Keep a watch out for the async update that we talk about here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2691068-support-async-in-portable-class-libraries. This will include CallMemberNameAttribute support.
They've been RC stage for a month, and Visual Studio 2012 which uses the newer portable libraries has already released. Due to policy I can't use them until ther are officially released so I'm stuck on the old Portable Library tools which aren't even available from Microsoft anymore.
I can't find HttpWebRequest.ServicePoint or System.Net.ServicePoint.Expect100Continue property in PCL that likes other .net platforms has.
Can I excluding the Expect header from HttpWebRequest? or any other workaround?
It is basically impossible to use XmlAnyElementAttribute as per the documentation since XmlElement is not supported.
I added a Service Reference and the IMyServiceReference interface is empty and no operations are generated in the IMyServiceReferenceClient.
I was trying to convert a current solution to use Portable Class Libraries. So I created a new project, and just added the Service Reference.
I develop for WP7, WinRT and .NET 4.5 (App Push Notifications). Please add supoport for GeoCoordinate. I use it in several of my models and it is supported by all environments except WinRT where they have changed things and used a different class (Why?).
When I'm creating a Service Reference in a Portable Library, I get problems when the WCF service (on the server!) is configured to use the transport clientCredentialType "windows".
I get a "custom tool error" that says "the transport of 'windows' is not supported".
I'll have to remove this configuration at the server, then create or update the service reference, and then I can add this configuration again.
This is annoying, I think the Portable Library should rather simply not care and create the proxy code anyway.
Thanks for the feedback, basically the reason you are getting an error, is because "windows" isn't supported everywhere (ie Phone), and we're blocking you from creating a service reference that won't work at runtime. Unfortunately, we have a limitation where we don't currently decide that based on whether you are targeting Phone or not.
Would you prefer us to the create the service anyway?