topic .NET Framework version in ArcGIS Enterprise Questions

.NET Framework version

RichardWatson — Tue, 06 Nov 2012 19:08:53 GMT

ESRI delivers a sample ASP.NET provider for security here:

C:\Program Files\ArcGIS\Server\help\samples\asp.net\in_memory_provider

I built this, installed the resulting DLL in the GAC, and then tested the result using the JSON in the Readme.txt file using this URL:

http://localhost:6080/arcgis/admin/security/config/testIdentityStore

It works fine. No problems.

I then modified the project to use the .NET 4.0 framework and repeated the above steps. It does not work. I can run fuslogvw and see that it fails to load the assembly. The failure occurs in conjunction with ArcSOC.exe. Is there a way to configure this, similar to ArcMap, with a configuration file which tells it to use the 4.0 framework? I tried to copy the pattern from ArcMap but did not have success.

In general, does anyone know of any issues with using the 4.0 framework in conjunction with ArcGIS Server?

As a followup; other than losing XP support, does anyone know why we cannot use the 4.5 framework for both desktop and server?

Re: .NET Framework version

nicogis — Wed, 07 Nov 2012 18:29:51 GMT

Richard, I have tried a fast test and I haven't problems compile in net 4, update in http://localhost:6080/arcgis/admin/s...tIdentityStore and add users/roles and assign roles to services. What are steps so I can simulate if I have same problem.

Re: .NET Framework version

RichardWatson — Wed, 07 Nov 2012 18:37:35 GMT

Did testIdentityStore work for you?

What I did was to:

Modify the sample to build it using my key

Modify the sample to use the 4.0 framework

Built the sample

Added the sample to the GAC (it should go in C:\Windows\Microsoft.NET\assembly\GAC_MSIL)

Use the REST admin testIdentityStore pasting in the JSON from ReadMe.txt after changing the public key

Note that when I did the same thing using the 3.5 framework it worked.

Make sure that you remove the 3.5 assembly from the GAC before testing the 4.0 assembly.

Re: .NET Framework version

nicogis — Thu, 08 Nov 2012 06:11:39 GMT

Excuse me I haven't cut in assembly before re-add in new gac assembly.
However I have inserted in new gac C:\Windows\Microsoft.NET\assembly\GAC_MSIL and when I do the test I have this error:

Could not create an instance of class 'CustomProvider.InMemoryMembershipProvider,CustomProvider,Version=1.0.0.0,Culture=Neutral,PublicKeyToken=mypublictoken'. Type not found in default assembly.

Have you this problem?

ESRI thinks do a soe target .net 2. By default, the runtime attempts to bind with the exact version of an assembly that the application was built with. This default behavior can be overridden by configuration file setting.

see soe C:\Program Files\ArcGIS\Server\framework\lib\ext\AGSMembershidProviderAddin.soe (it's a zip file)

Re: .NET Framework version

RichardWatson — Thu, 08 Nov 2012 09:37:10 GMT

Thanks for the tip on AGSMembershipProviderAddin.soe because I certainly did not know that.

I created the file C:\Program Files\ArcGIS\Server\bin\ArcSOC.exe.config with the following content:

<?xml version='1.0' encoding='utf-8'?>
<configuration>
<startup>
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>

It still won't load my .NET 4.0 ASP.NET provider. I can see the failure in fuslogvw.

Just wondering if you got this to work? I really appreciate your help!

Re: .NET Framework version

nicogis — Thu, 08 Nov 2012 11:13:26 GMT

The problem is that also if you only add supportedRuntime to 4.0 the add-in esri is compiled in 2.0 and it invokes a dll 4.0 in context 2.0. Add supportRuntime 4.0 is ok for config arcsoc.exe but also it's need that esri recompile his soe addin AGSMembershidProviderAddin for manage 4.0 (it invokes with Activator.CreateInstance your dll).

Re: .NET Framework version

RichardWatson — Thu, 08 Nov 2012 20:05:22 GMT

This is now clear. The botttom line here is ESRI does not support custom ASP.NET security providers which are based on the .NET 4.0 framework.

Workarounds include:
1) Editing the ESRI code, recompiling it for the 4.0 framework, and then redistributing that
2) Develop a JAVA extension which implements the required interfaces and have it delegate those to .NET via COM

The 4.0 framework has already been replaced with 4.5 and ESRI has yet to fully support 4.0. I find that disappointing.

Thanks to Domenico for his assistance in understanding this.