Comment utiliser un spécifique CultureInfo dans Asp.net Web API

J'ai récemment ajouté API WEB existant VS application de bureau et tout fonctionnait bien, jusqu'à hier, quand j'ai dû ajouter une méthode qui a pris trois paramètres, l'un d'eux un Jour.
Eh bien, au début, je pensais que cela allait être un morceau de gâteau, mais à ma grande surprise, j'ai remarqué que quand j'ai envoyé 2014/07/09 (9 juillet) sur le serveur sur lequel l'application a été installée il a été traité comme 2014/09/07 (7 septembre) et pour cette raison, tous mes comparaisons jamais travaillé.

J'ai essayé des choses comme le changement d'une méthode à une méthode POST, de changer mes paramètres Options Régionales et Linguistiques de la même façon sur le serveur, en passant de la date en tant que Chaîne a créé un objet Datetime sur le serveur en utilisant les parties de la chaîne. Malheureusement, aucun d'entre eux travaillaient.

Puis je me souviens que cette application de bureau ont certaines méthodes sur son WCF projet (qui je passe maintenant à l'API web), qui est passé dates avec aucun problème du tout. En regardant dans le code alors que je trouve qu'ils ont utilisé quelque chose comme ça sur toutes les classes de la WCF projet qui utilise dates:

Imports System.Globalization
Imports System.Security.Permissions
Imports System.Threading

Public Class ServicioRemotoVentas
    Implements IServicioRemotoVentas        
    Public Sub New()
        MyBase.New()
        Thread.CurrentThread.CurrentCulture = New CultureInfo("es-PE", False)
    End Sub

Sûrement ce Fil.CurrentThread.CurrentCulture = New CultureInfo("es-PE", False), doit y être pour quelque chose.
Maintenant, je voudrais savoir si vous avez utilisé quelque chose comme ça dans l'API Web avant? si oui, comment et où avez-vous mis une telle configuration.

Ce sont les paramètres sur mon pc :

Comment utiliser un spécifique CultureInfo dans Asp.net Web API

Et ce sont les paramètres du serveur:

Comment utiliser un spécifique CultureInfo dans Asp.net Web API

J'ai presque oublié de mentionner que j'ai passer toutes les dates à l'aide de ce format aaaa/M/d avec tous les autres paramètres à l'aide de json.
C'est peut-être que lorsque la chaîne est désérialisé dans le site Web de l'API ceci est fait en utilisant la système de format de date parce que je n'ai pas de spécifier la culture info à utiliser? ou peut-être que c'est un Json d'erreur lorsque vous essayez sérialiser/désérialiser les dates??

Comme toujours, des conseils ou des ressources vous pouvez fournir serait grandement apprécié.

S'il vous plaît, essayez de lire ce stackoverflow.com/a/13550990/1679310, il pourrait vous donner une idée, comment définir les web.config ... cela pourrait peut-être aider.
Merci, je vais lui donner un aller, mais il ressemble à quelque chose de plus pour asp.net MVC et mon problème est avec l'API Web
Ce paramètre est la course-réglage de l'heure, c'est à dire qu'il n'a pas d'importance si Asp.net, mvc, web api.. c'est la manière, la façon de dire ce qu'est la culture par défaut sur un serveur (et runtime soins pour nous de mettre sur n'importe quel sujet) ou si nous allons utiliser la culture de l'utilisateur (pas la bonne façon de l'api web où l'on n'utilise JSON... la culture indépendante format)
Merci il fonctionne comme un charme. Désolé de ne pas faire confiance dès le début. C'est juste que j'avais vu quelques pages qui ont essayé de changer cela dans l'WebApiConfig.cs ou Mondial.asax que je pensais que tu avais mal compris ce que j'avais décrit dans ma question. Merci beaucoup et encore une fois DÉSOLÉ

OriginalL'auteur eddy | 2014-07-11

asp.net-web-api c#date date-formatting json

Tel que discuté dans les commentaires, l'ASP.NET d'exécution n'ont qu'une solution pour ces scénarios: c'est le web.cofig élément <mondialisation> - (voir MSDN <mondialisation> de l'Élément)

Sa structure est définie comme:

<configuration>
 <system.web>
  <globalization 
    enableClientBasedCulture="true|false"
    requestEncoding="any valid encoding string"
    responseEncoding="any valid encoding string"
    fileEncoding="any valid encoding string"

    responseHeaderEncoding = "any valid encoding string" 
    resourceProviderFactoryType = string
    enableBestFitResponseEncoding = "true|false"

    culture="any valid culture string"
    uiCulture="any valid culture string"/>

Donc dans le cas où, que nous voulons à force de serveur/station de développement à agir dans en-US culture nous devrions utiliser ces paramètres explicites:

<globalization 
    enableClientBasedCulture="false" 
    uiCulture="en-US" 
    culture="en-US" />

Cela permettra d'utiliser le bon (et réglé) de la culture pour toute requête http.

Aussi intéressant pourrait être la réglage par défaut vue d'ensemble:

<globalization 
    requestEncoding="utf-8" 
    responseEncoding="utf-8" 
    fileEncoding="" 
    culture="" 
    uiCulture="" 
    enableClientBasedCulture="false" 
    responseHeaderEncoding="utf-8" 
    resourceProviderFactoryType="" 
    enableBestFitResponseEncoding="false" />

Voir aussi similaires:

OriginalL'auteur Radim Köhler

1

Il est mentionné dans votre question que l'entrée est une chaîne pas un objet datetime ("j'ai presque oublié de mentionner que je passe toutes les dates à l'aide de ce format aaaa/M/d").
Votre interface de service n'est pas posté, mais je suppose que le paramètre est de type DateTime et c'est pourquoi la désérialisation est incorrect.

Bien que le paramètre posté par Radim fonctionne, il n'est pas un correctif, mais un hack/solution de contournement.

Il y a deux recommandations sur les moyens à mettre en œuvre ce:
1. Utiliser des chaînes à ses deux extrémités, c'est à dire l'API paramètre devrait également être de la chaîne et de la spécification de l'API doit indiquer le format de date à utiliser. Utiliser DateTime.Parse(String, IFormatProvider) et spécifier la culture dans le contrat (c'est à dire new CultureInfo("es-PE")) lorsque la chaîne d'entrée est converti en type DateTime.
  https://msdn.microsoft.com/en-gb/kc8s65zs
2. Utiliser les objets date aux deux extrémités. Dans ce cas, le sérialiseur va sérialiser l'objet date pour un bien connu, de la culture indépendante du format et de la desrializer sera désérialiser la chaîne de corriger objet DateTime.
  
  public void GetOrders(DatetTime fromDate)
J'irais avec #2, car il est générique et ne pas forcer le client à utiliser une culture spécifique.

Voir aussi:
Le "droit" JSON format de la date

OriginalL'auteur user3285954

Vous devez vous connecter pour publier un commentaire.