mapscript_csharp causes memory errors in VS 2010 (CLR 4) #3438

mapserver-bot opened this Issue Apr 3, 2012 · 2 comments


None yet

2 participants


Reporter: JamesP
Date: 2010/04/23 - 00:57
Trac URL:
The existing version of mapscript_csharp (compiled in VS 2008 CLR 2/3.5) appears at first to work in VS2010 app. However inspection of the mapObj having simply loaded a .MAP file shows numerous properties with memory corruption.

All dlls are from a single compilation and switching the .net framework compilation target back to 3.5 in VS2010 works thus proving that the supporting dlls are themselves OK

Compiling the Mapscript_csharp library using CLR 4 produces a dll, but atempting to access it causes an error:

''"Attempt by security transparent method 'OSGeo.MapServer.mapObj..ctor(System.String)' to call native code through method OSGeo.MapServer.mapscriptPINVOKE.new_mapObj(System.String)
failed. Methods must be security critical or security safe-critical
to call native code."''

there are issues due to changes in the security model in .NET 4 ( Just adding this in the config file does not solve the problem of transparency.

[assembly: SecurityRules(SecurityRuleSet.Level1)]

into the AssemblyInfo.cs for mapscript_csharp and then recompiling produces a dll compiled with CLR 4 that can be called without security error.

However this dll still has the memory corruption originally encountered (maybe due to .NET 4 using a different cvrt ??)

The memory corruption can be demonstrated simply by:
msMap = New mapObj("")

P.S. You can be fooled into thinking everything is OK in CLR 4 if you are running with default VS 2010 debug settings. Errors only appear when running an .exe directly or if in the designer you change Its only when you try and run the compiled exe or switch off the debug setting "suppress jit optimization on module load
(managed code only)" that you see the error.


Author: tamas
Date: 2010/05/02 - 14:37
The security exception issues is fixed in dba2101 (r10129), 599089e (r10130) and 017a923 (r10131)

I've set up a debug build by default for the C# interface to prevent from the access violations. However I need to investigate this issue a bit further, which might be related to some change in the garbage collection handling.


Author: tamas
Date: 2010/08/05 - 13:50
The issue is now fixed in 53f0959 (r10440), 0575a8e (r10441) and bcdd86e (r10442)

@szekerest szekerest was assigned Apr 5, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment