mapscript_csharp causes memory errors in VS 2010 (CLR 4)

[JamesP]

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 (​http://blogs.rev-net.com/ddewinter/2009/05/20/opting-out-of-security-changes-in-net-4/). Just adding this in the config file does not solve the problem of transparency.

Adding: [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("MyMapfile.map")

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.

[tamas]

The security exception issues is fixed in r10129, r10130 and 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.

[tamas]

The issue is now fixed in r10440, r10441 and r10442