I'm writing a Windows Phone framework with Windows 8 in mind. That means I'm creating a Portable Class Library (PCL) to be used in both platforms.
Right now my PCL is targeting .NET 4.5, Windows Phone 8 and Windows Store apps, as you can see in the project properties.
In that project I need to use Path.DirectorySeparatorChar but I get the following error from the compiler:
System.IO.Path' does not contain a definition for 'DirectorySeparatorChar'
I understand that that particular char might be different in the different targeted OS (I really don't know if they are) but why is the compiler complaining about it? I mean, the property help doc says it is supported by .net framework 4.5, am I targeting the right framework? Is the PCL really targeting the full .net framework 4.5?
With respect to Path.DirectorySeparatorChar:
As far as I remember we've removed it from Windows Store in order to discourage manual parsing of paths. In general you should use Path.Combine() for assembling paths and Path.GetDirectoryName() for splitting them up. In order to check for invalid chars, there is another method that allows retrieving those.
So practically speaking, what do you need the property for?
Update: To answer your original question around understanding profiles: The profiles represent API intersections between the platforms you've selected in the PCL dialog. Generally speaking, the fewer platforms you target and the more recent the versions, the more APIs you get. Checking all platforms in the oldest version basically gives you the lowest common denominator.
Since you've targeted .NET 4.5 and .NET Windows Store, you can't access Path.DirectorySeparatorChar because that property isn't included in Windows Store.
So, here's the actual answer to this question taken from the MSDN forum.
When you are creating a PCL, you can only have a subset of API-s that are defined in that particular profile. A profile is a list of API-s visible in all platforms.
Now, even if some API exists in both individiual platforms, this doesn't mean that it will automatically be in the PCL profile. Why is it missing is anyone's guess, but you cannot infer those reasons yourself.
If you take a look at the official documentation on MSDN (Cross-Platform Development with the .NET Framework), you'll notice that there are several constraints on what can be shared. I guess that that particular property doesn't satisfy those constraints.
And a good way of knowing is a particular method is supported relies on the icons of the documentation
Your PCL can use .NET methods which are available to all of its targets. Since PathDirectorySeparator isn't available to Windows Store apps it isn't available in PCLs targeting Windows Store apps. You can see that it doesn't have the green shopping bag marker for store support at http://msdn.microsoft.com/en-us/library/system.io.path.aspx
Related
I am working on extending number of supported platforms for my app, it used to support .NET4/Windows Store/Windows Phone, but I hope to also cover Mono for Android and iOS. I've put all business logic, models and view models to portable class libraries (PCL) but it's a big dilemma what subset of platforms I should target. Each combination causes something to fail. Here are the results for 4 platforms that I might use:
Profile 78 (NET45+WP8+Store): no problem with TPL,await/async and support for CallerMemberName attribute (used in BindableBase view model base class). But the Mono.Android project that refers such library fails to build complaining about non-present System.Runtime.dll that should be referenced.
Profile 104 (NET45+SL4+WP75+Store): await/async don't work, CallerMember name not found, but if I remove all references to them, Android project builds fine.
Profile 147 (NET403+SL5+WP8+Store): await/async don't work, CallerMember name not found, but if I remove all references to them, Android project builds fine.
Profile 158 (NET45+SL5+WP8+Store): await/async don't work, CallerMember name not found, but if I remove all references to them, Android project builds fine.
So I am not really sure what to choose. Profiles 78, 104, 147 are limited, profile 78 is the only one that supports both await/async and CallerMemberName used BindableBase, but it fails on Android complaining about System.Runtime.dll. So if you have an experience with what PCL profile is the best match for PCL targeting Mono, please share your thoughts.
Thinking about profile numbers is hard - I prefer to think in terms of the platforms.
Ideally I'd love my projects to support:
.Net 3.5 and higher
SL3 and higher
WP7.x phone and higher
MonoDroid 1.6 and higher
MonoTouch iOS6 and higher
(Mac desktop OSX Lion)
The main PCL project I support is MvvmCross - which requires Mvvm 'facilities' like ICommand. These facilities are only available in platforms for .Net 4.5 and higher... that's a hard limit - nothing I can do about it - so changes my needs to:
.Net 3.5 and higher .Net 4.5
SL3 and higher SL4 and higher
WP7.x phone and higher
MonoDroid 1.6 and higher
MonoTouch iOS6 and higher
(Mac desktop OSX Lion)
With this selection in place, then this leads me to a profile number - 104 (no idea how the platform decided this... gave up asking a long time ago!)
So I've targeted MvvmCross at profile 104 - and it will stay there while WP7.x support is still needed.
This selection does mean that MvvmCross cannot out-of-the-box support things like async/await and CallerMemberName - but this is a compromise we've decided to make - we have users who need WP7.
However, some people are asking about await/async...
To use these new features, there are some BCL.Async Nuget hacks to make them work in profile 104... or these users can target their apps at a newer profile (one that doesn't support WP7.x and SL4) - this leads them to build their apps in profile 78, but to add references to my profile 104 assemblies.
Neither of these sets of solutions works very well with the Xamarin twins at present - e.g. you hit issues like the missing System.Runtime.dll assembly. However, I anticipate that when Xamarin officially supports PCLs (and after some alpha/beta testing) then these problems will be resolved. This official support is due very soon now - which is why I don't bother expending too much of my time thinking about these problems...
I expect in the medium term that MvvmCross will drop support for WP7.x and SL4. When that happens, we may also move the core libraries to profile 78.
The only other large platform I know that has started PCL support is ReactiveUI. I believe this platform must use profile 78 because the PCL version of Reactive from Microsoft is targeting 78.
My scenario: trying to port a small part of an application created by our company from native code (ObjC for iOS / Java for Android) to C-Sharp. The project will interact with our webservices. Goal of this project is figuring out how feasible it is to port our whole app to Mono.
To create URLs, I'd like to use String.Format(). I thought it'd be a wise idea to put this 'service layer' inside a Portable Class Library (PCL) since I don't expect this code to change across platforms. Sadly, it seems the String library is not available for PCLs.
So my question is the following:
I think the main advantage of PCLs over "normal" libraries is that they shouldn't need a recompile for different platforms. Is this assumption correct?
This experience makes me think that for the moment PCLs are rather limited. Should I try to stick with PCLs and work around these kinds of issues, or might it be better to stick with a "normal" library for now? --- I'll assume the "normal" library has more functionality exposed.
You can use PCLs currently across many platforms, but it does require some small hacks to your setup.
These hacks are listed in http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
Once you've got those working then the functionality available is quite broad - and it definitely includes things like String.Format
For the situations where the PCL profile is not broad enough, then you can use several techniques for extending them - see http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx . The technique I generally use is to use MvvmCross Plugins - which are basically PCL interfaces with platform specific implementations. But these plugins are generally at the level of 'make bluetooth work' rather than at the level of String.Format
I do lots of PCL work across WinRT, WP, WPF, MonoTouch and Mono for Android - see http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html for lots of links to PCL work.
It's true that Xamarin have recommended not using PCLs for a couple of years, but that situation has now changed and the official support for PCLs is under way - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html
From a development perspective - especially from the point of view of using refactoring and testing tools - I don't hesitate to recommend you use PCLs now... especially for operations at the String.Format level. However, each project is unique... so it's not always the right answer.
One important note: right now it's better to not reuse the PCL binary files across to the MonoTouch platform - for now, build your portable libraries against the specific MonoTouch library platform. See http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html?m=1
Perhaps you want to look at the efforts other who have got PCLs working to a considerable degree with monotouch and monodroid.
For example see http://www.slideshare.net/cirrious/mvvm-cross-going-portable . You'll also find instructions on how to setup PCL support for MVVMCross here http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html .
Xamarin has recently committed to providing far greater PCL support rather than some of the workarounds that people have been having to make, but it is worth the effort.
I can't seem to figure out how to get F# TypeProviders to work in a Windows Store (C#) app.
As far as I can tell, TypeProviders can only be used in an assembly targeting the full .NET Framework, whereas Windows Store apps must target .NET Portable.
I have created an F# assembly and referenced the F# TypeProviders library, however when attempting to reference this assembly from my Windows Store app, I receive an error stating that the library could not be referenced.
Is there any way around this? I want to use F# TypeProviders to reference various data sources and then use the generated code/types in my Windows Store app. Anyone have experience with this?
UPDATE:
Just to be clear, I am asking if there is a way to use the standard F# TypeProviders (such as WsdlService) in a Windows Store App?
Looking at the other assemblies FSharp.Data.TypeProviders.dll is referencing, I don't think there is a way around this. Since most type providers are used for accessing a database in one way or another (ADO.NET, LINQ to SQL, EF), it references System.Data.dll which is not available in WinRT.
The only data sources supported by built-in type providers that can be used in WinRT are web services and OData services. Their type providers maybe could be supported in a WinRT project if they were implemented in a separate library, but not in their current implementation.
Type providers are design/compile time facility. It should work in Portable library profile. It is maybe dependent on how is type provider library implemented, but in general, it should work.
For more info see F# type providers with Portable Library
I'm new to objective-c & osx architecture. I started playing with building a framework and then using it. I followed this great tutorial.
During the tutorial, I had to set the framework's target's Dynamic Library Install Name to #rpath/MyFramework.framework/Versions/A/MyFramework. My understanding is that #rpath will expand to the loader's (consumer's) run-path search paths.
It seems as if the responsibility of loading the framework is split between the framework author and the consumer author. Could someone please explain why the author of the framework needs to be concerned with the consumer's run-path search path? For example, if the framework-author set the Dynamic Library Install Name to point to some random directory (instead of #rpath) how would the client be able to consume the framework?
Thanks in advance.
It depends a lot on how the framework is being used. And it's important to remember that the framework construct has existed for a long time on the platform.
For a system framework, such as the ones that Apple creates, you're going to be quite happy that they keep the frameworks in a known location. In those cases, the paths that they use are fixed for the OS, and it guarantees that you don't accidentally load the wrong one. Further, as indicated in the Framework documentation, these frameworks are loaded only once on the machine, regardless of how many times they are used (see Apple:What Are Frameworks) . The benefit here is performance and it is for both the code and the resources in many cases.
Due to the recent move to randomize framework locations,and Apple's comments in the release notes that "Mountain Lion randomly relocates the kernel, kexts, and system frameworks at system boot," it certainly appears they're still sharing these resources, and thus still gaining from this benefit.
For embedded frameworks, the situation is a lot more tedious, and Apple has moved through a variety of methods over the years to make it easier to find frameworks wherever they may be. Due, again, to the shared nature, it would make sense for Applications which share common library requirements to share them on the machine, both for purposes of efficiency, and to make sure they're at the same version if they're sharing data. So, for example, if you have two separate apps that use the same framework to work with shared data, you might put the shared framework in /Library/Frameworks and have both apps explicitly look for that, making sure that some other (possibly older) version of the framework, that has been loaded by another App, is not used instead.
In the end, there's a lot of flexibility for the Framework producer and consumer the way that it currently works. It means that the developer can decide to share a framework, include a private copy of the framework, or even do both, depending upon whether the framework exists on the machine or not. However, the price for that flexibility is the complexity that we have today.
Another example of a reason you might not want to use #rpath specifically is for tightly-linked embedded frameworks (yes, people embed frameworks within other frameworks). In these cases, you don't know where the first framework is loaded, but you want to put the embedded framework inside of it, so that they stay together. In this case #loader_path is relative to the code that is loading it, so that your plug-in's framework can find its resources correctly.
In answer to your specific example about somebody setting the Dynamic Library Install Name
to a "random" location. In this case, you'd have to know that location. There might be many reasons for somebody doing this, such as wanting to discourage reuse by other programs, or because there are large resources within the framework that should only be installed in a known shared location.
The new Metro style / WinRT apps in Windows 8 have certain restrictions as to which APIs you can call. Also, you have to use asyncronous techniques and your app has to be pauseable, etc.. I'm wondering how, and if all of this is enforced.
Are the new Metro apps simply execuable programs, or are they something else (e.g. more like COM controls, with a set of defined interfaces)? How are the API restrictions enforced, at compilation, at runtime (via sandboxing etc.) or just via Windows Store policy (similar to the situation in iOS)? If I was feeling devious, could I e.g. get a handle to the screen and manipulate the interface, add floating windows on top, launch something in the background, or otherwise break out of the confines of Metro?
One reason I'm asking is that I'm looking into creating a WinRT library for Python, so that one could use it for writing Metro apps. However, the Python core obviously uses a lot of non-WinRT API calls, so this might be doomed from the beginning. I'd also like to get a feel for the anatomy of Metro apps in general.
Edit: According to this thread, you have all the functions of the C runtime available. It seems like you can compile stuff that calls forbidden functions, but the "application verifier" complains. I'm wondering if you could just run such a hybrid app, if you don't care about the Store (and maybe make it Store compatible later by writing workarounds for the forbidden functions)...
There are (at least) two separate sets of technical restrictions on what a Metro style Windows Store app can do.
The first is a set of security restrictions: Windows Store apps run with low privileges, and thus are limited in how they are permitted to interact with the rest of the system. For example, a Windows Store app cannot access arbitrary locations in the filesystem, it can only access files in a predefined set of locations, and files to which the system expressly gives access. You cannot violate these security restrictions (if you could, that would be a rather problematic operating system bug).
The second set of restrictions is the API partitioning. Windows Store apps are only permitted to call system functions that are present in the App Partition. The documentation for each system function on MSDN specifies whether the function is present in the App Partition. You can also find out by looking in the header file that defines the function: functions are conditionally defined depending on the API partition targeted by the project: the WINAPI_FAMILY macro controls this (see winapifamily.h in the Windows SDK for more information).
If you call an "unapproved" function, the results are undefined. It might appear to work; it might fail catastrophically. It might appear to work fine today and fail catastrophically tomorrow (or after a Windows update is applied, or with the next version of Windows).
The API partitioning is enforced in various ways. The headers are constructed such that it is difficult to call an unapproved function. If you define the function yourself or change the WINAPI_FAMILY, your app will fail the Windows App Certification Kit (WACK) process. My understanding is that the CLR prohibits calls to unapproved .NET functionality at runtime, though I am less familiar with the .NET restrictions. In any case, my understanding is that if your app calls an unapproved function, you cannot submit it to the store, per the "Windows 8 app certification requirements" (please read those requirements yourself, though; I have not read them in detail and I certainly can't interpret them for you).
If you don't care about submitting your application to the Windows Store or just want to write some test apps or play with WinRT, then there's nothing stopping you from trying to call unapproved functions. For example, I find it is useful to create a console window for debugging purposes. That appears to work fine, and I don't much care that it fails Windows Store certification since it's for debugging and testing only.
They aren't standard executables. You're restricted to a subset of .Net 4.5 to create the applications which doesn't let you (or rather, makes it extremely difficult to) do anything that MS don't want Metro apps doing. They're pretty heavily sandboxed as well.
You have a limited part of the .net api available:
The .NET Framework provides a subset of managed types that you can use
to create Metro style apps for Windows using C# or Visual Basic. This
subset of managed types is called the .NET for Windows Store apps and
enables .NET Framework developers to create Metro style apps within a
familiar programming framework. Any types that are not related to
developing Metro style apps are not included in the subset.
You use
these managed types with types from the Windows Runtime API to create
Metro style apps. Typically, you won't notice any differences between
using the managed types and the Windows Runtime types except that the
managed types reside in namespaces that start with System, and the
Windows Runtime types reside in namespaces that start with Windows.
Together, the .NET for Windows Store apps and the Windows Runtime
provide the complete set of types and members available for developing
Metro style apps with C# or Visual Basic.
There are app store requirements.
3.1 You must use only the Metro style APIs to implement the features of your Metro style app We describe these APIs in the Metro style apps
API reference. Your app may only depend on software listed in the
Windows Store.
Apps are sandboxed.
In short, you must you the api provided.