Of course having a .NET 4.0 version of re-linq (and Antlr if needed) would be the best solution. But since it could be a long time until those are available, shouldn't there be a solution (or lets better call it workaround) until then?
I think the options are: 1) Downgrade ILMerge and set the SecurityRules(SecurityRuleSet.Level1) attribute. 2) Switch to il-repack and set the SecurityRules(SecurityRuleSet.Level1) attribute. 3) Don't use any assembly merger. Are there other options that I missed? On Thursday, December 6, 2012 11:09:34 AM UTC+1, Alexander I. Zaytsev wrote: > > 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] <javascript:>> > >> 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] <javascript:>>: >> > 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] <javascript:>> >> >> >> >> 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 >> > >> > >> > >
