none
Errore contenuto text/xml charset

    Domanda

  • Salve a tutti, nelle more di approfondire la mia conoscenza della sicuerzza in WCF, sto facendo delle prove, però ricevo un errore :

    Tipo di contenuto text/xml; charset=utf-8 non supportato dal servizio http://localhost/servicemodelsamples/service.svc. I binding del client e del servizio potrebbero non corrispondere.

    questo il file di configurazione del client :

    <?xml version="1.0"?>
    <configuration>
      <system.serviceModel>
    
        <client>
          <!-- passing "basic" into the constructor of the CalculatorClient class selects this endpoint-->
          <endpoint name="basic" address="http://localhost/servicemodelsamples/service.svc" binding="basicHttpBinding" contract="Microsoft.ServiceModel.Samples.ICalculator"/>
          <!-- passing "secure" into the constructor of the CalculatorClient class selects this endpoint-->
          <endpoint name="secure" address="http://localhost/servicemodelsamples/service.svc/secure" binding="wsHttpBinding" contract="Microsoft.ServiceModel.Samples.ICalculator"/>
        </client>
    
      </system.serviceModel>
    
    <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup></configuration>

    E questa la configurazione del server :

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <system.serviceModel>
        <services>
          <service name="Microsoft.ServiceModel.Samples.CalculatorService">
            <!-- this endpoint is exposed at the base address provided by host: http://localhost/servicemodelsamples/service.svc  -->
            <endpoint address=""
                      binding="basicHttpBinding"
                      contract="Microsoft.ServiceModel.Samples.ICalculator" />
            <!-- secure endpoint exposed at {base address}/secure: http://localhost/servicemodelsamples/service.svc/secure -->
            <endpoint address="secure"
                      binding="wsHttpBinding"
                      contract="Microsoft.ServiceModel.Samples.ICalculator" />
            <!-- the mex endpoint is exposed at http://localhost/servicemodelsamples/service.svc/mex -->
            <endpoint address="mex"
                      binding="mexHttpBinding"
                      contract="IMetadataExchange" />
          </service>
        </services>
    
        <!--For debugging purposes set the includeExceptionDetailInFaults attribute to true-->
        <behaviors>
          <serviceBehaviors>
            <behavior>
              <serviceMetadata httpGetEnabled="True"/>
              <serviceDebug includeExceptionDetailInFaults="False" />
            </behavior>
          </serviceBehaviors>
        </behaviors>
    
      </system.serviceModel>
    
    </configuration>
    

    
    Sembra un problema di codifica fra il client e server per cui non si capiscono, ma se lascio il tutto non indicato, dovrebbe andare di default ?

    Quindi entrambi dovrebbero avere le stesse impostazioni ?

    Grazie in anticipo.

    Gino.



    • Modificato fiborge martedì 5 dicembre 2017 07:49
    martedì 5 dicembre 2017 07:43

Tutte le risposte

  • Faccio presente che è il semplice e banale esempio della documentazione ufficiale di microsoft ... e se non funzionano manco gli esempi forniti da essa stessa ... siamo proprio alla frutta !

    Qualcuno ha mai provato ad eseguirne qualcuno ?

    La parte che mi piace di più è quando cercano di facilitarci la vita (forse si sentono un pò in colpa) e ti scrivono le istruzioni passo passo, sempre ovviamente seguendo la catena dei link.

    Alla fine della catena troviamo qualcosa del tipo :
    esecuzione dell'esempio sullo stesso PC
    ...
    apri l'utilità dei comandi di visual studio
    fai questo e poi quest'altro
    ..
    e fin qui posso capire

    esecuzione dell'esempio su due pc diversi
    posizionarsi sul PC che funzionerà da Client
    ...
    apri l'utilità dei comandi di visual studio
    ...
    ed allora mi chiedo : se è un pc diverso da quello di sviluppo, mica c'è installato visual studio, e tanto meno può esserlo nel PC dove funzionerà la parte SERVER, magari c'è IIS
    ..

    E continuo ... dicevo nell'altra discussione, si va avanti per tornare indietro, con tutta la tecnologia WCF, ci siamo ridotti ad editare a manuzza un file di testo, che tanto comprensibile non è .
    Il formato XML non è proprio immediato, e la documentazione (parlo dei file .config) scarsa, se non a livello di classi e servizi.

    Capisco che nell'impeto di avvicinarsi sempre più all'ambiemte OPEN tipico di Linux la configurazione dei programmi/servizi, tramite l'editazione di file di testo è una cosa naturale, però c'è (e c'è sempre stata) una grande differenza.

    Con Unix qualche anno fa (anche decennio o ventennio), con un semplice 286' con 1 Mb (si un megabyte di memoria) ed una multiporta seriale, si metteva su un server che serviva appunto anche 8 PC in modalità testo (TTY), mentre per fare la stessa cosa con windows 3.1 ai tempi ci voleva un windows for Workgroup, e mega e mega di memoria, schede di rete, software di gestione lanman (c'era anche un software su 12 dischetti della Novell, sto andando a memoria), ed alla fine con quale velocità ?

    Andando avanti negli anni, il mondo free con Linux ha acquisito la grafica e la leggerezza è rimasta, mentre per fare girare un windows oggi, ci vogliono fior di macchine.

    Ma torniamo a noi, per far girare visual studio 2015 agilmente ci vuole il doppio della memoria che in visual studio 2008, e questo analogamente a quello che succede al sistema operativo.

    Avete mai visto un windows "in servizio" quanti Gb di spazio sprecato dalla cartella windows ?
    Si supera facilmente i 25Gb !!!

    Motivo ?
    Semplice in casa microsoft non sanno sviluppare software, per cui usano una tecnica "incrementale", l'aggiunta di nuove funzioni, prevede l'aggiunta di codice, e nessuno che si azzarda ad andare a rivedere (o non parliamo poi di ottimizzare) il codice già presente, magari scritto da altri.
    Se invece perdessero più tenpo per andare a rivedere il codice per amalgamare, riutilizzare ed ottimizzare più oggetti che magari fanno cose simili... e meno male che l' OOP doveva servire per scrivere/produrre meno codice, utilizzando concetti (astratti in casa MS a questo punto devo dire) come polimorfismo, ereditarietà e ....

    Basta mi fermo qui per stasera.

    E così le DLL crescono, i programmi diventano pesanti (a livello utente), e si perde il controllo del codice (a livello developer).

    Gino.
    giovedì 7 dicembre 2017 07:57