bandit's picture

.Net 4.0 compatibility

Project:The Open Toolkit library
Category:support request

I'm using VS2010 RC und win7 x64 and newest SVN version of OpenTK. I also have the bug which was already discussed befor. OpenTK.Examples and OpenTK.Compatibility which decline to reference to OpenTK.dll.

MethodAccesException breaks on this line in API.cs
Debug.Print("Initializing threaded X11: {0}.", Functions.XInitThreads().ToString());

It really depends on settings of target framework, cause the following line throws DisplayDevice exception:

        public TestClass()
            : base(640, 480, GraphicsMode.Default, "Test") //this will help us track down bugs
        { }

I already tried different ways of assigning privileges to the project, changing target framework and x86/x64 target architecture. Does anyone already stumbled upon this issues and found a solution?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture


TypeInitializationException is the expected result here, but the exception should be caught and swallowed behind the scenes. OpenTK is trying to initialize the X11 subsystem, which is expected to fail on Windows.

MethodAccessException does not look right, though. Which .Net version are you compiling OpenTK for?

bandit's picture


I tried for .net 4.0 and 3.5 but both gave me equal result of this exception.

I turned exception rerouting off, which i activated for another project and now i can run my test application. But this error now comes up when I'm trying to load my class derived from GameWindow (i know there are German descriptions, but I'm pointing to safe-critical thing in the message):

+ base {System.TypeInitializationException: Der Typeninitialisierer für "OpenTK.DisplayDevice" hat eine Ausnahme verursacht. ---> System.TypeInitializationException: Der Typeninitialisierer für "OpenTK.Platform.Windows.WinDisplayDeviceDriver" hat eine Ausnahme verursacht. ---> System.MethodAccessException: Attempt by security transparent method 'OpenTK.Platform.Windows.WinDisplayDeviceDriver..cctor()' to call native code through method 'OpenTK.Platform.Windows.Functions.EnumDisplayDevices(System.String, Int32, OpenTK.Platform.Windows.WindowsDisplayDevice, Int32)' failed. Methods must be security critical or security safe-critical to call native code.
bei OpenTK.Platform.Windows.WinDisplayDeviceDriver..cctor() in C:\SVN\OpenTK\Source\OpenTK\Platform\Windows\WinDisplayDevice.cs:Zeile 46.
--- Ende der internen Ausnahmestapelüberwachung ---
bei OpenTK.Platform.Windows.WinDisplayDeviceDriver..ctor()
bei OpenTK.Platform.Windows.WinFactory.CreateDisplayDeviceDriver() in C:\SVN\OpenTK\Source\OpenTK\Platform\Windows\WinFactory.cs:Zeile 48.
bei OpenTK.DisplayDevice..cctor() in C:\SVN\OpenTK\Source\OpenTK\DisplayDevice.cs:Zeile 52.
--- Ende der internen Ausnahmestapelüberwachung ---} System.SystemException {System.TypeInitializationException}

The line which debugger shows up after the exception is from GraphicsMode.cs (line 310):

Debug.Print("Creating default GraphicsMode ({0}, {1}, {2}, {3}, {4}, {5}, {6}).", DisplayDevice.Default.BitsPerPixel, 16, 0, 0, 0, 2, false);

the Fiddler's picture


A quick search indicates that .Net 4.0 has a stricter security model:


For example, if a transparent method tried to call native code in v2, the CLR would issue a full demand for SecurityPermission/UnmanagedCode. This demand would succeed if the whole stack was fully trusted, indicating that even though the code doing the native invoke may not have been subjected to a security audit, it was OK to proceed since the current context doesn't involve partial trust.
The next step toward using security transparency as a full enforcement mechanism is to treat all transparency errors as hard violations, regardless of the trust context they occur in. Rather than transparency violations being converted to full demands in the v4 transparency model, they are treated as strict violations - and will unconditionally result in an exception when they are encountered. This also matches the way that Silverlight enforces its transparency model.

The exact exception that will be triggered, and the time that it is triggered, depends upon the transparency violation being encountered. For example, a transparent method trying to call a critical method will result in a MethodAccessException the first time that the JIT sees the call. However, a transparent method overriding a critical method will instead result in a TypeLoadException when the violating type is first loaded.

It is not immediately obvious how this should be handled in OpenTK. Any ideas?

bandit's picture


Maybe this solution will help to solve the problem: CA2140: Transparent code must not reference security critical items

the Fiddler's picture


Status:open» need info

Thanks for the link. I'm not sure I understand the new security model completely yet and I don't have .Net 4.0 to test, so it would really help if you could test a couple of ideas:

  1. OpenTK is marked with the [AllowPartiallyTrustedCallers] attribute, which should (in theory) work around this issue. However, this attribute only affects strongly-signed assemblies and OpenTK isn't strongly signed when checked out from SVN. How to fix: enable assembly signing under the project options for OpenTK in visual studio and rebuild the library.
  2. If the above didn't help, try marking the GL class as [SecuritySafeCritical] (add the attribute to Source/OpenTK/Graphics/OpenGL/GLHelper.cs). Does it work now?

Out of curiosity, does Examples.exe also suffer from this issue?

bandit's picture


I tested it. Both methods are failing. And i can't compile OpenTK.Examples and OpenTK.Compatibility because of BadImageFormatException. I think MS changed a lot of things in .Net 4.0 relying on privileges and security.

the Fiddler's picture


Status:need info» open

Thanks for testing.


And i can't compile OpenTK.Examples and OpenTK.Compatibility because of BadImageFormatException.

I think this has something to do with the fact that VS2010 compiles for x86 instead of AnyCPU by default, now.

I would recommend trying opentk-1.0-beta-3 if you have done so already, but other than that I'm afraid I won't be able to find a fix before VS2010 is officially released. If anyone has an idea feel free to make a post!

bandit's picture


This thing bothers me. I thought i could start to develop an application with OpenGL 3.2 after i finished other software projects. But no go. I see its Visual Studio 2010 bug, i think so after i tried to compile for .net 2.0 an 3.5. The result is always OpenTK.Examples refuses to use OpenTK as it was build with another framework version, but all projects are set to 2.0, 3.5 or 4.0 and have equal compile settings.

So i will try a couple things and post my results if it succeeds.

bandit's picture


I found a problem in VS2010. When i compile OpenTK the references are for .Net 2.0 no matter what framework is selected. It causes the BadImageFormatException in OpenTK.Examples. When i try to add reference for .Net 4.0, it's shown as 4.0 in Add Reference dialog. It adds the assembly but the properties show version 2.0.50727. Very strange thing, cause i already reinstalled VS2010 RC. Could bei interfere between GAC and Framework versions.

I posted this feedback about a bug to VS developers

c2woody's picture


OpenTK-Examples under vs2010 rc1, targetting the .net framework 4.0:
there seems to be a problem when converting the project files, maybe even a strangeness in the layout of the Build.exe-generated files (did not investigate the real cause or a correct fix yet). You can work around this by opening all .csproject files and changing ToolsVersion="2.0" to ToolsVersion="4.0" in the header project line.

The sample browser does not display any samples though, there's a hidden exception when enumerating the sample files (LoadSamplesFromAssembly). assembly.GetTypes() generates System.Reflection.ReflectionTypeLoadException, object data contains: Inheritance security rules violated while overriding member: 'OpenTK.Half.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.":"OpenTK.Half.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)" (which does not make too much sense to me...). Assembly signing does not seem to make a difference.