<br><div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}</style><br>
<div class="gmail_quote">2010/4/22 James Perrins <span dir="ltr"><<a href="mailto:JamesP@esdm.co.uk">JamesP@esdm.co.uk</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Tamas,<br>
<br>
Adding the following line into the AssemblyInfo.cs file for mapscript_csharp<br>
<br>
[assembly: SecurityRules(SecurityRuleSet.Level1)]<br>
<br>
Seems to avoid the transparency security error (though it does seem to have introduced something else in my app - but it works for a simple test app (just populating a mapObj with a .map file)<br>
<br></blockquote><div><br>James,<br>
<br>
I've fixed the security error issue in MapServer 5-4 / 5-6 and the
development version. I've also set up the build system on
<a href="http://vbkto.dyndns.org/sdk/">http://vbkto.dyndns.org/sdk/</a> to provide packages for Visual Studio
2010. Feel free to try this out.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
However - unfortunately after all this - it doesn't seem to make any difference to the original problems with the memory errors. I had hoped by compiling to CLR 4 these would go but they haven't. So I'm back to square one - it doesn't work with CLR 4.<br>
<br>
Any other ideas whey there might be memory issues ?<br>
<br></blockquote><div><br>This issue is not completely clear to me, however it doesn't seem to occur with the debug builds. For this reason I've altered the build process to include a csc /debug:full compiler option for the VS2010 builds.<br>
<br>This behavour may be due to a change in the garbage collector handling with CLR4, I suspect some objects may be garbage collected earlier than expected, but the debug builds may enlarge the lifespan of those objects at least within the scope of a particular function call. I will investigate this issue futher.<br>
<br><br>Best regards,<br><br>Tamas<br><br></div></div><br>