Archive for the ‘ArcObjects’ Category
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.
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.
I’m One of Those Types
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.