2012-05-08 13 views
9

Quindi ho due funzioni e sto ottenendo un problema interessante. Essenzialmente sto mirando a rendere il mio codice più portabile in un file cs facilmente comprensibile.Un riferimento a un oggetto è richiesto per il campo, il metodo o la proprietà non statici 'System.Web.UI.Page.Server.get'

Qui dice di file cs:

namespace basicFunctions { 
public partial class phpPort : System.Web.UI.Page { 
    public static string includer(string filename) { 
     string path = Server.MapPath("./" + filename); 
     string content = System.IO.File.ReadAllText(path); 
     return content; 
    } 
    public void returnError() { 
     Response.Write("<h2>An error has occurred!</h2>"); 
     Response.Write("<p>You have followed an incorrect link. Please double check and try again.</p>"); 
     Response.Write(includer("footer.html")); 
     Response.End(); 
    } 
} 
} 

Ecco la pagina che fa riferimento è:

<% @Page Language="C#" Debug="true" Inherits="basicFunctions.phpPort" CodeFile="basicfunctions.cs" %> 
<% @Import Namespace="System.Web.Configuration" %> 

<script language="C#" runat="server"> 
void Page_Load(object sender,EventArgs e) { 
    Response.Write(includer("header.html")); 
    //irrelevant code 
    if ('stuff happens') { 
     returnError(); 
    } 
    Response.Write(includer("footer.html")); 
} 
</script> 

L'errore che sto ottenendo è quello di cui sopra, vale a dire:

Messaggio di errore del compilatore: CS0120: è richiesto un riferimento a un oggetto per il campo, il metodo o la proprietà non statici "System.Web.UI.Page.Server.get"

Sulla riga seguente:

Linea 5: stringa di percorso = Server.MapPath ("./" + nome del file);

+2

Consiglio vivamente di non ripetere gli errori di php. Controlla invece come funzionano le pagine master o semplicemente passa a MVC. – NotMe

+1

Non tutti noi vediamo lo stile di codifica di PHP come un errore. Per quelli di noi con uno sfondo di codifica più tradizionale che ci offre più controlli di basso livello e flessibilità di codifica a scapito della velocità di produzione (sebbene non di runtime) o di un focus su oggetti pesanti, ci si sente un po 'più a casa. Inoltre, la documentazione è migliore = P. Inoltre, trovo che più profondamente entri nella tana del coniglio di ASP.NET, peggiore il tuo HTML e JavaScript tendono a finire (dato che inizia a generarsi pesantemente). XHTML, JSLint, ecc. È importante per me, quindi preferisco tenere il più possibile dipendente dal codice. –

+1

Non c'è niente di sbagliato nel modo ufficiale sanzionato da Microsoft, suppongo. Tuttavia, dire che è intrinsecamente migliore perché è quello che la gente ti dice di fare è un po 'ingenuo in quanto spesso crea codice con un ingombro di memoria più grande, più posti per buchi di sicurezza di errore comune e molte, molte più linee di codice. Naturalmente, d'altra parte, è anche migliore sotto molti aspetti per i grandi ambienti di lavoro di produzione con molti programmatori individuali che lavorano insieme. Diversi stili di codifica, tutto qui. Sono sempre nel campo di PHP, temo. –

risposta

9

Server è disponibile solo per i casi di System.Web.UI.Page -implementations (in quanto è una proprietà di istanza).

hai 2 opzioni:

  1. convertire il metodo da statico a esempio
  2. Usa codice seguente:

(sovraccarico di creare un System.Web.UI.HtmlControls.HtmlGenericControl)

public static string FooMethod(string path) 
{ 
    var htmlGenericControl = new System.Web.UI.HtmlControls.HtmlGenericControl(); 
    var mappedPath = htmlGenericControl.MapPath(path); 
    return mappedPath; 
} 

o (non testato):

public static string FooMethod(string path) 
{ 
    var mappedPath = HostingEnvironment.MapPath(path); 
    return mappedPath; 
} 

o (opzione non che il bene, come si finge in qualche modo di essere statico ma è piuttosto statico per webcontext chiamate soli):

public static string FooMethod(string path) 
{ 
    var mappedPath = HttpContext.Current.Server.MapPath(path); 
    return mappedPath; 
} 
+0

L'OP * è * sottoclasse di 'System.Web.UI.Page'. Questo non è il problema dell'OP. –

+0

** che ** è il problema dell'OP - non è in grado di distinguere tra proprietà statiche e istanze! ... ho chiaramente dichiarato 'istanza di ...' –

+0

Certo, la tua risposta ora è più chiara. La tua risposta iniziale implicava che l'OP non stava usando quella classe. –

0
public static string includer(string filename) 
{ 
     string content = System.IO.File.ReadAllText(filename); 
     return content; 
} 


includer(Server.MapPath("./" + filename)); 
1

mi sono imbattuto in una cosa simile qualche tempo fa - In parole povere, non si può tirare Server.MapPath() dalle cs code-behind all'interno di un metodo statico (a meno che il codice dietro in qualche modo eredita una classe di pagine web, che non è probabilmente consentita comunque).

La mia semplice soluzione era quella di avere il codice dietro il metodo di acquisire il percorso come argomento, quindi la pagina web chiamante esegue il metodo con Server.MapPath durante la chiamata.

codice sottostante (.CS):


public static void doStuff(string path, string desc) 
{ 
    string oldConfigPath=path+"webconfig-"+desc+"-"+".xml"; 

... now go do something ... 
} 

pagina web (.ASPX) Metodo di chiamata:


... 
doStuff(Server.MapPath("./log/"),"saveBasic"); 
... 

Non c'è bisogno di colpire o parlare verso il basso per l'OP, sembrava una confusione legittima. Spero che questo aiuti ...

+0

Di gran lunga il più facile! Puoi mettere tutti i tipi di materiale confidenziale nel CS, passare il comando mappath non darà via alcuna informazione segreta. – Dandymon