Code Sharing Projects... plans to support?

I am struggling to find ways to satisfactorily deal with what I feel should be a very simple problem… sharing code and assets between projects.

e.g. I wish to have a “free” and a “pro” version of an app. The free version incorporates advertising, the pro version does not. Almost all of the code in the two apps will be identical, but there will some differences required in order to both distinguish the two apps as separate and distinct for the purposes of the respective app stores, as well as incorporating such differences as required to enable advertising in the free version.

As well as common code, I also have common assets - both the free and pro versions of the android app (for example) use the same set of drawables for the icons and the same set of values files, used for various aspects of the app.

Sharing code is awkward and (imho) messy but is somewhat achievable, however far from ideal the mechanisms might be. But sharing assets appears nigh on impossible.

Matters get even more messy when you add in versions of the app for additional platforms, sharing code but NOT the assets, with those other platform versions.

The problem, as far as I can tell, is that there is no reliable, straightforward way to set up projects to achieve this. Trying to share assets between projects doesn’t appear to work, nor does it seem possible to create a “master” project, excluded from any build, from which files are then consistently “added as link” to my actual build target apps.

The technique used in the Sugar solution could work for code, but doesn’t work for assets due to the way that the project types impose expectations on folder structures beneath the project file location, in a way that makes co-locating projects in order share code in that same location impossible as soon as assets are added to the mix. As far as I can tell, the approach taken with the Sugar solution works only because it does not involve application-type projects with assets to worry about.

The problem stems from the Project System implementation in Visual Studio which requires that a Project System implement such expectations and behaviours and then removes any form of control or flexibility from a developer who needs to vary these rules (if the Project System does not incorporate the ability to achieve the required variation). The platform project types for Oxygene etc simply don’t appear to accommodate sharing their assets with (or from) other projects and thanks to the way that the Visual Studio Project system works, this means I am stuck.

I have even looked at what might be involved in implementing my own “Project System” to achieve what I need but frankly it looks like far more work than I wish to spend time on (at the expense of my other projects) and not the sort of thing I am going to enjoy doing. The entire Project System framework in Visual Studio may indeed be very powerful, but it is also the sort of over-engineered framework that I find frustrating and exasperating to have to deal with. This is made worse by the fact that it doesn’t appear to have ever progressed far beyond it’s COM origins. The MPF for Projects framework is not actually much more straightforward to deal with, riddled with bugs, and filled with it’s own assumptions and expectations of what sort of Project System someone will want to develop.

For example, creating a new project type which does not contain a “References” node (which a platform agnostic “Shared Code” project would not, for example) causes problems for the MPF framework.

The whole VS system seems geared towards creating highly complex and automated project systems, and MPF toward creating a specific sub-set of the capabilities, but both seem singularly ill equipped (or perhaps over equipped) to provide the sort of simple, hands-off simple code -organisation capabilities that I am looking for.

This is perhaps not surprising given that the creators of Visual Studio presumably envisaged that everyone would simply be using .NET or at least Windows, so any shared code would just be lumped in to a library (DLL or assembly).

Microsoft have addressed this identical need with respect to “Universal Apps” with a specific Share Code Project type (as ov VS 2013 Up 2), but thanks to the Highly-Capable-Yet-Simultaneously-God-Awful Project System, even this only allows specific file types to be shared between certain other project types. i.e. RemObjects code/assets etc cannot make use of the sharing capabilities this provides.

Xamarin neatly side-steps the entire issue thanks to the fact that it is Mono based and specifically abstracts the different platforms in a way that makes sharing code and assets more straightforward - you just use a Portable Class Library, for which no equivalent exists in the RemObjects world (and cannot, since each platform is platform native, not running on a common Mono platform) . And beyond that, Xamarin does seem able to additionally take advantage of the Shared Code project type that MS have introduced.

Which is a very long-winded way of bringing me to my question:

  • Are there any plans to provide a similar “Shared Code” project system for RemObjects languages ?

Having spent some time already grappling with the implementation of a Project System that might solve this problem, I anticipate that there would in fact need to be a suite of “Shared Asset Type” projects:

  • Shared Code (possibly separate project types for Oxygene, C# and Swift code)
  • Shared Android Assets
  • Shared iOS Assets
  • Shared Windows Store Assets

Alternatively, there must be some expertise within RemObjects in the area of implementing a Project System, and if someone would be willing to give me a jump-start and provide some guidance on implementing such a thing, I might be prepared to consider taking on the task myself as an open-source exercise.

Failing any of that, how do other people tackle this problem ?

Short answer: yes, we are looking at Shared projects right now. :wink:

see Share code between projects