So we need .NET 4 version of re-linq. So now atleast we have one more argument for .NET 4 version:)
2012/12/6 Oskar Berggren <[email protected]> > Some more info that might be relevant: > > > http://msdn.microsoft.com/en-us/library/system.runtime.serialization.isafeserializationdata.aspx > "In versions previous to.NET Framework 4.0, serialization of custom > user data in a security transparent code was accomplished using the > GetObjectData method. Starting with .NET Framework 4.0, that method is > marked with the SecurityCriticalAttribute attribute which prevents > execution in security-transparent code. To work around this condition, > implement the ISafeSerializationDatainterface and add custom data as > shown in the example below. " > > > Exploring the .NET Framework 4 Security Model > http://msdn.microsoft.com/en-us/magazine/ee677170.aspx > Long, but it has something to say about AllowPartiallyTrustedCallers etc. > > > /Oskar > > > > 2012/12/6 Alexander I. Zaytsev <[email protected]>: > > Is there only one problem with retargeting .NET 3.5 to .NET 4.0 that we > need > > to apply such security attributes? I think il-repack can easily be > adapted > > for such scenarios. > > > > > > 2012/12/6 cremor <[email protected]> > >> > >> I just tried il-repack. Results in the same exception from re-linq as > when > >> using the old ILMerge. > >> > >> Even if there would be an re-linq build for .NET 4.0, wouldn't then > cause > >> the Antlr3.Runtime the same problems? Or doesn't the Antlr3.Runtime > call any > >> security critical methods? > >> > >> > >> On Thursday, December 6, 2012 9:35:49 AM UTC+1, Oskar Berggren wrote: > >>> > >>> What is re-linq's take on .Net 4? Can we use a custom build adapted > >>> for .Net 4 and/or get them to release such a build? > >>> > >>> /Oskar > >>> > >>> > >>> 2012/12/6 cremor <[email protected]>: > >>> > I've now found the reason for NH-3340 - NHibernate assembly loses the > >>> > AllowPartiallyTrustedCallers attribute after ILMerge > >>> > (https://nhibernate.jira.com/browse/NH-3340). But since this is > going > >>> > to be > >>> > more a question/discussion than a comment for that bug I'll post it > >>> > here. > >>> > > >>> > So the reason why this attribute is there in NHibernate 3.3.x but is > >>> > missing > >>> > in 4.0.0 is that the 3.3.x branch still uses some older ILMerge > version > >>> > (2.10.526) whereas the master branch uses the latest version > >>> > (2.12.803). > >>> > Using the old ILMerge for building the master branch solves the > problem > >>> > of > >>> > the missing AllowPartiallyTrustedCallers attribute (but causes other > >>> > problems, more on that later). > >>> > > >>> > Using the .NET Reflector I found the following code in the latest > >>> > ILMerge: > >>> > > >>> > else if (((node6.Type == SystemTypes.SecurityCriticalAttribute) || > >>> > (node6.Type == SystemTypes.SecurityTransparentAttribute)) || > >>> > ((node6.Type == > >>> > SystemTypes.AllowPartiallyTrustedCallersAttribute) || > >>> > node6.Type.FullName.Equals("System.Security.SecurityRules"))) > >>> > { > >>> > this.WriteToLog("Assembly level attribute '{0}' from > >>> > assembly '{1}' being deleted from target assembly", new object[] { > >>> > node6.Type.FullName, a.Name }); > >>> > a.Attributes[num8] = null; > >>> > } > >>> > > >>> > So it seems like all those security attributes are always removed. > >>> > Interestingly the change log of ILMerge > >>> > > >>> > ( > http://research.microsoft.com/en-us/people/mbarnett/changehistory.aspx) > >>> > doesn't mention this change. But most likely it was because of the > >>> > problem > >>> > I'm now getting: > >>> > > >>> > After merging the NHibernate 4.0.0 assembly with the old ILMerge I'm > >>> > getting > >>> > the following exception when executing a Linq query: > >>> > Inheritance security rules violated while overriding member: > >>> > > >>> > > 'Remotion.Linq.Utilities.ArgumentTypeException.GetObjectData(System.Runtime.Serialization.SerializationInfo, > >>> > System.Runtime.Serialization.StreamingContext)'. Security > accessibility > >>> > of > >>> > the overriding method must match the security accessibility of the > >>> > method > >>> > being overriden. > >>> > > >>> > So re-linq is not setting the correct security attributes for .NET > 4.0 > >>> > which > >>> > is understandable since it still targets 3.5. How should this ever > work > >>> > without requiring all dependencies to target .NET 4.0 and fixing > their > >>> > security attributes? > >>> > > >>> > I'm no .NET security expert but I think the best solution would be to > >>> > rollback to the old ILMerge version and additionally set the > [assembly: > >>> > SecurityRules(SecurityRuleSet.Level1)] attribute for the NHibernate > >>> > assembly. That way everything should behave like previously. > Completely > >>> > removing ILMerge and falling back to seperate assemlies should also > be > >>> > an > >>> > option, but I don't think that is a good solution. Opinions? > >>> > > >>> > PS: Here is a very good explanation of what > >>> > AllowPartiallyTrustedCallers > >>> > means in the .NET 4.0 security world: > >>> > http://msdn.microsoft.com/en-us/magazine/ee336023.aspx > > > > >
