VS gives me errors when I try to do it. Yet, it displays such projects as available to reference. Is it possible to add winRT project reference to the classic class library project somehow?
If not, how to bridge both worlds, so common logic can be stored in one place?
The short answer is yes. The long answer is that it's not supported and comes with some caveats that you need to understand.
See my answer here:
Using Custom Windows Runtime Components in Non-Metro Applications
VS2012 adds a "Portable Class Library" project type that allows you to select multiple targets, including the ability to target WinRT and full .Net 4.5 from one assembly.
See http://msdn.microsoft.com/en-us/library/gg597391.aspx.
Related
I want to modularize a monolithic application by using Java modules (introduced by Project Jigsaw).
Unfortunately I'm currently stuck to use Java 8. I would like to build those modules (jar files) anyway, but without the feature of using a module-info.java file for declaring the dependencies and the exported API.
Some weeks ago I stumbled upon an API/framework which allows to define nearly the same things that you can do in a module-info.java file. It could be used in JUnit tests in order to enforce module's not to use the internal's of another module and that module's only can access modules they explicitly depend on.
Of course you do not have any assistence from the compiler or the IDE, but you can enforce the access by JUnit. Unfortunately I do not find the project which provides the API any more.
Can anyone help?
Btw. if there is another good approach beside a unit test, please let me know, too!
https://www.archunit.org/ is what I have been looking for.
Is it possible to use MvvmCross with Shared Projects, or a similar technique of sharing code between projects? If so, How?
It seems MvvmCross is built around using PCL. If I use PCL, how do I overcome the problem of not being able to reference platform-specific 3rd-party libraries?
Thanks.
You can manually add App.cs class to your shared project. The same way you need to add your view models and other code. All namespaces will be automatically resolved. Look for solution explorer. In my case AppInit.cs inherits Cirrious.MvvmCross.ViewModels.MvxApplication
I'm trying to create a cross platform application using MVVMCross and portable class libraries, which interacts with an api and displays some data asynchronously.
Currently I am trying to generate a SHA512 hash value for a sign key that will be sent along to the api.
I am not exactly sure how I can implement the cryptology portion. I have tried using the SHA512 class, however it appears to be unavailable. I tried manually adding a reference to System.Security.Cryptology which didn't help.
I also tried additional packages on nuget such as SharpCrypt to see if they would help generate a hash value, however I see the error "the type or namespace name 'CryptSharp' could not be found" after adding the package from nuget.
I am targeting:
.Net Framework 4.5+
Windows Store apps
Silver light 5
Windows Phone 8
I'm quite a beginner so maybe I am missing something extremely obvious, any help or examples would be much appreciated.
Thanks!
I believe some of the crypto classes may also be available portably using the PCLContrib project - http://pclcontrib.codeplex.com - but I don't think this is yet available beyond Windows.
Where functionality isn't available portably, you can inject implementations into portable class libraries via an interface from each UI platform:
there's an example of this in the first part of N=31 in http://mvvmcross.blogspot.co.uk
there's a full introduction to MvvmCross dependency injection in https://github.com/MvvmCross/MvvmCross/wiki/Service-Location-and-Inversion-of-Control
I'm having trouble understanding why the Newtonsoft JSON parser has to be device specific under Xamarin. I cannot seem to find any way to have the parser exist in a common, shared library. I'm using the Tasky Pro sample app. I can get the JSON.Net DLLs from the Xamarin store to work in the Android and iOS projects, however that makes no architecural sense. E.g., the SQLite stuff is all in a shared lib, as you'd expect - as one set of c# source files.
Ideally I'd like to just add some kind of reference to "Tasky.Core" and be able to serialize/deserialize JSON.
Is there any way to get JSON.Net to work in a shared library (across droid/ios/wp8)? The source is pretty huge to try to manage as linked files, if that's even possible...
If not, is there some alternative way of managing JSON that will work in this way?
You should be able to use the JSon.NET NuGet Package for this. The implementation is actually platform-specific [1], but NuGet will transparently take care of that for you and pick the correct one for you.
Note that you need Mono 3.2.6 and Xamarin.iOS 7.0.6 for this, which just hit the alpha channel this week, I have just fixed some critical bugs in this area. You should also upgrade the NuGet Add-In in Xamarin Studio to the latest version (0.8), which contains several PCL-related bug fixes.
Simply add the NuGet Add-In to Xamarin Studio if you have not done so already, then search for "JSon.NET", the add-in will automatically install the package and add the required library references for you.
[1] The NuGet package contains different .dll's for different target frameworks and then picks and references the best one for your project - so your application will only contain a single implementation, but an iOS app may use a different one than a desktop application.
Update 01/14/14:
NuGet packages usually contain different implementations - unfortunately, not all of them will work with Xamarin.iOS due to APIs such as Reflection.Emit or Full DLR that are not available on iOS.
If you look into the packages/Newtonsoft.Json.5.0.8/lib/ directory, you'll see different sub-directories - each of these contain a different implementation and NuGet will use the one that best fits the current target framework. Unfortunately, NuGet does not always pick the right one :-(
For Newtonsoft.Json.5.0.8, the "portable-net45+wp80+win8" implementation uses DLR features that are not available on iOS, the "portable-net40+sl4+wp7+win8" one is ok. So if you add the NuGet package to a PCL that's targeting for instance Profile136, you'll get the correct implementation.
There is no GUI to choose another implementation, but you can edit the .csproj file. Replace
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.8\lib\portable-net45+wp80+win8\Newtonsoft.Json.dll</HintPath>
</Reference>
with
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.8\lib\portable-net40+sl4+wp7+win8\Newtonsoft.Json.dll</HintPath>
</Reference>
and it should work.
In general, when you're getting an error message about missing types after adding a new NuGet package, go to the corresponding package directory and grep -r for that symbol - chances are that there's a different implementation which does not use this type.
Hopefully, a more elegant solution will be available in the future, but that needs coordination with the NuGet team and package authors, so it'll take some time.
Just add it to Shared Library via NuGet. Actually, all your request/response tasks should be done in library. You should use JSON.Net to parse response.
I'm writing a plugin but I need a specific implementation for each Windows Phone version.
The problem is that the plugin system will try to load the platform plugin assembly based on a convention. In this case, "WindowsPhone".
We may try to override CreatePluginManager but then it will affect the rest of the plugins you may need.
I'm thinking of generating two different projects with different names but the same assembly and namespace. This, I think, would solve the problem of loading the specific plugin but I don't really know how to face an eventual publication to Nuget.
Best regards,
Roberto.
Generating assemblies with the same name is a viable way to go - it is something that the Microsoft Pcl teams do quite frequently - it is how the reference assemblies work.
The nuget distribution of these shouldn't be an issue - but would be a "faff" - as the nuget zip file would use different folders for the different files. There might, however, be some work to do at the .targets level if you want a single project to build both wp7 and wp8 configurations (this is similar to the effort needed for x86/x64/arm variants of assemblies in winrt nuget packages).
In fact, the main reason I can think for not using the same name is the very simple reason that it's far too easy to get in a muddle that way.
If for this one plugin, you wanted to override the plugin manager during setup, you could provide custom loading functionality based on
inheriting from https://github.com/slodge/MvvmCross/blob/v3/CrossCore/Cirrious.CrossCore/Plugins/MvxFilePluginManager.cs
and then overriding protected virtual string GetPluginAssemblyNameFrom(Type toLoad) to add a special based on some property of toLoad - eg if (toLoad.Name.EndsWith("Foo")) toReturn += PlatformPostfix
If this pattern becomes common - whether for wp or for the other versioned platforms - then we could include something back into the framework - it would be easy enough to try a version-neutral load followed by a version-specific load for every plugin.
There are also other ways you could go about this too...
E.g. Another possibility/opportunity is that your plugin core file could try loading multiple platform adaptions itself - eg using code like
public void EnsureLoaded()
{
var manager = Mvx.Resolve<IMvxPluginManager>();
manager.TryEnsurePlatformAdaptionLoaded<PluginLoader>();
manager.TryEnsurePlatformAdaptionLoaded<Sub1.PluginLoader>();
manager.TryEnsurePlatformAdaptionLoaded<Sub2.PluginLoader>();
}
This would try loading three child assemblies for that plugin - MyPlugin.WindowsPhone, MyPlugin.Sub1.WindowsPhone and MyPlugin.Sub2.WindowsPhone although you would only package one of these on each platform.