Latest Contributions by AnthonyGrescavage

The issue was caused by the different spatial references.  It seems that the appropriate transformation was being applied by some operations and not by others.  We got around this issue by changing the data frame for the service to WGS84 and applying the appropriate transformation to the data frame.  This way the features do not have to be projected on the client and everything matches up nicely. ... View more

Edit 2: I just noticed if I serve the same data up using an ArcGISDynamicMapServiceLayer, the data displays properly.  It's ONLY when using a FeatureLayer that it is in the wrong location, regardless of whether or not the ProjectionService property is set. Edit 3: This only happens with point feature layers.  There is a polygon feature layer in the same service that works as expected.  There are also polyline feature layers in other services with the same basic configuration that also work as expected. ... View more

Thanks Jennifer. ... View more

Are there any plans to support this scenario moving forward? ... View more

This is a fairly old post, so I'm assuming you figured this out already.  In case you haven't, and for the benefit of everyone who stumbles across this page, I'll explain why it's more secure. If you are trying to access secure services, some sort of credentials must be provided.  Regardless of whether or not you are using a secure connection, the credentials are passed in plain text.  Once your credentials are validated, the token service will send the token in plain text.  So there are two chances for someone to intercept valuable information that would allow them to access the site.  If they intercepted a token, they can typically only use it for a short period before it expires (in the case of a short term token).  If they intercept the username and password, however, they can request tokens that would allow them to access the site for as long as the credentials are valid. A scenario that's even worse is if the username and password or token are stored within the application.  In this case that's all someone needs to do to discover it is to reverse engineer the application and read it.  With all of the tools available this is really easy to do.  In some cases, such as javascript, it's already plain text. Enter the proxy page.  The proxy page will typically store either username/password or the actual token.  If you don't secure the proxy page, of course anyone can access it.  That's why you secure the page, much like you would any page you want to limit views to.  At that point you could control who has access to the page and who doesn't.  The username/password or token is stored on the server only, and nothing is ever transmitted to the client. - Anthony ... View more

I posted some helpful information about this issue here. ... View more

Solved! It turns out it WAS a dll issue.  It doesn't matter where you put your GDAL dlls, because ArcGIS Explorer uses GDAL, so it is pre-loaded.  This is why you are seeing the issue.  It seems like it can't find the dll, but it's really a conflict where it can't load it.  The solution is to figure out which version of GDAL that the application is using, and use the same version.  Unfortunately, it is often difficult to find the .NET wrappers for varying version of GDAL.  One direction you could go is to get the source and compile it yourself.  I can tell you, this is quite the pain.  If you're interested, I can provide you with the dlls that I compiled, which match the dlls in the most recent version of ArcGIS Explorer. ... View more

I am currently dealing with the same issue. I have used the sysinternals suite to trace the issue.  While I have not specifically found the problem, I am getting closer.  I have determined that gdal IS finding the dll's that are located in the directory with it.  This has been verified using the procmon utility.  I suspect the problem is a "dll hell" issue.  Some of the dlls that come gdal requires are also used by ArcGIS explorer.  Many of these dlls are different versions than the ones gdal is using.  I suspect that this is what is really causing the issues.  These dlls are not .NET assemblies, so they are still subject to the dll hell problem.  Once the main application loads the dll, there is no way to load another dll with the same name. I'm still troubleshooting.  I'll keep you informed if I make any progress. ... View more