NSubstitute and JustMockLite also still support .NET 3.5. On Mon, Feb 2, 2015 at 3:39 PM, Jonathon Rossi <j...@jonorossi.com> wrote:
> I'm happy for you to drop Silverlight 4.0 support if you can't get it > working, agreed that there is no need to support it anymore because of the > very low usage. However .NET 3.5 is another story, Castle Core has quite a > lot of users and with Microsoft still supporting .NET 3.5.1 on many > operating systems (including Win8.1) my vote is strongly to keep support > for it. I don't think I'd accept a PR that dropped .NET 3.5 support. > > Just a quick look at Moq, FakeItEasy and RhinoMocks, and FakeItEasy at > least clearly wants to continue supporting .NET 3.5.1: > https://github.com/FakeItEasy/FakeItEasy/issues/217 > > When you said that Visual Studio 2013.4 is having problems with Shared > Projects, did you mean just for those two platforms you wanted to remove > support for? i.e. it works for .NET4+. > > On Sat, Jan 31, 2015 at 7:56 AM, <ja...@apx-labs.com> wrote: > >> How important is it to preserve support for Silverlight 4.0 or older >> versions of .NET? >> >> I'm naturally trying to make sure that I don't break the Desktop or >> Silverlight builds of Castle as a result of introducing Shared Projects to >> the solution. Therefore, I'm testing my changes in my Windows 7 VM with >> Visual Studio 2013 Update 4. I'm running into particular trouble keeping >> the Silverlight 4.0 and .NET 3.5 configurations working, because VS 2013 >> does not like all of the Conditional <Import> tags and DLL references. >> >> Silverlight itself is deprecated, and Silverlight 5.0 has been out for >> over 3 years. 5.0 runs on all versions of Windows going back to Windows XP, >> so there's no need for an app to target Silverlight 4.0. Similarly, .NET >> 4.0 is almost 5 years old at this point. 4.0 also runs on all versions of >> Windows going back to Windows XP, so there's no need for an app to target >> earlier versions of the framework. When does Castle stop maintaining >> support for platforms that are beyond EOL? >> >> On Sunday, January 18, 2015 at 9:46:46 PM UTC-5, Jonathon Rossi wrote: >>> >>> I didn't get that error with NLog in Xamarin Studio or xbuild on OSX >>> building for a normal net 4.5 profile. >>> >>> If you want to send a pull request through changing the NUnit assertions >>> to the newer API and/or fixing the Windows assumptions in the unit tests I >>> can merge them before other changes to we don't end up with a massive pull >>> request. >>> >>> I'm happy for the PEVerify assertions to not be executed, we haven't >>> been running them at all until now, so one step at a time is the best way. >>> >>> On Sat, Jan 17, 2015 at 7:23 AM, <ja...@apx-labs.com> wrote: >>> >>>> Jono, >>>> >>>> I just read through the issue you linked to. I'll look at adding NLog >>>> to the Android build so that I can see whether that error occurs on Xamarin >>>> as well. >>>> I think it is possible to create the .shproj files without moving any >>>> .cs files, as requested. >>>> >>>> About the test cases: >>>> >>>> 1. Xamarin.Android uses NUnitLite, which does not have support for some >>>> of the old "classic" assertions of NUnit. This means that some unit tests >>>> now use the modern "constraint" assertion API. For example, wherever a unit >>>> test says Assert.IsInstanceOf<T>(obj), I've changed it to read >>>> Assert.That(obj, Is.InstanceOf<T>()). >>>> 2. Mono does have a version of the PEVerify tool, but its syntax is >>>> different and I haven't proven that it tests the same things as Visual >>>> Studio's tool. If I figure it out, I'll use a runtime check in the >>>> BasePEVerifyTestCase.cs to make the correct call. >>>> 3. Of the 1330 unit tests currently enabled in my Android build, 96 are >>>> failing. Many of those Xml test failures, which were #ifdef'd out in the >>>> SILVERLIGHT and MONO configurations before. Many other failures are >>>> frequently related to the unit tests assuming that they are running on a >>>> Windows machine with write access to the current working directory, and I >>>> can hopefully fix those. >>>> >>>> ~James >>>> >>>> On Thursday, January 15, 2015 at 11:13:13 PM UTC-5, Jonathon Rossi >>>> wrote: >>>>> >>>>> Hey James, >>>>> >>>>> That Silverlight solution and project file are quite old, but IIRC you >>>>> need a Silverlight project type to be able to run the project under the >>>>> debugger as an XBAP. We might be able to remove them, ignore them unless >>>>> they get in the way trying to add Android support. >>>>> >>>>> I've documented my efforts with getting things going with Mono over >>>>> the last month, I really haven't spent much time on it, I've been meaning >>>>> to get back to it to see if I can sort the blocking problem out. I know >>>>> people are using Castle Core on Mono, but getting support in our build >>>>> scripts is what I'm trying to do there. If we could sort out that blocking >>>>> problem I agree a bunch of stuff could be removed from those build files. >>>>> I'd appreciate if you could take a read though this issue I just logged. >>>>> https://github.com/castleproject/Core/issues/79 >>>>> >>>>> Just so it is on the table, we aren't pretending Mono should be a >>>>> different DLL, the last time we actually officially supported Mono was the >>>>> Mono 2.6 days. Since then Mono has definitely got heaps better but there >>>>> has been no work on the Castle side to clean up any of that. As mentioned >>>>> in #79, currently the MONO310 configuration doesn't define MONO, I renamed >>>>> it to try to get things going like NET45. >>>>> >>>>> I'm not the author of the MSBuild targets and proj files we've got for >>>>> our set up, but they were a lot easier to maintain than the NAnt set up we >>>>> had before it when there weren't so many platforms, however with more >>>>> platforms being added and none removed things have become a little messy >>>>> on >>>>> that front. >>>>> >>>>> Okay back to the actual issue at hand, Android. I've thought about it >>>>> a bit more and I'm happy to accept a PR to add a Shared Code project (well >>>>> two of them) as long as all the .cs files don't move, whether the current >>>>> .csproj needs to move to another directory, or the current .csproj and the >>>>> .shproj go in the same source directory I'm not too torn, same directory >>>>> will probably make the least change. >>>>> >>>>> Jono >>>>> >>>>> On Fri, Jan 16, 2015 at 2:59 AM, <ja...@apx-labs.com> wrote: >>>>> >>>>>> I am suggesting separate Castle.Core-Android.csproj and >>>>>> Castle.Core.Tests-Android.csproj files, but NOT a separate >>>>>> Castle.Core-Android.sln. (Why is there a Castle.Core-SL.sln file anyway? >>>>>> Silverlight is built in Castle.Core.sln as well...) I am just trying to >>>>>> avoid manually updating the Android project files every time a file is >>>>>> added or removed from the regular project files. I know from past >>>>>> experience that Xamarin Studio chokes on <Link> entries with wildcards, >>>>>> so >>>>>> that won't work. It's perfectly happy with wildcards in <Compile> >>>>>> entries, >>>>>> but that won't help us here. >>>>>> >>>>>> I understand the reluctance to further complicate the project files. >>>>>> A Shared Project in addition to all of the conditional checks, >>>>>> Settings.proj, and buildscripts/Castle.Common.Targets files would be >>>>>> messy. What if some of those conditionals and additional build files were >>>>>> unnecessary? Would that make room for a Shared project? >>>>>> >>>>>> For example, the MONO310 configurations can be removed altogether. >>>>>> Desktop Mono (as opposed to Xamarin) is compatible with .NET, and there's >>>>>> nothing stopping Mono's runtime from using the assemblies built with the >>>>>> NET45 configuration, so why pretend that it needs a different DLL? Issues >>>>>> w/ Mono's *compiler* (as in DynamicProxy/ProxyGenerator.cs) can be >>>>>> handled using the built-in preprocessor define __MonoCS__ >>>>>> <https://stackoverflow.com/questions/329043/how-can-i-conditionally-compile-my-c-sharp-for-mono-vs-microsoft-net/329072#329072> >>>>>> instead >>>>>> of needing to define MONO in the .csproj. As for all of the conditional >>>>>> compilation checks for MONO with the comment "Until support for other >>>>>> platforms is verified", isn't that what Unit Tests are for? And wouldn't >>>>>> a >>>>>> failure there be a bug with Mono, not a bug with Castle? >>>>>> >>>>>> ~James >>>>>> >>>>>> Reading through those additional project files, it makes me wonder >>>>>> whether they are all really necessary. >>>>>> >>>>>> On Wednesday, January 14, 2015 at 11:12:46 PM UTC-5, Jonathon Rossi >>>>>> wrote: >>>>>>> >>>>>>> Personally I'd prefer we didn't introduce Shared Code projects into >>>>>>> Castle Core, our current MSBuild project files and the .targets file and >>>>>>> others running in there makes it complicated enough, and Shared Code >>>>>>> projects just introduce more projects. I've also found that XS doesn't >>>>>>> like >>>>>>> all the conditional MSBuild checks we've got in there currently, so >>>>>>> this is >>>>>>> likely to make things worse. >>>>>>> >>>>>>> I've seen quite a few ways that you can do wildcards for files in >>>>>>> MSBuild where VS won't revert it back to a full file list. James, do you >>>>>>> think having a separate Castle.Core-Android.csproj and >>>>>>> Castle.Core.Tests-Android.csproj (a bit like our >>>>>>> Castle.Core.Tests-SL.csproj) would do the trick? If we went this way it >>>>>>> would mean not changes to the existing projects, and the Xamarin project >>>>>>> can stand on its own. >>>>>>> >>>>>>> Hammett, yes it's the PCL subset (you pick the combination of >>>>>>> platforms). PCLs can't have any conditional compilation, as they are >>>>>>> meant >>>>>>> to be "platform independent" to the extent you make them portable. >>>>>>> >>>>>>> On Thu, Jan 15, 2015 at 6:42 AM, hammett <ham...@gmail.com> wrote: >>>>>>> >>>>>>>> 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-pro...@ >>>>>>>> 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-pro...@googlegroups.com >>>>>>>> . >>>>>>>> Visit this group at http://groups.google.com/group >>>>>>>> /castle-project-devel. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jono >>>>>>> >>>>>> -- >>>>>> 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-pro...@googlegroups.com. >>>>>> Visit this group at http://groups.google.com/group >>>>>> /castle-project-devel. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jono >>>>> >>>> -- >>>> 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-pro...@googlegroups.com. >>>> Visit this group at http://groups.google.com/group/castle-project-devel >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Jono >>> >> -- >> 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. >> > > > > -- > Jono > -- Jono -- 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.
