Swig code security problems encountered when compiling gdal C # libraries and how to solve them

Used to be someone else compiled Gdal library development, today compiled the Gdal 2.0.0, stepped on a lot of pits, but finally solved.

The method of compiling mainly refer to the http://blog.csdn.net/liminlu0314/article/details/6945452, the pit and the solution of the method reference http://www.cnblogs.com/yeahgis/ Archive/2013/04/10/3011553.html. But Yeahgis predecessors did not solve the problem that security transparent code could not invoke native C + + code, adding a security level statement to each class was too much trouble. By accessing the information, the security description in the%gdal_code%\swig\csharp\assemblyinfo.cs is changed to

// The AllowPartiallyTrustedCallersAttribute requires the assembly to is signed with a strong name key. // This attribute are necessary since the control is called by either an intranet or Internet // Web page that should is running under restricted permissions. // [assembly:securitycritical] // Use the . NET Framework 2.0 Transparency Rules (Level 1 transparency) as default #if (CLR4) [Assembly:securityrules (SECURITYRULESET.LEVEL2)] #endif

There is no code security level issue.

. NET code security is determined by both [assembly:securitycritical] and [Assembly:securityrules (Securityruleset.level2)], and the assembly scope annotations have none, SecurityTransparent, securitycritical, allowpartiallytrustedcallers four kinds of characteristics, Securityruleset Level1, Level2 two levels, The security level after the combination is described below

In this compilation I choose None, Level2, security level is enough.

Attached: Code Access Security Basics https://msdn.microsoft.com/zh-cn/library/dd233102.aspx

Swig code security problems encountered when compiling gdal C # libraries and how to solve them