24 messaggi dal 01 febbraio 2017
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 che nn si capiscono, ma se lascio il tutto non indicato, dovrebbe andare di default ?
Quindi entrambi dovrebbero avere le stesse impostazioni ?

Grazie in anticipo.

Gino.
24 messaggi dal 01 febbraio 2017
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 un pò hanno coscienza delle fesserie che fanno) 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
...
pezzo di idiota (riferito a chi l'ha scritto) 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 usavo 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.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.