Mamy aplikację, która została oryginalnie zbudowana przy użyciu .NET 4.0 i WIF 3.5 (1.0?). Jestem w trakcie przekształcania go, aby korzystać z WIF 4.5, ponieważ zaktualizowaliśmy aplikację do .NET 4.5. Mam wszystkie zmiany w kodzie i walczę z ustawieniami konfiguracji. Mój obecny dylemat to element <claimTypeRequired>. Według this documentation powinno być dzieckiem <identityConfiguration>, ale kiedy zmodyfikować mój config wyglądać tenKonfiguracja Windows Identity Foundation 4.5 Konfiguracja
<system.identityModel>
<identityConfiguration>
<claimTypeRequired>
...
</claimTypeRequired>
pojawia się następujący błąd w czasie wykonywania
Parser Error Message: Unrecognized element 'claimTypeRequired'.
Gdybym tylko komentarz out <claimTypeRequired> blok I przeszedł ten błąd, ale potem jestem przedstawiony z innym problemem. Mieliśmy zmodyfikował maximumClockSkew w istniejącej aplikacji za pomocą następującej konfiguracji
<securityTokenHandlerConfiguration>
<maximumClockSkew value="1" />
</securityTokenHandlerConfiguration>
Dokumentacja konfiguracji odwołuje wcześniej nawet nie wspominając o maximumClockSkew. Pomyślałem, że spróbuję zostawić to, żeby zobaczyć, co się stanie. Co się dzieje, jest
Parser Error Message: Property 'maximumClockSkew' is not a ConfigurationElement.
Ale kiedy patrzę na klasy SecurityTokenHandlerConfigurationElement użyciu JustDecompile widzę właściwość:
[ConfigurationProperty("maximumClockSkew", IsRequired=false, DefaultValue="00:05:00")]
[IdentityModelTimeSpanValidator(MinValueString="00:00:00")]
[TypeConverter(typeof(TimeSpanOrInfiniteConverter))]
public TimeSpan MaximumClockSkew...
więc wydaje się, że spodziewa się go tam być.
To prawie tak, jak Microsoft nie chce, abyśmy używali tych rzeczy.
To jest niesamowite. W System.IdentityModel.Services.Serialization.ConfigurationConstants nadal mają stałą dla niego i klasy wewnętrznej nadal istnieje, aby go reprezentować (System.IdentityModel.Services.Serialization.ClaimTypeRequiredElement). To naprawdę nie ma znaczenia, że był mniej niepokojący niż MaximumClockSkew, który skończyliśmy, robiąc programowo. –
możesz wypróbować opcję poniżej Craig W.Dzięki temu można go konfigurować i nie wymaga twardego kodowania –