This project is read-only.

Refresh GPS devices

Jan 25, 2011 at 8:32 PM
Edited Jan 25, 2011 at 8:49 PM

When I try to refresh the list of GPS devices, I get the following MethodAccessException:

Attempt by security transparent method 'DotSpatial.Positioning.BluetoothDevice.Refresh()' to call native code through method 'DotSpatial.Positioning.NativeMethods2.BluetoothGetDeviceInfo(IntPtr, BluetoothDeviceInfo ByRef)' failed.  Methods must be security critical or security safe-critical to call native code.

I've studied the Exception on MSDN and google but can't make heads or tails of what to do.  I had been using GPS.NET and migrated everything over.  It all seems to work well, except this one piece.

Any ideas?




Edit: So if I remove the  [assembly: AllowPartiallyTrustedCallers] line from the AssemblyInfo.cs file, everything works fine.  So I guess the question is what is the proper way to use this assembly?


Jan 25, 2011 at 9:42 PM

Erm... this is all still a little bit of a mystery for me, since this came from GPS3 and GeoFramework2 and were not something I wrote.  What partially trusted callers is all about is allowing the code to run when called from a web application like a webpage or something.  The problem is that having unmanaged driver code visible to publicly accessible web methods seems to be a security risk.  The options are to 1) don't allow partial trust users to access any part of your code at all.  (this is the option you describe).  2) mark up the public methods with the pertinent security tag.  (This option also requires converting any properties on the exposed classes that trigger unmanaged methods to be converted into methods, since the security tag cannot be placed on properties.   3) Mark entire classes with an appropriate security attribute.  In GPS3 and Geoframework2, the classes rely on a series of Link-Demand attributes in order to allow the code to call the unmanaged methods on the devices so long as the caller basically has full trust (or at least enough security permission to run the driver code).  In other words, I believe that Microsoft has determined that people doing things like connecting to device drivers are a security risk, so they mark up their API with security requirements in order to access the driver.  If you are only working with a regular program called by a regular user running a local application on your own machine, then the original Link-Demand verified that the calling assembly is local, has full trust, and then everything is good.    However, when I was learning about all this, I learned that the Link-Demand attribute is more or less obsolete now.  Instead we use a different attribute for marking methods.  Unfortunately, not every public method requiring this markup has been mapped out yet, because I personally have no device to test.  Without a device I can't trip the exceptions that you are getting, so have no real way to track down where we need to go in and set the security attributes.  Tidyup tried hunting a lot more of these down, got mostly done, and then lost heart because he would have to change some properties to methods.

For the average user, your solution may work out best for now.  Simply don't allow partial trusted callers of any kind to invoke the code.  This has no affect on your standard library use, but will cause trouble for people using it in a web context.  I'm not sure how many of those there are though, so if that solves your problem and you can still run the application, then by all means keep the change as I don't think it will hurt the code at all.



Jan 25, 2011 at 10:03 PM

Thanks for the quick response.  I will just continue with what I have done.  If you make any progress on the issue, keep me in the loop.  I have plenty of gps devices to test with, so let me know if I can help you in some way.


Feb 22, 2011 at 7:36 AM

Ted - This situation was caused by the changes you introduced after I pushed the first version working version of DotSpatial.Positioning (refactored from GPS.NET and Geoframeworks) to the repo. I "lost heart" when I relalised that the work required to get it working again after your changes would mean I had to change a lot of the public properties to methods - making useage of the component cumbersome and greatly increasing the work required to get existing GPS.NET and Geoframeworks dependent projects going again utilizing DotSpatial instead. As you know GPS.NET and Geoframeworks have been frozen so DotSpatial.Positioning is where all further development work will be made,  the current situation is crippling any development effort and people are starting to find it confusing.

  1. Is there any plan to do something about it apart from waiting for someone who has the time to fix it. this approach seems counter productive as it already worked - LinkDemand may be obsolete but it does work without any practical issue so if you allow it development and usage can continue while a better solution is formulated that we can apply without impacting to much any projects that depend on DotSpatial.Positioning?
  2. Is the intention to make the Positioning component available from a "web application like a webpage" if not does it matter? Why don't we just "Mark entire classes with an appropriate security attribute" so the current problem can be averted?

I'm sorry I haven't had the time to finish the GPS "simulator" and to be honest I'm not sure if this will really be an adequate tool to fix this problem as is not an actual device. It would have to be combined with some kind of virtual com port interface to be of any use.

BTW If your Android phone has a GPS then you do have a bluetooth GPS device! Your phone can pass through it's internal GPS to a bluetooth connected computer - If your interested there is at least one free app on the market...





Aug 4, 2011 at 8:52 PM

Has a fix been implemented for this? I'm getting this error in a winforms application...


Attempt by security transparent method 'DotSpatial.Positioning.BluetoothDevice.Refresh()' to call native code through method 'DotSpatial.Positioning.NativeMethods2.BluetoothGetDeviceInfo(IntPtr, BluetoothDeviceInfo ByRef)' failed.  Methods must be security critical or security safe-critical to call native code

Nov 14, 2012 at 8:06 AM

Apparently a fix has been implimented - work item 421