10.1 SOE error - ClassFactory cannot supply requested class

[ReneRubalcava]

We recently deployed ArcGIS Server 10.1 and had previously used MVC web services with ArcObjects to do our heavy lifting. Our services broke with 10.1, it's my understanding we are better suited to use SOEs.

To just do some imple testing and see how we could enable the SOE on a service and interact with it, we published the REST SOE Template from Visual Studio and deployed it to our server with no errors.
However, when we tried to enable it on a map services capabilities we got the error "ClassFactory cannot supply requested class" and the service failes to start. Disable the SOE and the service starts fine.

I'm not sure how to test this locally to see where this might occur, but I assumed if I just published the template without changing anything, I shouldn't have an issue.

For reference, our ArcGIS Server install is 10.1.1 (build 3143).

Any insights would be appreciated. Could there be an issue with our install? Should we try a reinstall?

Thanks.

[nicogis · Accepted solution]

Have you tried with a new simple soe and see if you have the same error?
when have you installed the arcgis server have you flag .net extension support?

[ReneRubalcava]

Well, what do you know. .NET Extension Support was disabled on our install. I don't actually get to install the software, so I had an IT guy double check and sure enough, once we enable it, we can use SOEs as planned. Surprised I could actually add an extension if it that option was disabled.

Thanks!

[JohnGravois]

Big props to Domenico for that find.  I agree with Rene that the error messaging in this case was less than helpful so I logged the following:

[#NIM095669  Provide more descriptive error messaging when an SOE fails because .NET Extension support was not enabled during the install of ArcGIS Server. ]

It don't think it would be appropriate to disable the option to deploy extensions entirely, in case anyone wants to write something in Java.  🙂

[ReneRubalcava]

Thansk for all your help John!
Quick note on this, it looks like enabling .net extension support after AGS is installed wiped the Python27 directory on our server. The folder last updated time and date matches when we enabled that featue and no one else has access to the machine. I asked our IT group do a repair install and see if that fixes it. Just a word of caution.