Archive for the ‘ArcObjects’ Category

Simplify SOE Deployment with Self Registration

Registering SOE’s can be a pain, but there is an easier way.

Esri suggests having a separate exe that registers the dll, but this needs to be done after running Regasm on it.

On top of that, if you’re running Win7, and right click on a .bat file and choose to “run as Administrator”, the current working directory does not get set to the folder where the .bat is located. What a pain.

Instead of building an SOE as a dll, build it as an exe. The Main program of the SOE can do the registration/unregistration. First, by calling Regasm, and then by registering with AGS, similar to Esri’s sample.

I haven’t tested this a lot in production, so if you run into issues, please let me know.

I’ve posted a sample solution here that illustrates this.

Advertisements

LinqPad Spatial Challenge

To get up to speed with new things in C# 4.0, I’ve been reading C# 4.0 In A Nutshell by Joseph and Ben Albahari.

To illustrate examples, the book uses LinqPad, a freely downloadable tool. I recommend the book, and I highly recommend LinqPad.

Still, there is room for improvement with LinqPad. The author of LinqPad has presented the LINQPad Challenge, with the following rules:

1. Locate the shortcut for SQL Management Studio (SSMS) on your Start Menu and move it some place else.
2. In its place, insert a shortcut to LINQPad.
3. For the next week, perform all your ad-hoc SQL queries using only LINQPad.

If you’re like me though, you may not feel up to this challenge. I have grown attached to SSMS’s spatial query viewer, which is lacking in LinqPad. It would be great if someone would write a custom Data Context Driver for LinqPad so that spatial query output from ArcObjects could be displayed on a map, just as it is in SSMS.

It seems like this would also allow the geodatabase implementation to be abstracted, removing dependencies on SQL Server, so maybe someone from ESRI could justify doing this.

ArcGIS Server, Balkanization and Unintellisensibility

With five ArcGIS Server SDK’s to choose from, it would be helpful to have some sort of matrix summarizing relative strengths weaknesses of each. For now, it sure looks Balkanized.

I’m One of Those Types
Yes, I’m the type of guy who can’t stand stereotypes. You know, the kind that blurts out “generalizations are bad!” when cornered. Generally speaking, generalizations are bad – but not when it comes to IDE’s. I’ve gotten so spoiled on VS intellisense, working with javascript feels awkward. And not because it’s not an MS product – autocompletion in Sql Server Management Studio is quite annoying as well. From what I can tell, static types are what make intellisense possible. With Silverlight I can use intellisense to write all my client side code, if I so choose.

That may change with addition of dynamic types in C# 4.0. Generally speaking, dynamic types are a good thing, but it seems like it’ll make C# more like javascript. Here’s a good writeup showing how dynamic types simplify JSON interaction. Perhaps an understated advantage of SOAP over REST is static types. I guess as long as I have two monitors I’ll survive – with one of them eternally opened to the API reference docs.

Sense and UnIntelliSensiblity
Kirill shows how dynamic types can simplify use of COM libraries in .NET – at the expense of becoming unintellisensible.

This suggests ArcObjects programmers will be able to write code that is visually more elegant than currently possible – yet unintellisensible. It may look pretty during a code review, but I sure feel sorry for any non ArcObjects programmer tasked with altering it. It looks like it would even be possible to write an obfuscator disguised as a prettyfier. It would take Kirill’s first example, strip out the “using”, replace the static type with a dynamic type, and voila, prettier code.