I think that's reasonable, since it's the only way for people to benefit using those directly or indirectly.
> Since Castle.Core is not a candidate to become a PCL I've been somewhat away from .net so I'm not up to speed on why it's not a candidate. Is it the API surface it relies on not available on the portable API subset? On Wed, Jan 14, 2015 at 7:24 AM, <ja...@apx-labs.com> wrote: > I've been working lately on getting Moq to work on Xamarin.Android, which > means getting Castle.Core to work on Xamarin.Android as well. My goal is to > get my changes accepted upstream for both Castle and Moq, so I'd looking for > guidance and feedback on how to organize my changes to make them acceptable. > > TL;DR - Would it be acceptable to put Castle.Core's source files in a new > Shared Code project (.shproj), and then reference that project in both > Castle.Core and a new Castle.Core.Android project? > > So far, I have Castle and Moq both building for Xamarin.Android, and Moq > passes all but 2 of its unit tests now. To get to that point, however, I had > to hack up Castle.Core's solution and project files to the point that they > only build for Xamarin.Android. > > I would use $(Configuration) or $(Platform) Condition checks to make a > single .csproj work with both .NET and Xamarin.Android profiles, if that > were possible. Unfortunately, the Xamarin.Android .csproj must be separate, > or else Xamarin gets confused about what kind of project it is. > > Since Castle.Core is not a candidate to become a PCL, my usual approach to > fix this would be to create a Shared Project. It would contain all of the > source files currently in Castle.Core, and then Castle.Core.csproj and > Castle.Core.Android.csproj would reference that project. Adding a source > file to the Shared Project would then automatically be included in both > projects. A similar approach would be used for Castle.Core.Tests. This > approach is easy to understand and maintain. It's only downside is that it > requires at least Visual Studio 2013 Update 2 or Xamarin Studio 5.0 or > later. > > The alternative is ugly and unpleasant to maintain. In > Castle.Core.Android.csproj, make a <Link> to every source file from > Castle.Core that should be compiled in Castle.Core.Android as well. This is > painful because every time a file is added/removed from Castle.Core, the > link must also be added/removed in Castle.Core.Android. > > Is there an alternative that I've missed? > > Also, is there anything I need to account for in Settings.proj, > buildscripts/Build.proj, or buildscripts/Castle.Common.Targets? > > Thanks, > James > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to castle-project-devel+unsubscr...@googlegroups.com. > To post to this group, send email to castle-project-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/castle-project-devel. > For more options, visit https://groups.google.com/d/optout. -- Cheers, hammett http://www.d-collab.com/ http://www.hammettblog.com/ -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-devel+unsubscr...@googlegroups.com. To post to this group, send email to castle-project-devel@googlegroups.com. Visit this group at http://groups.google.com/group/castle-project-devel. For more options, visit https://groups.google.com/d/optout.
