To be honest I've got no idea what the error means. From the mono code it doesn't look like the row 0 means the module, but I'm not knowledgable about the internal structures of the mono runtime. https://github.com/mono/mono/blob/adb9681393a8dfec2ca9c2e8c5a4ed72d663878d/mono/metadata/metadata-verify.c#L2958
Do you think these verify errors could be related to the compilation errors I was getting with Mono on Linux that I couldn't work out. The "Missing method .ctor in assembly" ones: http://builds.castleproject.org/viewLog.html?buildId=10615&buildTypeId=Core_MasterMono310&tab=buildLog You could call having peverify there a sanity check, but IL code generation is finicky, so the unit tests might pass but be invalid IL, it is definitely a must at least on Windows. As I mentioned earlier I'd be happy to accept smaller pull requests that push us further to supporting mono, you could leave the peverify checks out on mono for now. On Wed, Mar 25, 2015 at 12:48 AM, <ja...@apx-labs.com> wrote: > Jono, > > I'm still working on this in my spare time. I've been trying to get as > many unit tests to pass as possible, including ones that were previously > altered or ignored on Mono. > > I've got BasePEVerifyTestCase.cs using Mono's peverify instead of .NET's > peverify.exe when the test detects that it's running on Mono. It turns out > that Mono's peverify is significantly more strict that .NET's peverify.exe > <http://mono.1490590.n4.nabble.com/peverify-vs-mono-verify-all-td4663844.html>. > The DLLs that Castle.Core generates when running under Mono pass with > .NET's peverify.exe, so I'm not worried that there's a problem with Castle > running on Mono. When I test with Mono's peverify, all of those tests fail > with the following error: > > Error: Invalid CustomAttribute content row 0 Value field 0x00000166 > Error: CustomAttribute: Invalid constructor > Error count: 2 > > The "field" hex value varies on some tests, but otherwise the error > message is the same. Since it's talking about row 0 (the module?), is this > error referring to CacheMappingsAttribute? > > Also, is peverify.exe there as a sanity check, or is it part of the unit > tests to catch something specific, like type safety? If it's there to test > something specific, I might be able to imagine another way to test for that. > > ~James > > On Monday, February 2, 2015 at 12:54:53 AM UTC-5, Jonathon Rossi wrote: >> >> NSubstitute and JustMockLite also still support .NET 3.5. >> >> On Mon, Feb 2, 2015 at 3:39 PM, Jonathon Rossi <jo...@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+unsubscri >>>>>>>>>> b...@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-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 >>> >> >> >> >> -- >> 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 -- 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.
