ESRI's development plan for developers

[BrentHoskisson]

I think I am going to scream.  We develop in C# using Visual Studio (2010, 2012, 2013 - doesn't matter).

I am now investigating our migration to 10.2.2.  I was pleased to note that no changes (other than a build) were required to make a 10.2.2 compatible program for ArcEngine and ArcGIS.  All the builds worked as x86 builds.

So I turned my attention to ArcGIS Server.  I spent most of the day trying to figure out why my Extensions weren't working even though they compiled and loaded fine.  Finally I compiled the base projects with "Any CPU".  Like magic everything started working.

So (hopefully) I took my "Any CPU" compiled projects and put them back into ArcEngine and ArcGIS.  No luck - you STILL have to compile as x86.  So now it seems I have to maintain ANOTHER set of DLL's just for ArcGIS Server.

It shouldn't surprise me.  ESRI has never been one to care much for code reuse.  (Witness Silverlight API, WPF API, etc which are all different code bases from ArcObjects - not to mention the old MapObjects).
 
My suggestion to ESRI.  Make it ALL work same - just one set of Objects for everything compiled the same way, please.  It will save me many headaches and phone calls to support.

[KenBuja]

You have to remember that ArcGIS Server was rewritten at 10.1 as a 64 bit application, while ArcMap, ArcCatalog, etc. will all remain as 32 bit applications. Esri does not have any plans to make those into 64 bit applications. Instead, the upcoming ArcGIS for Professionals is a 64 bit application.

[MichaelVolz]

Ken:

Is that correct that ArcMap and ArcCatalog will never be 64 bit applications?

Also, I never heard of ArcGIS for Professionals.  Is that a 64 bit application that will be replacing ArcMap and ArcCatalog?

[KenBuja]

That's a question I asked at one of the demos of ArcGIS Pro (not ArcGIS for Professionals like I said in the previous post). They said they will not produce 64 bit versions of the old 32 bit applications. However, Pro is not seen as a replacement for Map (see this video from the 2014 Developer Summit), so the 10.3 release will have both Map and Pro.

[AlexanderGray · Accepted solution]

ArcGIS professional is a new application esri is releasing with 10.3 (the last I heard.)  It is a 64 bit application, multi-threading that using esri's custom graphic engine (no GDI+.)  It is brand new, .NET based (no COM) application with no ArcObjects.  Story is python scripts written for desktop will work (unlikely since desktop is python 2.7 and pro is 3.4)   GUI customization is going to be through WPF. 
On the face of it, it looks like a replacement for desktop and it may eventually be that.  I suspect so many new things at once will compromise stability.  I also suspect it will not have the full suite of functionality desktop currently has.  Looks like you can do some cool new things, how useful, I am not sure.  I wouldn't get too excited or too upset just yet.  Our organization has a lot of investment in customization in ArcObjects (and also in AML.)  The switch wouldn't be easy...

As far as 64bit, 32bit and Any CPU, you can compile for 'Any CPU' for dlls (not exes)  The calling exe needs to be 32 bit on the client and 64bit on the server.  For example, if ArcMap calls a dll compile as Any CPU, it will load it in 32bit because ArcMap is already started in 32bit.  Server should load in as 64bit.  You can also set up different configurations in the visual studio (release32, release64) and compile the same code base twice...  Not as nice but it should work.  If you have a build server, you can automate all that.

[BrentHoskisson]

Instead, the upcoming ArcGIS for Professionals is a 64 bit application.

I will be praying that it uses ArcObjects and not some new set of Objects.  But if not, it won't be the first or second or third time ESRI said "Let's make our  client developers do it all again".

[SeanNakasone]

It might be more of a Microsoft issue...

Yes, I too struggled with the 32-bit vs. 64-bit issues.  It's confusing because although the PC might be 64-bit, Windows supports both 32-bit and 64-bit.  And it's too easy to pick the wrong one when you build.  And if you do pick the wrong one, you'll get a misleading error like...


Unhandled Exception: System.DllNotFoundException: Unable to load DLL 'ArcGISVersion.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
   at ESRI.ArcGIS.NativeInterop.DllGetClassObject(Guid& rclsid, Guid& riid, Object& ppv)
   at ESRI.ArcGIS.RuntimeManager.GetArcGISVersion()
   at ESRI.ArcGIS.RuntimeManager.Bind(ProductCode code)


It would be helpful if it said, the DLL needs to be a 32-bit assembly, instead of, module could not be found.

[AlexanderGray]

I will be praying that it uses ArcObjects and not some new set of Objects.  But if not, it won't be the first or second or third time ESRI said "Let's make our  client developers do it all again".

I suggest voicing you concern to esri.  Personally I think getting away from COM is a very good thing but esri can provide a similar API in .net with most of the same objects.

[BrentHoskisson]

As far as 64bit, 32bit and Any CPU, you can compile for 'Any CPU' for dlls (not exes)  The calling exe needs to be 32 bit on the client and 64bit on the server.

Alexander, I'm giving you the answer because you tipped me off here.  I had never thought about it before, but it is only the RuntimeManager.Bind commands that need to be compiled in x86.  Everything else can be compiled in Any CPU.   I have tested it now, and it is true.  That removes my main frustration anyway.

Brent

[BrentHoskisson]

I suggest voicing you concern to esri.  Personally I think getting away from COM is a very good thing but esri can provide a similar API in .net with most of the same objects.

On the other hand, I think it would be very nice to be able to have a DataAdapter for feature classes.

Brent