I'm learning Xamarin. We have two ways to share our codes across platform, i.e. Shared Project and Portable Class Libraries.
I want to know what is happening, in detail, when I click on the "Play" button in Xamarin Studio. In particular, I'm interested in the build process for Xamarin. I have another related question: Is there a way to modified the build process?
I can not tell you what happens exactly within the build process but I can tell you that both types of sharing code have there advantages as well as down sides. And I personally prefer SharedProjects over Portable Class Libraries (PCLs).
The reason for this is that PCLs provide the minimal common denominator of the platform that your PCL profile support. Which can be sometimes annoying. A PCL is simplified nothing else as an assembly you reference in you project.
A SharedProject on the other side will be compiled into your project to a monolith. You can use compiler switches and such. Simplified it is a better way of linking files between different projects.
Xamarin has a good guide about Code sharing options you should read through.
Related
So, I've been searching around about the ideal way to build a cross-platform .NET (C#) application that also relies on some native code bits.
Since I couldn't find a de-facto way to build these things together, I turned by attention into the following workflow:
Build native code (c++ -> native "dll"(.dll/.dylib/.so/etc);
(Generate bindings, w/ SWIG or something, or have a project with them);
Package said project into NuGet;
Consume from the cross-platform application.
Now, Microsoft itself has some suggestions about this. But this - and all other - guides I've found so far have the same quirk: include pre-compiled binaries into the folder structure. This bothers me because:
It makes version control hard, because you have hard-copied build artifacts;
It completely breaks CI/CD because you can't just have a matrix of CI machines each one doing their build/package/upload.
It breaks the development workflow because you need to constantly be building + copying files over.
But, looking around in the NuGet Gallery, there seem to be packages more in the direction that I thought of, for example in the SkiaSharp, and Avalonia packages.
My idea is that there should be a series of for-one-platform-only packages (plus eventually an "aggregator" package) that could be transparently consumed.
Is this a possible workflow? If yes, how? If not, what is the currently agreed upon workflow, and how does it tackle the issues I mentioned?
Just to make it clear, I want to develop the native library and consume it in the cross-platform .NET (5/6) application in a simultaneous fashion, it's not that I'm binding a mature library, with periodic releases, that would make the mentioned workflow easy.
Thank you.
I know there is someone who has post some questions like this. But my problem is a little different.
My program has two versions, one is for PC and the other one is for Windows Phone. In my case, they both use a same algorithm. I want to share the codes between two projects.
First, I tried to create a project containing these codes, then add them to my projects as a reference. But here is the problem, if i create a Windows Form Application project, I can't reference it in a WP project, and vice versa.
Second, I tried to add these codes to my projects as a link. But I have lots of files to share, I don't want add them one by one. And these shared files will mass my project directory.
What should I do?
You need to create a "Portable class Library" project and put your common code in there. it will create a dll. Reference it in other projects and it will work fine.
Using the Portable Class Library project, you can build portable
assemblies that work without modification on the .NET Framework,
Silverlight, Windows Phone 7, or Xbox 360 platforms. Without the
Portable Class Library project, you must target a single platform and
then manually rework the class library for other platforms. The
Portable Class Library project supports a subset of assemblies from
these platforms, and provides a Visual Studio template that makes it
possible to build assemblies that run without modification on these
platforms. - MSDN
sounds to me like you need to make a Class Library project. Create that and you can put in whatever code you want, then compile it to a dll, and reference it in any of your other projects.
I have once made a game in xna, and have converted it to android using monogame using this. Now I need to use some classes from the new project in the old project and am using this tutorial to reference the old project in the new project. But soon as I have finished doing this I get a warning saying "The Project "****" cannot be referenced. The referenced project is targeted to a different framework family(.NETFramework)"
I know what is causing this, but I am wondering if there is a way around it or if I can use the classes from different projects in another way?
Xamarin has some documentation about the possible ways to share code between projects.
It's worth reading but essentially boils down to 2 options:
Portable class libraries
File linking into each project
There's a discussion on the Xamarin forums about current issues with Portable Class libraries.
There's also another discussion here about a project file hack to recursively share folders in Visual Studio. Unfortunately, it's not yet possible to do this in Xamarin Studio.
I would love to know if you discover a better way to do this. I've been interested in this issue for a while.
I ended up Just putting all information and data from my XNA Project into my monogame project because monogame supports XNA and Android. This helped.
System.Configuration is not supported on Monotouch; that actually means you cannot use app.config file types in your project. However, if you have an existing application that is using this .NET feature big time, what to do?
Any suggestions how to deal with it? Ideal situation is that app.config can be kept as it is and that Monotouch can read the settings as defined. In the end, that would mean a kind of implementation of System.Configuration.
Suggestions? Code? Would be more than welcome!
MonoTouch's main difference from the standard .NET is to drop support for System.Configuration, in the same way that Silverlight did.
The reason is that this is a pretty heavy framework and it is not an opt-in feature. If we were to support app.config, we would have to bring System.Configuration even for applications that did not care about, bloating the result.
The solution is to remove the dependency on app.config from your software, in the same way that you would if you used WinRT, .NET on Xbox or Silverlight.
First of all you should realize that MonoTouch is not meant to make apps portable, just to enable developers to use C# for iOS apps.
The obvious thing you can do is to wrap this part into your own configuration management code and reimplement the missing part on the iOS side.
BTW the guys at Xamarin are working to create cross-platform APIs for iOS, WP and Android but I doubt these include configuration. They are meant to support device APIs like camera, compass, etc. and I am not really sure how far they have progressed.
We ported the OpenNETCF.Configuration code from the SDF (and by "ported" I mean simply created a MonoDroid and MonoTouch project file and imported the code files) and it works fine. Of course it's a subset of the full Configuration namespace, but it provided pretty much everything we were using from the app.config files.
The code comes with the Standard and above editions, though if you're cheap I'm fairly sure the code changed very little from the 1.x code base which is free and at the bottom of the above linked page.
I have coded a dll library using the basic utilities of C#. But for platform independence, I want to port it to silverlight. Is it possible? If possible, then how to do it?
Or do you guys have any other suggestion?
If you build your DLL for Silverlight4, it can be referenced from a .NET-project; but not the other way round. See Sharing Silverlight Assemblies with .NET Apps.
Another method of sharing source code between SL and .Net is to use Linked files.
In your .net solution, add a silverlight library project.
Add>Existing Item>browse to the source files in the .net project, select them, click the little down-arrow on the 'add' button and select 'add as link'.
In a lot of cases, no modifications are necessary. In the instance that there is a minor discrepancy, use build flags and conditionals in source. e.g.
#if SILVERLIGHT
#else
#endif
This has worked out well for me, especially when I want to share a DTO library.
My suggestion is to create different project files (for .NET and SL). Then add the common files into each.
Many classes and methods are available on both .NET and SL, so it is possible to make the two projects share the same code.
This does not apply to all scenarios. For example, my open source project #SNMP uses UDP related classes, but SL does not have any UDP related things.
My personal choice is to limit the size of SL application and move necessary pieces into a backend WCF application.
What you need is a Portable Class Library: http://msdn.microsoft.com/en-us/library/gg597391.aspx
This way can share a project/DLL between .Net, Silverlight and Windows Phone projects.