This project is read-only.


Add Layer should work if Projection.dll is missing.


One task will be to remove the NAD tables from DotSpatial, but there is little benefit from our modularity if the app crashes when you open a shapefile but don't have the projection library. I will need to think of something clever to manage the bridge because we don't want projection to reference Data, and we want Data to survive without referencing Projection, and only fail if you specifically attempt to reproject. It should be able to pass around a proj4 string or something when no Projection provider is available.

We can use a dynamic loading scheme similar to what plug-ins use, but use reflection to hunt down the projection provider using simply using naming definitions. Hosting a "ProjectionInfo" class in Data that is defined in Projections doesn't work very well if you take away DotSpatial.Projections. Interestingly, it doesn't seem to crash until opening data tries to access that projection info class. We could store the proj4 string on Data, and if you want to do anything clever with that, then you need a reference to ProjectionInfo.

The projection provider could simply take the proj4 strings as arguments. A third idea is that we can create a third library like DotSpatial.Projections.Extender.dll which would reference both DotSpatial.Data and DotSpatial.Projections and provide extension methods on FeatureSet that allow Reproject() by adding a reference, but this could lead to lots of confusion and the extra library may be too much of a penalty to pay. Also, it seems that having the ProjectionInfo is only a problem if you access it in code. So what we need to prevent crashing in our own code is to host the proj4 string. Based on the fact that AOR is able to develop code with FeatureSet references without a DotSpatial.Projections library tells me that you can work with the FeatureSet in code even with the ProjectionInfo class sitting on it, without breaking until you touch it. So we just need to make sure our internal code doesn't touch it and uses reflection to test to see if it can reproject and fail that method if not. We could also support a "CanReproject" property to test so that GUI designers can tip-toe around the issue if necessary.
Closed Feb 28 at 9:04 AM by jany_
This issue list is no longer active. This issue has been copied to our issue list on github (

Please check there to find out whether this issue was fixed.