There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?
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
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
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.