In my PCL I am trying to call to an SSL service so I am trying to set ServerCertificateValidationCallback like so:
System.Net.ServicePointManager.ServerCertificateValidationCallback = ValidateServerCertficate;
but it seems I can't add a reference to System.Net in my PCL and it says the type ServicePointManager does not exist.
How do I reference this in my PCL?
You can't reference this in your pcl - it isn't defined in any current portable subset.
If you need to use it, you can reference it in some of your Ui projects - eg in your setup class - or for reuse you can build a plugin to reference it for some platforms. However there are some modern platforms which simply don't support it - WindowsPhone (and perhaps windows store too?)
For more on injecting platform specific code into pcl core libraries, see http://slodge.blogspot.co.uk/2013/06/n31-injection-platform-specific.html
Related
I'd like to create a library, which can be used within Xamarin projects.
I also want to reuse iOS as well as Android libraries (static lib & jar). Therefore I created a solution which contains an Android binding project as well as an iOS binding project.
To expose this functionality I'd like to create a single wrapper class (within a shared project), which forwards the call to the appropriate native lib. I first thought that this could be done with the use of if-makros. Unfortunately, it seems like I can't add references to a shared project, which means I am not able to call the binded methods.
Could you expose an interface in your shared library that each platform implements with their specific binding implementation and reference everything through that?
MonoTouch Binding refers to my Static Library, which uses FacebookSDK.
Сhain projects:
MonoTouch App -> MonoTouch Binding -> My Static Library -> FacebookSDK
When you add interfaces ApiDefinition, arise errors associated with FacebookSDK how to solve this problem? Maybe someone has already encountered this problem?
Error MT5211: Native linking failed, undefined Objective-C class:
_OBJC_CLASS_$_FBFriendPickerViewController. If '_OBJC_CLASS_$_FBFriendPickerViewController' is a
protocol from a third-party binding, please check that it has the [Protocol] attribute in its
api definition file, otherwise verify that all the necessary frameworks have been referenced and
native libraries are properly linked in. (MT5211)
Remove reference of current the Facebook SDK framework and add the Facebook SDK again by drag and drop it in framework folder.
This will add Facebook SDK path automatically.
I have a WPF application which utilizes a handwriting control.
By using an
<InkCanvas></InkCanvas>
In my XAML, I was able to get the user's strokes, and turn them into text using the InkAnalysis class. However, this is strictly 32bit, and my requirements dictate a 64bit build.
Unable to find a 64bit compatible library, I looked into upgrading to .NET 4.5 and utilizing the Windows8 classes which are available to desktop apps (by also adding
<TargetPlatformVersion>8.1</TargetPlatformVersion> to the csproj file so that I could add the 'Windows' namespace references). Luckily, Windows.UI.Input.Inking is.
However, when I add the reference to Windows.UI.Input.Inking, I get a build error which states:
Unknown build error, 'Cannot resolve dependency to Windows Runtime type 'Windows.Foundation.Metadata.PlatformAttribute'. When using the ReflectionOnly APIs, dependent Windows Runtime assemblies must be resolved on demand through the ReflectionOnlyNamespaceResolve event.'
I have looked into the:
Windows.Foundation.Metadata.PlatformAttribute
And it seems to want an enum member, either:
Windows.Foundation.Metadata.Platform.Windows
or
Windows.Foundation.Metadata.Platform.WindowsPhone
This is a desktop application, so I would obviously choose to target Platform.Windows, but cannot figure out how to tell the compiler this.
How can I incorporate this Windows.UI.Input.Inking class into my WPF application? My end goal is simply to convert strokes from the inkcanvas into text, in a 64 bit environment.
I discovered that I was receiving this error due to the reference added to the:
Windows.UI.Input.Inking
library. It seems that the correct way to add reference to Windows 8/8.1 WinAPI components (from a non WinAPI application) is the following:
Add <TargetPlatformVersion>8.1</TargetPlatformVersion> to the csproj file
Add reference to the Windows library (this is the key - adding the specific lib, in this case, Windows.UI.Input.Inking, causes the build error)
Add the more specific (ex: Windows.UI.Input.Inking) reference in the actual file where the API is required
I am working on creating a NuGet package which will edit the csproj file, and add the Windows reference. I'll update this if/when it is completed.
I am using Ninject IoC assembly - an external assembly for IoC , they support both mono and windows. but to work on mono a different compiled version of the assembly is needed.
I have the following problem:
I have a Domain.Core project that uses Ninject windows version
I have two additional project - Call them For.Mono and For.Windows, they both have reference for the Domain.Core project
The problem is that For Ninject to work on mono we have to compile it with a special compilation symbol.
Now the mono version will not work on windows, how can I have resolve the issue of using both versions in the same solution to have the following:
When I run the For.Mono project only the Mono version of Ninject is used, even if the Domain.Core project is using Ninject in some classes inside it's code and referencing the local to it's score windows version - I would like to override this with the Mono version somehow,
And use the Ninject windows version on the For.Windows project, this issue is trivial as it just works, but the first request I am asked to reference the windows version by the compiler when I use code from the Domain.Core in my For.Mono project. I understand that the compiler is right but how can I resolve this issue of cross-platform support with one code-base
Your question is not exactly clear, but from what I gather: You have shared base classes/interfaces in Domain.Core assembly that your project uses, you also have 2 sets of derived classes/interfaces (For.Windows and For.Mono) that provide platform specific implementation of classes/interfaces from Domain.Core. You want to have both For.XXX referenced from your solution.
I don't see problem with that approach. As long as your code only refers to classes from Domain.Core and instantiation code is wrapped in
if (platform = Platform1)
{
// must be function calls in both branches to avoid JIT-ing references
// to unsupporterd DLL for the other platform.
InstantiatePlatformOneClasses();
}
else
InstantiatePlatformTwoClasses();
there should be no problem at either compile or run-time.
Note: using some DI container will solve the same issues easier since you can simply configure it to pick platform specific implementations a run-time.
I am writing an n-layer app/site and in my Common class library I need to call on NetSqlAzMan Web reference but that cannot be imported into a class library, only into a website type project.
One way to get around it is to make my Common layer a site but that just doesn't seem right.
How to properly implement that?
I am using VS2010 Pro
Sounds like the project type of your class library is Client Profile instead of a normal one.
Client profile class libraries are not allowed to reference System.Web
If you change the target platform to ".NET Framework 4" you should be able to reference System.Web